Hi,

Le 11 août 09 à 07:50, Heikki Linnakangas a écrit :
>2009/8/11 Robert Haas <robertmh...@gmail.com>
> We should probably have a separate discussion about what the least
> committable unit would be for this patch.  I wonder if it might be
> sufficient to provide a facility for streaming WAL, plus a standalone
> tool for receving it and storing it to a file.

That's an interesting idea. That would essentially be another method to set up a WAL archive. I'm not sure it's worthwhile on its own, but once we have the wal-sender infrastructure in place it should be easy to write such a tool.

Well it might be over engineering time *again* but here's what it makes me think about:

We should somehow provide a default archive and restore command integrated into the main product, so that it's as easy as turning it 'on' in the configuration for users to have something trustworthy: PostgreSQL will keep past logs into a pg_xlog/archives subdir or some other default place, and will know about the setup at startup time when/if needed.

Now, the archive and restore commands would make a independent subsystem, the only one (for modularisation sake) allowed to work with the archives. So we extend it to support sending and receiving archives to/from a remote PostgreSQL server, using libpq and the already proposed protocol in the current patch form.

It could be that for integration purpose we'd need something like the autovacuum launcher, an archive manager daemon child of postmaster accepting signals in order to spawn a specific tasks. Sender part could be launched more than once at any time, e.g.

Of course the included automatic and easy to setup daemon wouldn't care about setting up a remote archiving policy, but on the other hand a remote PostgreSQL instance could easily be set up as a wal receiver from the master's archive. The archive retention policy and how it applies to known list of receivers is to discuss :)

As far as the (a)Sync Rep patch is concerned, this could solve the setup part of it, this step where starting from a filesystem level backup you realize you need archived WALs before being able to apply currently received entries (LSN granularity).

Regards,
--
dim


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to