Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node

Aidan Van Dyk <aidan@highrise.ca>

From: Aidan Van Dyk <aidan@highrise.ca>

To: Andres Freund <andres@2ndquadrant.com>

Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>

Date: 2012-06-20T19:41:03Z

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 Wed, Jun 20, 2012 at 3:27 PM, Andres Freund <andres@2ndquadrant.com> wrote:

>> OK, so in this case, I still don't see how the "origin_id" is even enough.
>>
>> C applies the change originally from A (routed through B, because it's
>> faster).  But when it get's the change directly from A, how does it
>> know to *not* apply it again?
> The lsn of the change.

So why isn't the LSN good enough for when C propagates the change back to A?

Why does A need more information than C?

a.


-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.