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: Robert Haas <robertmhaas@gmail.com>

Cc: Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>, Daniel Farina <daniel@heroku.com>

Date: 2012-06-19T21:58:53Z

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 05:46, Robert Haas <robertmhaas@gmail.com> wrote:

> It seems to me that you are intent on using the WAL stream as the
> logical change stream.  I think that's a bad design.  Instead, you
> should extract changes from WAL and then ship them around in a format
> that is specific to logical replication.

The proposal is to read the WAL in order to generate LCRs. The
information needs to be in the original data in order to allow it to
be passed onwards.

In a multi-master config there will be WAL records with many origin
node ids at any time, so this information must be held at WAL record
level not page level.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services