On Fri, 2008-09-12 at 13:54 +0200, Csaba Nagy wrote: > > I think that enabling long-running queries this way is both > > low-hanging > > fruit (or at least medium-height-hanging ;) ) and also consistent to > > PostgreSQL philosophy of not replication effort. As an example we trust > > OS's file system cache and don't try to write our own. > > I have again questions (unfortunately I only have questions usually): > > * how will the buffers keep 2 different versions of the same page ?
As the FS snapshot is mounted as a different directory, it will have it's own buffer pages. To conserve RAM, one could go to FS snapshot files only in case main pages have LSN too big to be trusted. > * how will you handle the creation of snapshots ? probably an external command, possibly shell script. similar to current "archive_command" for wal copying maybe 'create_fs_snapshot_command' and 'destroy_fs_snapshot_command' > I guess there's no portable and universal API for that (just guessing), > or there is some POSIX thing which is supported or not by the specific FS ? > So if the FS is not supporting it, you skip the snapshot step ? Yes, if not FS snapshots are not supported, we fall back to either inconsistent read or killing long-running queries. > And if there's no universal API, will it be handled by plugins providing > a specified API for snapshotting the FS ? Yes, the simplest one being external command. As FS snapshots are supposed to happen not-too often, at least not every second, just having external commands may be enough. > I hope my continuous questioning is not too annoying... On the contrary, much appreciated. :) ---------------- Hannu -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
