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