Re: [PATCHES] Forcing current WAL file to be archived - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] Forcing current WAL file to be archived
Date
Msg-id 19673.1155132288@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] Forcing current WAL file to be archived  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [PATCHES] Forcing current WAL file to be archived
Re: [PATCHES] Forcing current WAL file to be archived
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> Something Hannu wrote has just reminded me that
> pg_current_xlog_location() returns the current Insert pointer rather
> than the current Write pointer.
> That would not be useful for streaming xlog records would it?

Good point.

> Methinks it should be the Write pointer all of the time, since I can't
> think of a valid reason for wanting to know where the Insert pointer is
> *before* we've written to the xlog file. Having it be the Insert pointer
> could lead to some errors.

However the start/stop_backup functions return the Insert pointer.
I can see scripts getting confused if pg_current_xlog_location reports
something less than what they just got from pg_stop_backup.

Is there value in exposing both pointers?  (Maybe not, it'll just cause
confusion probably.)

Another option is to have pg_current_xlog_location force a write (but
not fsync) as far as the Insert pointer it's about to return.  This
would eliminate any issues about inconsistency between results, but
perhaps there's too much performance penalty.

I'm not necessarily against your suggestion, just trying to be sure
we've thought about all the options.

            regards, tom lane

pgsql-hackers by date:

Previous
From: Richard Huxton
Date:
Subject: Re: proposal for PL packages for 8.3.
Next
From: "korryd@enterprisedb.com"
Date:
Subject: Re: 8.2 features status