Re: Corner case in xlog stuff: what happens exactly at a seg boundary?

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Corner case in xlog stuff: what happens exactly at a seg boundary?
Date: 2006-08-07 19:11:26
Message-ID: 20060807191126.GB40481@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 05, 2006 at 11:59:40PM -0400, Tom Lane wrote:
> I wrote:
> > Rather than expecting user-level scripts to get this corner case
> > right, I suggest that we ought to modify pg_stop_backup and friends
> > so that what they return is the last used byte address of WAL, not
> > the first unused byte address as now. Then, blindly extracting
> > the filename will give the right answer about which file to archive,
> > even in the boundary case.
>
> After further thought I desisted from that plan: changing the result
> convention of existing functions like pg_stop_backup() will break any
> existing archiving scripts that do get it right. Instead, we can put
> the boundary-case logic into the new functions that extract a filename
> from the WAL location string that the action functions return.

Should we ask users if anyone is currently doing this? It seems pretty
ugly to have most functions return the last used WAL byte with only
stop_backup returning the first unused byte. If nothing else we should
at least plan on depricating this, probably by having a
pg_stop_backup(boolean) that lets the user specify which behavior they
want, and eventually switching pg_stop_backup() to the new behavior.

Ultimately, I'd bet that the vast majority of scripts out there blindly
do the wrong thing today and the authors aren't even aware of the issue.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2006-08-07 19:25:27 Re: buildfarm - make check failures for leveret on 8.0
Previous Message Jeremy Drake 2006-08-07 18:58:19 Re: buildfarm - make check failures for leveret on 8.0