Re: [PATCHES] Forcing current WAL file to be archived
От | Bruce Momjian |
---|---|
Тема | Re: [PATCHES] Forcing current WAL file to be archived |
Дата | |
Msg-id | 200608140243.k7E2ho000108@momjian.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] Forcing current WAL file to be archived (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCHES] Forcing current WAL file to be archived
|
Список | pgsql-hackers |
This issue is closed, right? --------------------------------------------------------------------------- Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > Something Hannu wrote has just reminded me that > > pg_current_xlog_location() returns the current Insert pointer rather > > than the current Write pointer. > > That would not be useful for streaming xlog records would it? > > Good point. > > > Methinks it should be the Write pointer all of the time, since I can't > > think of a valid reason for wanting to know where the Insert pointer is > > *before* we've written to the xlog file. Having it be the Insert pointer > > could lead to some errors. > > However the start/stop_backup functions return the Insert pointer. > I can see scripts getting confused if pg_current_xlog_location reports > something less than what they just got from pg_stop_backup. > > Is there value in exposing both pointers? (Maybe not, it'll just cause > confusion probably.) > > Another option is to have pg_current_xlog_location force a write (but > not fsync) as far as the Insert pointer it's about to return. This > would eliminate any issues about inconsistency between results, but > perhaps there's too much performance penalty. > > I'm not necessarily against your suggestion, just trying to be sure > we've thought about all the options. > > regards, tom lane -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: