From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Nikhil Sontakke <nikhils(at)2ndquadrant(dot)com>, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
Subject: | Re: Failed recovery with new faster 2PC code |
Date: | 2017-04-19 02:29:08 |
Message-ID: | CAB7nPqQUzRQrSxycnFsWX8=ztyQrt_MXTPjN=R-864Yhe8M=Ww@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 19, 2017 at 11:09 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> Would this bug have been seen in a replica server in the absence of crashes,
> or was it only vulnerable during crash recovery rather than streaming
> replication?
This issue could have been seen on a streaming standby as well,
letting around a TwoPhaseState impacts as well their linked PGPROC so
CLOG truncation would have been messed up as well. That's also the
case of the first issue involving as well incorrect XID updates,
though the chances to see it are I think lower as only the beginning
of recovery was impacted.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2017-04-19 02:39:00 | Re: Should pg_current_wal_location() become pg_current_wal_lsn() |
Previous Message | Petr Jelinek | 2017-04-19 02:25:42 | Use sync commit for logical replication apply in TAP tests |