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. > So not a bug, but just one of many possible behaviours we could enforce. > 1. Allow AccessExclusiveLocks yet they do not interrupt WAL replay > 2. Allow AccessExclusiveLocks but have them pause WAL replay > 3. Disallow AccessExclusiveLocks (and so LOCK TABLE is effectively a > no-op because it will not be able to serialize anything) > > So the patch originally implemented (3) but now implements (1). > > I would say that (2) is very undesirable because it puts WAL replay in > the control of non-superusers. That could mean LOCK TABLE implicitly > alters the high availability of the standby, and might even be used > maliciously to do that. I don't see a problem with (2) as long as the locker is kicked out after max_standby_delay, like a long-running query. That's what I would expect. I'm fine with (3) as well, but (1) does seem rather suprising behavior. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
