Re: lazy snapshots?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Oct 20, 2010 at 8:11 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> I'm imagining that the kernel of a
>>> snapshot is just a WAL position, ie the end of WAL as of the time you
>>> take the snapshot (easy to get in O(1) time). Visibility tests then
>>> reduce to "did this transaction commit with a WAL record located before
>>> the specified position?".

> I spent a bunch of time thinking about this, and I don't see any way
> to get the memory usage requirements down to something reasonable.
> The problem is that RecentGlobalXmin might be arbitrarily far back in
> XID space, and you'll need to know the LSN of every commit from that
> point forward; whereas the ProcArray requires only constant space.

That's like arguing that clog is no good because it doesn't fit in
constant space. ISTM it would be entirely practical to remember the
commit LSN positions of every transaction back to RecentGlobalXmin,
using a data structure similar to pg_subtrans --- in fact, it'd require
exactly twice as much working space as pg_subtrans, ie 64 bits per XID
instead of 32. Now, it might be that access contention problems would
make this unworkable (I think pg_subtrans works largely because we don't
have to access it often) but it's not something that can be dismissed
on space grounds.

[ thinks for a bit... ] But actually this probably ends up being a
wash or a loss as far as contention goes. We're talking about a data
structure that has to be updated during each commit, and read pretty
frequently, and it's not obvious how that's any better than getting
commit info from the ProcArray. Although neither commit nor reading
would require a *global* lock, so maybe there's a way ...

regards, tom lane