Re: Forcing current WAL file to be archived
От | Hannu Krosing |
---|---|
Тема | Re: Forcing current WAL file to be archived |
Дата | |
Msg-id | 1153843549.2922.22.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Forcing current WAL file to be archived (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
Ühel kenal päeval, T, 2006-07-25 kell 11:48, kirjutas Bruce Momjian: > Hannu Krosing wrote: > > ?hel kenal p?eval, T, 2006-07-25 kell 11:27, kirjutas Bruce Momjian: > > > Hannu Krosing wrote: > > > > ?hel kenal p?eval, T, 2006-07-25 kell 10:51, kirjutas Bruce Momjian: > > > > > Where are we on these TODO items: > > > > > > > > > > > > > > o Add reporting of the current WAL file, perhaps as part of > > > > > partial log file archiving > > > > > > > > It would be nice to have a function that tells both filename and offset > > > > of current WAL file, so it would be possible to do live async streaming > > > > of up-to-subsecond changes without too much overhead. > > > > > > OK, "offset" added to TODO item. What would the offset give us? > > > > the offset returned by lseek() on the WAL file, that is the end of the > > part of the WAL file which has actually been written to. > > Sorry, I was actually asking what use the offset would be to a user. There would be an external async process, which continuously polls the offset and pushes everything written between the polls to slave site. so when this process starts up it gets (file = wal00001 and offset=10000) and it sends first 10000 bytes to slave site, at next rountd it gets (file = wal00001 and offset=15000) and it sends bytes 10001-15000 to remote and so on. this way the slave has a lag no more than the poll interval in usable WAL data. -- ---------------- 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 по дате отправления: