> 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.
RelFileNode has a spcNode which can be redirected to a temporary
filesystem snapshot. So its relatively easy to imagine redirecting
access to a table from its normal tablespace to the snapshot one.
> To conserve RAM, one could go to FS snapshot files only in case main
> pages have LSN too big to be trusted.
That would mean you'd need to do two I/Os, one to get the newly changed
page to get its LSN and another to get the old COW copy. We might waste
buffer space with that technique also. Since we'd be trying to avoid
cacheing bigger tables anyway (since 8.3) it seems easier to just go
straight to the COW copy.
So I think its fairly straightforward to support temporary snapshots in
Postgres, with creation/destruction handled in the way you say.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment