Re: [PATCHES] Forcing current WAL file to be archived
От | Hannu Krosing |
---|---|
Тема | Re: [PATCHES] Forcing current WAL file to be archived |
Дата | |
Msg-id | 1155131545.5899.4.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: [PATCHES] Forcing current WAL file to be archived (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: [PATCHES] Forcing current WAL file to be archived
|
Список | pgsql-hackers |
Ühel kenal päeval, K, 2006-08-09 kell 12:56, kirjutas Simon Riggs: > On Sat, 2006-08-05 at 23:57 -0400, Tom Lane wrote: > > > I also made the new user-level functions a bit > > more orthogonal, so that filenames could be extracted from the > > existing functions like pg_stop_backup. > > 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? > > 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. > > Any objections if I correct that? What is the difference ? I'd expect it to point either to last byte written or to the next byte that will be written, and I want to know which one it is :) And another question: is is possible that under some circumstances the last few bytes of a WAL file will not be written to ? or is the writing done as if all the wal files together form one huge tape, without any gaps between ? -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com
В списке pgsql-hackers по дате отправления: