Re: Transaction Snapshots and Hot Standby
От | Simon Riggs |
---|---|
Тема | Re: Transaction Snapshots and Hot Standby |
Дата | |
Msg-id | 1221230912.3913.1065.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Transaction Snapshots and Hot Standby (Hannu Krosing <hannu@2ndQuadrant.com>) |
Список | pgsql-hackers |
On Fri, 2008-09-12 at 15:08 +0300, Hannu Krosing wrote: > 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.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: