From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hannu Krosing <hannu(at)tm(dot)ee> |
Cc: | Curt Sampson <cjs(at)cynic(dot)net>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Mike Biamonte <mbiamonte(at)affinitysolutions(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WAL -> Replication |
Date: | 2002-04-26 14:41:02 |
Message-ID: | 26008.1019832062@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)tm(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-04-26 14:46:24 | Re: pid gets overwritten in OSX |
Previous Message | Tom Lane | 2002-04-26 14:34:38 | Re: Vote totals for SET in aborted transaction |