From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
Subject: | Re: Speedup twophase transactions |
Date: | 2016-04-12 22:04:18 |
Message-ID: | CAB7nPqTAK=NA4HURt7GXxGeUOOhWq6OgY8rGEWkgp=mqL5Lo7A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 13, 2016 at 1:53 AM, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> wrote:
>> On 12 Apr 2016, at 15:47, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
>>
>> It looks to be the case... The PREPARE phase replayed after the
>> standby is restarted in recovery creates a series of exclusive locks
>> on the table created and those are not taken on HEAD. Once those are
>> replayed the LOCK_STANDBY record is conflicting with it. In the case
>> of the failure, the COMMIT PREPARED record cannot be fetched from
>> master via the WAL stream so the relation never becomes visible.
>
> Yep, it is. It is okay for prepared xact hold a locks for created/changed tables,
> but code in standby_redo() was written in assumption that there are no prepared
> xacts at the time of recovery. I’ll look closer at checkpointer code and will send
> updated patch.
>
> And thanks again.
That's too late for 9.6 unfortunately, don't forget to add that in the next CF!
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2016-04-12 22:31:19 | Re: Choosing parallel_degree |
Previous Message | Tom Lane | 2016-04-12 21:40:25 | Re: pg_upgrade error regarding hstore operator |