Re: Forcing current WAL file to be archived - Mailing list pgsql-patches

From Tom Lane
Subject Re: Forcing current WAL file to be archived
Date
Msg-id 20239.1155135458@sss.pgh.pa.us
Whole thread Raw
In response to Re: Forcing current WAL file to be archived  (Hannu Krosing <hannu@skype.net>)
Responses Re: Forcing current WAL file to be archived  (Hannu Krosing <hannu@skype.net>)
List pgsql-patches
Hannu Krosing <hannu@skype.net> writes:
> Ühel kenal päeval, K, 2006-08-09 kell 12:56, kirjutas Simon Riggs:
>> 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.

> What is the difference ?

Insert points to the next byte to be written within the internal WAL
buffers.  The byte(s) preceding it haven't necessarily gotten out of
those buffers yet.  Write points to the end of what we've actually
written to the kernel, and there's also a Flush pointer that points
to the end of what we believe is down on disk.

Simon's point is that if you're going to use pg_current_xlog_location()
to control partial shipping of xlog files, you probably want to know
about the Write location, because that indicates the limit of what
is visible to an external process.

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Forcing current WAL file to be archived
Next
From: Zoltan Boszormenyi
Date:
Subject: Re: IDENTITY/GENERATED columns