From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, Hannu Krosing <hannu(at)skype(dot)net> |
Subject: | Re: Forcing current WAL file to be archived |
Date: | 2006-08-09 14:04:48 |
Message-ID: | 19673.1155132288@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | korryd@enterprisedb.com | 2006-08-09 14:20:31 | Re: 8.2 features status |
Previous Message | Richard Huxton | 2006-08-09 14:01:13 | Re: proposal for PL packages for 8.3. |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-08-09 14:57:38 | Re: Forcing current WAL file to be archived |
Previous Message | Hannu Krosing | 2006-08-09 13:52:25 | Re: Forcing current WAL file to be archived |