Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>, Daniel Farina <daniel@heroku.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2012-06-19T22:02:06Z
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 →
-
Don't waste the last segment of each 4GB logical log file.
- dfda6ebaec67 9.3.0 cited
-
Stamp HEAD as 9.3devel.
- bed88fceac04 9.3.0 cited
-
Wake WALSender to reduce data loss at failover for async commit.
- 2c8a4e9be273 9.2.0 cited
-
Make the visibility map crash-safe.
- 503c7305a1e3 9.2.0 cited
On 20 June 2012 04:31, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > I've done a lot of MM replication, > and so far have not had to use a topology which allowed loops. The proposal is to use WAL to generate the logical change stream. That has been shown in testing to be around x4 faster than having a separate change stream, which must also be WAL logged (as Jan noted). If we use WAL in this way, multi-master implies that the data will *always* be in a loop. So in any configuration we must be able to tell difference between changes made by one node and another. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services