Re: WAL insert delay settings

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WAL insert delay settings
Date: 2019-02-14 16:06:24
Message-ID: 20190214160624.557qp5qne2qf3ohx@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-02-14 16:16:05 +0100, Peter Eisentraut wrote:
> On 13/02/2019 16:40, Andres Freund wrote:
> > On February 13, 2019 4:39:21 PM GMT+01:00, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> >> On 13/02/2019 13:18, Andres Freund wrote:
> >>> But I don't think the way you did it is acceptable - we can't just
> >> delay while holding buffer locks, in critical sections, while not
> >> interruptible.
> >>
> >> The code I added to XLogInsertRecord() is not inside the critical
> >> section.
> >
> > Most callers do xlog insertions inside crit sections though.
>
> Is it a problem that pg_usleep(CommitDelay) is inside a critical section?

Well: We can't make things sleep for considerable time while holding
crucial locks and not make such sleeps interruptible. And holding
lwlocks will make it noninterruptible (but still it could throw an
error), but with crit sections, we can't even error out if we somehow
got that error.

Consider throttled code writing to a popular index or bree page - they'd
suddenly be stalled and everyone else would also queue up in an
uninterruptible manner via lwlocks. You'd throttle the whole system.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-02-14 16:14:34 Re: WAL insert delay settings
Previous Message Stephen Frost 2019-02-14 16:02:24 Re: WAL insert delay settings