| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: logical decoding of two-phase transactions |
| Date: | 2017-02-01 21:35:42 |
| Message-ID: | CAMsr+YEDR3OHhULKa_Xk+JKSvCajSSjgKqzF-EaPKNyUDEB9QQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2 Feb. 2017 08:32, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Also, including the GID in the WAL for each COMMIT/ABORT PREPARED
> doesn't seem inordinately expensive to me.
I'm confused ... isn't it there already? If not, how do we handle
reconstructing 2PC state from WAL at all?
Right. Per my comments uothread I don't see why we need to add anything
more to WAL here.
Stas was concerned about what happens in logical decoding if we crash
between PREPSRE TRANSACTION and COMMIT PREPARED. But we'll always go back
and decode the whole txn again anyway so it doesn't matter.
We can just track it on ReorderBufferTxn when we see it at PREPARE
TRANSACTION time.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-02-01 21:38:59 | Re: [COMMITTERS] pgsql: Make psql's \set display variables in alphabetical order. |
| Previous Message | Alvaro Herrera | 2017-02-01 21:31:44 | Re: Patch: Write Amplification Reduction Method (WARM) |