Re: WAL -> Replication - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WAL -> Replication
Date
Msg-id 26008.1019832062@sss.pgh.pa.us
Whole thread Raw
In response to Re: WAL -> Replication  (Hannu Krosing <hannu@tm.ee>)
Responses Re: WAL -> Replication
Re: WAL -> Replication
List pgsql-hackers
Hannu Krosing <hannu@tm.ee> writes:
> DB2 can run in two modes 
> 1) similar to ours, where logs are reused after checkpoints/commits
> allow it.
> 2) with log archiving: logs are never reused, but when system determines
> it no longer needs them, it will hand said log over to archiving process
> that will archive it (usually do a backup to some other place and then
> delete it).

There is in fact the skeleton of support in xlog.c for passing unwanted
log segments over to an archiver, rather than recycling them.  So far
no one's done anything with the facility.  I think the main problem is
the one Bruce cited: because the WAL representation is tied to physical
tuple locations and so forth, it's only useful to a slave that has an
*exact* duplicate of the master's entire database cluster.  That's not
useless, but it's pretty restrictive.

It could be useful for incremental backup, though I'm not sure how
efficient it is for the purpose.  WAL logs tend to be pretty voluminous.
At the very least you'd probably want enough smarts in the archiver to
strip out the page-image records.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Vote totals for SET in aborted transaction
Next
From: Bruce Momjian
Date:
Subject: Re: Vote totals for SET in aborted transaction