On Fri, Sep 30, 2011 at 4:07 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Fri, Sep 30, 2011 at 8:57 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Fri, Sep 30, 2011 at 3:22 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> If the feature could not be done another way, easily, I might agree.
>>
>> I don't see that you've offered a reasonable alternative. The
>> alternative proposals that you proposed don't appear to me to be
>> solving the same problem. AIUI, the requested feature is to be able
>> to get, on the master, the timestamp of the last commit or abort, just
>> as we can already get the timestamp of the last commit or abort
>> replayed on the standby. Nothing you WAL log and no messages you send
>> to the standby are going to accomplish that goal.
>
> The goal of the OP was to find out the replication delay. This
> function was suggested, but its not the only way.
>
> My alternative proposals solve the original problem in a better way.
As far as I can see, they don't solve the problem at all. Your
proposals involve sending additional information from the master to
the slave, but the slave already knows both its WAL position and the
timestamp of the transaction it has most recently replayed, because
the startup process on the slave tracks that information and publishes
it in shared memory. On the master, however, only the WAL position is
centrally tracked; the transaction timestamps are not.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
