Re: should check interrupts in BuildRelationExtStatistics ? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: should check interrupts in BuildRelationExtStatistics ?
Date
Msg-id CA+TgmoY=Q9C9n=P=e8gTqLFTLza89t-cz+X-16LPaxq2+=qY2g@mail.gmail.com
Whole thread Raw
In response to Re: should check interrupts in BuildRelationExtStatistics ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: should check interrupts in BuildRelationExtStatistics ?
List pgsql-hackers
On Sun, May 8, 2022 at 11:36 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael@paquier.xyz> writes:
> > How long can the backend remain unresponsive?  I don't think that
> > anybody would object to the addition of some CHECK_FOR_INTERRUPTS() in
> > areas where it would be efficient to make the shutdown quicker, but
> > we need to think carefully about the places where we'd want to add
> > these.
>
> CHECK_FOR_INTERRUPTS is really quite cheap, just a test-and-branch.
> I wouldn't put it in a *very* tight loop, but one test per row
> processed while gathering stats is unlikely to be a problem.

+1. If we're finding things stalling that would be fixed by adding
CHECK_FOR_INTERRUPTS(), we should generally just add it. In the
unlikely event that this causes a performance problem, we can try to
figure out some other solution, but not responding to interrupts isn't
the right way to economize.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:
Next
From: Bharath Rupireddy
Date:
Subject: Re: Can postgres ever delete the recycled future WAL files to free-up disk space if max_wal_size is reduced or wal_recycle is set to off?