Re: WAL -> Replication

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

In response to

Responses

Browse pgsql-hackers by date

  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