Re: Snapshot synchronization, again...
Jim Nasby <jim@nasby.net>
From: Jim Nasby <jim@nasby.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Joachim Wieland <joe@mcknight.de>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Alvaro Herrera <alvherre@commandprompt.com>, Noah Misch <noah@leadboat.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-03-02T02:28:06Z
Lists: pgsql-hackers
On Feb 28, 2011, at 11:59 AM, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Sun, Feb 27, 2011 at 8:33 PM, Joachim Wieland <joe@mcknight.de> wrote: >>> Remember that it's not only about saving shared memory, it's also >>> about making sure that the snapshot reflects a state of the database >>> that has actually existed at some point in the past. > >> But you can do all of this with files too, can't you? Just remove or >> truncate the file when the snapshot is no longer valid. > > Yeah. I think adopting a solution similar to 2PC state files is a very > reasonable way to go here. This isn't likely to be a high-usage or > performance-critical feature, so it's not essential to keep the > information in shared memory for performance reasons. Dumb question: Is this something that could be solved by having the postmaster track this information in it's local memory and make it available via a variable-sized IPC mechanism, such as a port or socket? That would eliminate the need to clean things up after a crash; I'm not sure if there would be other benefits. -- Jim C. Nasby, Database Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net