On Tue, 2009-02-03 at 13:50 +0000, Gregory Stark wrote: > Hannu Krosing <ha...@krosing.net> writes: > > > Actually we came up with a solution to this - use filesystem level > > snapshots (like LVM2+XFS or ZFS), and redirect backends with > > long-running queries to use fs snapshot mounted to a different > > mountpoint. > > Uhm, how do you determine which snapshot to direct the backend to? There could > have been several generations of tuples in that tid since your query started. > Do you take a snapshot every time there's a vacuum-snapshot conflict and > record which snapshot goes with that snapshot?
The most sensible thing to do seems to wait for some configurable period (say a few seconds or a few minutes), delaying WAL apply, and then to do the snaphot, mount it and redirect all running transactions to use _current_ filesystem snapshot, and then resume WAL application. As each of the transactions running on saved fs snapshots complete, they are switced back to main/live fs view. When the last there transaction ends, the snapshot is unmounted and released. -- ------------------------------------------ Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
