From: | Paul Guo <paulguo(at)gmail(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sync request forward function ForwardSyncRequest() might hang for some time in a corner case? |
Date: | 2021-05-28 03:43:09 |
Message-ID: | CABQrize5m7vnSLm+Lo1rjcU5W9G3AU5shkX8XombnCqwuZFw6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 27, 2021 at 10:22 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>
> On Thu, May 27, 2021 at 10:05 PM Paul Guo <paulguo(at)gmail(dot)com> wrote:
> >
> > Also note that ForwardSyncRequest() does wake up the checkpointer if
> > it thinks the requests in shared memory are "too full", but does not
> > wake up when the request is actually full. This does not seem to be reasonable.
> > See below code in ForwardSyncRequest
> >
> > /* If queue is more than half full, nudge the checkpointer to empty it */
> > too_full = (CheckpointerShmem->num_requests >=
> > CheckpointerShmem->max_requests / 2);
> >
> > /* ... but not till after we release the lock */
> > if (too_full && ProcGlobal->checkpointerLatch)
> > SetLatch(ProcGlobal->checkpointerLatch);
>
> Ah indeed. Well it means that the checkpointer it woken up early
> enough to avoid reaching that point. I'm not sure that it's actually
> possible to reach a point where the list if full and the checkpointer
> is sitting idle.
In theory this is possible (when the system is under heavy parallel write)
else we could remove that part code (CompactCheckpointerRequestQueue())
:-), though the chance is not high.
If we encounter this issue those affected queries would suddenly hang
until the next checkpointer wakeup.
From | Date | Subject | |
---|---|---|---|
Next Message | Ajin Cherian | 2021-05-28 03:44:12 | Re: [HACKERS] logical decoding of two-phase transactions |
Previous Message | Amit Kapila | 2021-05-28 03:23:57 | Re: Parallel Inserts in CREATE TABLE AS |