Re: [PATCH 8/8] Introduce wal decoding via catalog timetravel
Christopher Browne <cbbrowne@gmail.com>
From: Christopher Browne <cbbrowne@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Greg Stark <stark@mit.edu>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <peter@2ndquadrant.com>, Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org, hlinnakangas@vmware.com
Date: 2012-10-11T22:41:00Z
Lists: pgsql-hackers
On Wed, Oct 10, 2012 at 10:26 PM, Bruce Momjian <bruce@momjian.us> wrote: > How does Slony write its changes without causing serialization replay > conflicts? It uses a sequence to break any ordering conflicts at the time that data is inserted into its log tables. If there are two transactions, A and B, that were "fighting" over a tuple on the origin, then either: a) A went first, B went second, and the ordering in the log makes that order clear; b) A succeeds, then B fails, so there's no conflict; c) A is doing its thing, and B is blocked behind it for a while, then A fails, and B gets to go through, and there's no conflict. Switch A and B as needed. The sequence that is used establishes what is termed a "compatible ordering." There are multiple possible compatible orderings; ours happen to interleave transactions together, with the sequence guaranteeing absence of conflict. If we could get commit orderings, then a different but still "compatible ordering" would be to have each transaction establish its own internal sequence, and apply things in order based on (commit_tx_order, sequence_within). -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Move "hot" members of PGPROC into a separate PGXACT array.
- ed0b409d2234 9.2.0 cited