Hot Standby 0.2.1
in [PgSql]
|
From: Simon Riggs on 23 Sep 2009 06:23 On Wed, 2009-09-23 at 12:07 +0300, Heikki Linnakangas wrote: > seems to be broken Agreed. Patch withdrawn for correction and rework. Nothing serious, but not much point doing further testing to all current issues resolved. Tracking of issues raised and later solved via Wiki. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 23 Sep 2009 07:36 Simon Riggs wrote: > On Wed, 2009-09-23 at 11:13 +0300, Heikki Linnakangas wrote: >> I note that we don't emit RunningXacts after a shutdown checkpoint. So >> if recovery starts at a shutdown checkpoint, we don't let read-only >> backends in until the first online checkpoint. Could we treat a shutdown >> checkpoint as a snapshot with no transactions running? Or do prepared >> transactions screw that up? > > We could, but I see no requirement for starting HS from a backup taken > on a shutdown database. It's just another special case to test and since > we already have significant number of important test cases I'd say add > this later. There's also a related issue that if a backend holding AccessExclusiveLock crashes without writing an abort WAL record, the lock is never released in the standby. We handle the expiration of xids at replay of running-xacts records, but AFAICS we don't do that for locks. It shouldn't be much code to clear those states at shutdown checkpoint, just a few lines to call the right functions methinks. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 23 Sep 2009 10:45 Heikki Linnakangas wrote: > Simon Riggs wrote: >> On Wed, 2009-09-23 at 11:13 +0300, Heikki Linnakangas wrote: >>> I note that we don't emit RunningXacts after a shutdown checkpoint. So >>> if recovery starts at a shutdown checkpoint, we don't let read-only >>> backends in until the first online checkpoint. Could we treat a shutdown >>> checkpoint as a snapshot with no transactions running? Or do prepared >>> transactions screw that up? >> We could, but I see no requirement for starting HS from a backup taken >> on a shutdown database. It's just another special case to test and since >> we already have significant number of important test cases I'd say add >> this later. > > There's also a related issue that if a backend holding > AccessExclusiveLock crashes without writing an abort WAL record, the > lock is never released in the standby. We handle the expiration of xids > at replay of running-xacts records, but AFAICS we don't do that for locks. Ah, scratch that, I now see that we do call XactClearRecoveryTransactions() when we see a shutdown checkpoint, which clears all recovery locks. But doesn't that prematurely clear all locks belonging to prepared transactions as well? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jeff Janes on 23 Sep 2009 11:44 On Tue, Sep 22, 2009 at 10:02 AM, Alvaro Herrera <alvherre(a)commandprompt.com> wrote: > Heikki Linnakangas escribió: >> Simon Riggs wrote: >> > On Mon, 2009-09-21 at 19:42 -0700, Jeff Janes wrote: >> >> jjanes=# begin; >> >> BEGIN >> >> jjanes=# lock table pgbench_history in access exclusive mode; >> >> LOCK TABLE >> >> jjanes=# select count(*) from pgbench_history; >> >> count >> >> -------- >> >> 519104 >> >> (1 row) >> >> >> >> jjanes=# select count(*) from pgbench_history; >> >> count >> >> -------- >> >> 527814 >> >> (1 row) >> >> >> >> Is this the expected behavior? >> > >> > By me, yes. WAL replay does not require a table lock to progress. Any >> > changes are protected with block-level locks. It does acquire a table >> > lock and cancel conflicting queries when it is about to replay something >> > that would cause a query to explode, such as dropping a table, as >> > explained in docs. >> >> That is rather surprising. You can't get that result in a normal server, >> which I think is enough of a reason to disallow it. If you do LOCK TABLE >> ACCESS EXCLUSIVE, you wouldn't expect the contents to change under your >> nose. Right. I'd rather be denied the lock than have it granted to me but not do the same thing it does on a primary---prevent all changes to the locked table. > I think the fallout from that argument is that WAL replay should hold > table-level locks (otherwise the workaround to this problem is too > special-casey). I'm not sure about that. If I really wanted to get > consistent results, I'd use a serializable transaction. Unfortunately, isolation level "serializable" is not truly serializable. Usually it is good enough, but when it isn't good enough and you need an explicit table lock (a very rare but not nonexistent situation), I think it should either lock the table in the manner it would do on the primary, or throw an error. I think that silently changing the behavior between primary and standby is not a good thing. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 23 Sep 2009 12:03
Jeff Janes <jeff.janes(a)gmail.com> writes: > Unfortunately, isolation level "serializable" is not truly > serializable. Usually it is good enough, but when it isn't good > enough and you need an explicit table lock (a very rare but not > nonexistent situation), I think it should either lock the table in the > manner it would do on the primary, or throw an error. I think that > silently changing the behavior between primary and standby is not a > good thing. +1 --- this proposal made me acutely uncomfortable, too. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |