From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: race condition when writing pg_control |
Date: | 2020-05-23 05:39:35 |
Message-ID: | 20200523053935.GB266978@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, May 23, 2020 at 01:00:17AM +0900, Fujii Masao wrote:
> Per my quick check, XLogReportParameters() seems to have the similar issue,
> i.e., it updates the control file without taking ControlFileLock.
> Maybe we should fix this at the same time?
Yeah. It also checks the control file values, implying that we should
have LW_SHARED taken at least at the beginning, but this lock cannot
be upgraded we need LW_EXCLUSIVE the whole time. I am wondering if we
should check with an assert if ControlFileLock is taken when going
through UpdateControlFile(). We have one code path at the beginning
of redo where we don't need a lock close to the backup_label file
checks, but we could just pass down a boolean flag to the routine to
handle that case. Another good thing in having an assert is that any
new caller of UpdateControlFile() would need to think about the need
of a lock.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2020-05-23 06:33:32 | Re: Planning counters in pg_stat_statements (using pgss_store) |
Previous Message | Michael Paquier | 2020-05-23 05:21:50 | Re: Adding missing object access hook invocations |