| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | wangchuanting <wangchuanting(at)huawei(dot)com> |
| Cc: | PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: Re: BUG #14680: startup process on standby encounter a deadlock of TwoPhaseStateLock when redo 2PC xlog |
| Date: | 2017-06-06 04:17:35 |
| Message-ID: | CAB7nPqQthLP9GvD2242epHKOBkDMd+03tSuFvK3cVZsGarQyWA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Mon, Jun 5, 2017 at 8:32 PM, wangchuanting <wangchuanting(at)huawei(dot)com> wrote:
> I don't understand why the patch remove TwoPhaseStateLock in MarkAsPrepared.
This one is on purpose, no low-level routines in this patch acquire
TwoPhaseStateLock. Logically I agree that it does not change much
but... You wrote something below about that.
> if so:
> 1. does it need remove lock acquire in MarkAsPreparing also?
No, MarkAsPreparing() is used only in the non-redo code path.
> 2. MarkAsPrepared will call ProcArrayAdd, and in ProcArrayAdd it acquires
> ProcArrayLock, we should carefully handle the lock sequence about these two
> locks.
And this gives a reason to not complicate our lives.
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| 2pc-redo-lwlock-fix-v3.patch | application/octet-stream | 8.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mike Palmiotto | 2017-06-06 18:57:22 | Re: [BUGS] BUG #14682: row level security not work with partitioned table |
| Previous Message | Andres Freund | 2017-06-05 23:12:51 | Re: BUG #14687: pg_xlogdump does only count "main data" for record length and leading to incorrect statistics |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2017-06-06 04:18:46 | Re: Challenges preventing us moving to 64 bit transaction id (XID)? |
| Previous Message | Craig Ringer | 2017-06-06 04:15:15 | Re: pg_dump issues |