Re: Forcing current WAL file to be archived

Ühel kenal päeval, T, 2006-07-25 kell 17:52, kirjutas Csaba Nagy:
> > OK, "offset" added to TODO item. What would the offset give us?
>
> The last offset could be remembered by the external program, and it
> only
> has to transfer from the last offset to the new one. It allows
> incremental streaming of the WAL files... of course the external
> program
> will be a lot more complex than the current shell scripts which can be
> used for WAL archiving...
>
> The problems I see with this is if in this case the normal postgres
> WAL
> archiving won't conflict with this streaming ?

You are not forced to use it if your shell scripts do conflict.

What I envisioned, was that the current WAL archiving shell script would
just do some CRC check over the WAL's already shipped, or as we
currently use rsync to do the actual shipping this is what happens
automatically.

> And if yes, wouldn't it
> be better to have a separate mechanism for the stream based
> archiving ?

why separate ? I'm a great believer in doing the minimum useful change,
at least in systems used in production. We already have a working
solution for full file shipping, so why not just augment it with
streaming the currently-written-to file.

> I mean what will happen if postgres successfully archives the WAL file
> and then moves it out of way before the streaming process finishes
> with
> it, the streaming process will have a problem...

This should not happen. your streaming process should be smart enought
to guarantee that.

--
----------------
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

NOTICE: This communication contains privileged or other confidential
information. If you have received it in error, please advise the sender
by reply email and immediately delete the message and any attachments
without copying or disclosing the contents.