Re: Forcing current WAL file to be archived

On Wed, 2006-08-09 at 10:04 -0400, Tom Lane wrote:
> 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.

Hannu's Use Case is to have the function called regularly from an
external polling agent. If we don't do the write it could be possible in
some circumstances for an XLogWrite to be delayed for some time if we
have both large wal_buffers and period of few commits, whereas we might
want to have the writes be fairly regular to support regular streaming.
So I do see there is a reasonable case for performing a write.

The way we have XLogWrite now, I would want that write to be a
"flexible" write, which would leave us in the position that calling
pg_current_xlog_location() would return something logically between the
Insert pointer and the immediately prior Write pointer (even though very
often there would be no difference at all).

I'm inclined to say we should add a flexible write (i.e.
XLogWrite(WriteRqst, true)) to pg_xlogfile_name_offset() and ignore the
esoteric difference between the return value and the Insert pointer.

I'm not clear how pg_xlogfile_name_offset() would ever return a
different answer to pg_stop_backup() - surely we just forcibly moved the
Insert and the Write pointer forwards together, so you'll get the same
answer from each.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com