Re: Forcing current WAL file to be archived

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Wed, 2006-08-09 at 10:04 -0400, Tom Lane wrote:
>> 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.

> 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.

Now the other side of that coin is that any commit forces a write anyway.
So any data that would hypothetically be written by pg_current_xlog_location
would be uncommitted data, which is maybe not so important to write yet?
Anyway, it's easy enough for a polling program to force a write if it
wants to.

> 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 really don't want that; it makes it impossible to define what the
function is actually giving you. It's not an "esoteric difference".

> 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.

Hmm ... I guess given the just-added behavior of forcing an xlog switch,
that's probably true now, but it wasn't before.

Anyway, after further thought I've concluded that we really should
supply something that returns the Insert pointer, as this would be
useful for debugging and system-monitoring purposes. It's clear however
that we also need something that returns the Write pointer, as that's
what's needed for partial log-shipping. So my vote is for two
functions, both read-only (and hence not superuser-only). Not sure
what to name them exactly.

regards, tom lane