| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Subject: | Re: Race conditions with checkpointer and shutdown |
| Date: | 2019-04-16 22:59:37 |
| Message-ID: | CA+TgmoZyTLE1WDaw105bxCTj9PnG2NvL60O60tDy9wTvj+mK1A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 16, 2019 at 6:45 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Do we need to think harder about establishing rules for multiplexed
> use of the process latch? I'm imagining some rule like "if you are
> not the outermost event loop of a process, you do not get to
> summarily clear MyLatch. Make sure to leave it set after waiting,
> if there was any possibility that it was set by something other than
> the specific event you're concerned with".
Hmm, yeah. If the latch is left set, then the outer loop will just go
through an extra and unnecessary iteration, which seems fine. If the
latch is left clear, then the outer loop might miss a wakeup intended
for it and hang forever.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-04-17 00:05:36 | Re: Race conditions with checkpointer and shutdown |
| Previous Message | Robert Haas | 2019-04-16 22:55:31 | Re: hyrax vs. RelationBuildPartitionDesc |