Jason Long wrote:
> Greg Smith wrote:
>> On Thu, 30 Oct 2008, Tom Lane wrote:
>>> The real reason not to put that functionality into core (or even
>>> contrib) is that it's a stopgap kluge. What the people who want this
>>> functionality *really* want is continuous (streaming) log-shipping, not
>>> WAL-segment-at-a-time shipping.
>> Sure, and that's why I didn't care when this got kicked out of the
>> March CommitFest; was hoping a better one would show up. But if 8.4
>> isn't going out the door with the feature people really want, it would
>> be nice to at least make the stopgap kludge more easily available.
> Sure I would rather have synchronous WAL shipping, but if that is going
> to be a while or synchronous would slow down my applicaton I can get
> comfortably close enough for my purposes with some highly compressible
I also tend to agree; it'd be really handy. pg_clearxlogtail (which I
use) makes me nervous despite the restore tests I've done.
If Pg truncated the WAL files before calling archive_command, and would
accept truncated WAL files on restore, that'd be really useful. Failing
that, packaging pg_clearxlogtail so it was kept in sync with the main Pg
code would be a big step.
In response to
pgsql-hackers by date
|Next:||From: Heikki Linnakangas||Date: 2008-10-31 07:40:04|
|Subject: Re: PG_PAGE_LAYOUT_VERSION 5 - time for change|
|Previous:||From: Simon Riggs||Date: 2008-10-31 06:33:02|
|Subject: Re: BufferAccessStrategy for bulk insert|
pgsql-general by date
|Next:||From: Jodok Batlogg||Date: 2008-10-31 07:49:07|
|Subject: tsearch2 problem|
|Previous:||From: Kyle Cordes||Date: 2008-10-31 04:32:59|
|Subject: Re: Decreasing WAL size effects|