Re: [REVIEW] pg_last_xact_insert_timestamp
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Date: 2011-12-14T16:06:08Z
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 →
-
Treat 2PC commit/abort the same as regular xacts in recovery.
- e74e0906fad5 9.5.0 cited
Attachments
- primary_keepalive.v2.patch (text/x-patch) patch v2
On Mon, Dec 12, 2011 at 12:17 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Sat, Dec 10, 2011 at 12:29 PM, Greg Smith <greg@2ndquadrant.com> wrote: > >> "We can send regular special messages from WALSender to WALReceiver that do >> not form part of the WAL stream, so we don't bulk >> up WAL archives. (i.e. don't use "w" messages)." >> >> Here's my understanding of how this would work. > > Let me explain a little more and provide a very partial patch. > > We define a new replication protocol message 'k' which sends a > keepalive from primary to standby when there is no WAL to send. The > message does not form part of the WAL stream so does not bloat WAL > files, nor cause them to fill when unattended. > > Keepalives contain current end of WAL and a current timestamp. > > Keepalive processing is all done on the standby and there is no > overhead on a primary which does not use replication. There is a > slight overhead on primary for keepalives but this happens only when > there are no writes. On the standby we already update shared state > when we receive some data, so not much else to do there. > > When the standby has applied up to the end of WAL the replication > delay is receipt time - send time of keepalive. Patch introduces regular keepalives from WALsender to WALreceiver, using a new protocol message 'k'. These are sent at intervals of a fraction of replication_delay or 10s if not set, whenever no WAL records have been sent recently. Patch exposes info used for standby_delay calculation as used in 9.0+ In addition introduces direct calculations of replication apply delay and replication transfer latency, both in ms. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services