Horton

Re: [REVIEW] pg_last_xact_insert_timestamp

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Greg Smith <greg@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2011-12-12T14:53:26Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Treat 2PC commit/abort the same as regular xacts in recovery.

On Mon, Dec 12, 2011 at 9:51 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Mon, Dec 12, 2011 at 2:47 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Mon, Dec 12, 2011 at 9:24 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> On Mon, Dec 12, 2011 at 1:45 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>>> It also strikes me that anything
>>>> that is based on augmenting the walsender/walreceiver protocol leaves
>>>> anyone who is using WAL shipping out in the cold.  I'm not clear from
>>>> the comments you or Simon have made how important you think that use
>>>> case still is.
>>>
>>> archive_timeout > 0 works just fine at generating files even when
>>> quiet, or if it does not, it is a bug.
>>>
>>> So I don't understand your comments, please explain.
>>
>> If the standby has restore_command set but not primary_conninfo, then
>> it will never make a direct connection to the master.  So anything
>> that's based on extending that protocol won't get used in that case.
>
> Got that, but now explain the reason for saying such people are "out
> in the cold".

By that I only meant that if we add a lag-monitoring feature that
relies on the streaming replication protocol, then people who are not
using the streaming replication replication protocol will be unable to
monitor lag (or at least, the will be unable to do it any better than
they can do it today).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company