| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Fujii Masao <fujii(at)postgresql(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql: Get rid of the dedicated latch for signaling the startup process |
| Date: | 2020-11-04 13:17:41 |
| Message-ID: | b3265f23-f47c-6ab1-e0e7-2df0c3e4e9e1@iki.fi |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
On 04/11/2020 14:03, Fujii Masao wrote:
>> I'm thinking to remove the following code to fix this issue. Thought?
>>
>> /*
>> * We don't need the latch anymore. It's not strictly necessary to reset
>> * it to NULL, but let's do it for the sake of tidiness.
>> */
>> if (ArchiveRecoveryRequested)
>> XLogCtl->recoveryWakeupLatch = NULL;
That should work, but it seems a bit sloppy to leave it pointing to a
latch that belongs to a random process though.
> Or ISTM that WakeupRecovery() should set the latch only when the latch
> has not been reset to NULL yet.
Got to be careful with race conditions, if the latch is set to NULL at
the same time that WakeupRecovery() is called.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-11-04 16:26:04 | pgsql: Remove useless entries for aggregate functions from fmgrtab.c. |
| Previous Message | Fujii Masao | 2020-11-04 12:51:53 | pgsql: Fix segmentation fault that commit ac22929a26 caused. |