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.
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.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
