Snapshot memory management - Mailing list pgsql-hackers

Hi,

So far I've posted two patches on snapshot tracking: one to keep track
of "regular" snapshots[1] and another to keep track of snapshots used as
ActiveSnapshot[2].

[1] http://archives.postgresql.org/message-id/20080328140606.GL7464@alvh.no-ip.org
[2] http://archives.postgresql.org/message-id/20080408014655.GH5095@alvh.no-ip.org

These patches are conceptually largely independent; however, there is
one area where they clash heavily, which is on memory management: when
should we free the memory used by a snapshot?  If we do as soon as it is
unregistered, it may have been too soon since it is already active; and
conversely we cannot release it when it is removed from the active stack
because it may still be registered somewhere.

I think the way to solve this problem is to keep track, on each
snapshot, whether they are on the registered list, and also whether they
are on the active list.  FreeSnapshot will then be a no-op unless both
of these conditions no longer hold.

To implement this I propose keeping track of four additional pointers in
SnapshotData: "next" and "prev" in the registered list, and "next" and
"prev" in the active stack.  So when we unregister the snapshot, we will
update the next and prev's snapshots' pointers, and set this snapshot's
to NULL; and free the memory only if the active stack pointers are
already NULL.  Equivalently, when we pop the snapshot from the active
stack, we'll update the pointers of the adjacent snapshot and set ours
to NULL, and free the memory only if the registered list pointers are
NULL.

Basically these pointers implement two doubly linked lists for each
snapshot; we free it when the snapshot no longer belongs to either list.

One nice side effect of this is that we no longer need to troll the list
of snapshots when we unregister one -- the snapshot itself already has
the pointers needed to do it, so it is a cheaper operation.

Something to consider is that the patches posted implement separate
structs for keeping track of the snapshots; so for example the refcount
is kept separately from the snapshot itself.  On this proposal all this
info would go inside SnapshotData itself.  I don't think this is a
problem, particularly because it means snapmgr has immediate access to
the lists just given the snapshot, instead of having to walk from the
head-of-list each time.

Note: there is a slight complication as far as the registered list is
concerned, because we need to keep track of reference counts for each
snapshot.  This is not a problem -- when a snapshot is unregistered but
ends up with a nonzero refcount, we just don't touch the next/prev
links.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.