Re: cheaper snapshots

On Thu, Jul 28, 2011 at 11:57 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Jul 28, 2011 at 10:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> But should we rethink that?  Your point that hot standby transactions on
>>> a slave could see snapshots that were impossible on the parent was
>>> disturbing.  Should we look for a way to tie "transaction becomes
>>> visible" to its creation of a commit WAL record?  I think the fact that
>>> they are not an indivisible operation is an implementation artifact, and
>>> not a particularly nice one.
>
>> Well, I agree with you that it isn't especially nice, but it seems
>> like a fairly intractable problem.  Currently, the standby has no way
>> of knowing in what order the transactions became visible on the
>> master.
>
> Right, but if the visibility order were *defined* as the order in which
> commit records appear in WAL, that problem neatly goes away.  It's only
> because we have the implementation artifact that "set my xid to 0 in the
> ProcArray" is decoupled from inserting the commit record that there's
> any difference.

Hmm, interesting idea. However, consider the scenario where some
transactions are using synchronous_commit or synchronous replication,
and others are not. If a transaction that needs to wait (either just
for WAL flush, or for WAL flush and synchronous replication) inserts
its commit record, and then another transaction with
synchronous_commit=off comes along and inserts its commit record, the
second transaction will have to block until the first transaction is
done waiting. We can't make either transaction visible without making
both visible, and we certainly can't acknowledge the second
transaction to the client until we've made it visible. I'm not going
to say that's so horrible we shouldn't even consider it, but it
doesn't seem great, either.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company