From: Nathan Bossart <nathandbossart@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Bossart, Nathan <bossartn@amazon.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Maxim Orlov <orlovmg@gmail.com>
Cc: Amul Sul <sulamul@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: O(n) tasks cause lengthy startups and checkpoints
Date: Thu, 17 Feb 2022 14:58:38 -0800
Message-ID: <20220217225838.GA3292179@nathanxps13> (raw)
In-Reply-To: <20220217222829.lndzwq72fh4v34c2@alap3.anarazel.de>
References: <83A7426F-A7B6-4A10-A8F0-179AE30B871D@amazon.com>
<20220211180249.GA1886051@nathanxps13>
<20220217005057.GA3201038@nathanxps13>
<20220217015052.2y3wxibeommk37ey@alap3.anarazel.de>
<20220217041404.GA3243546@nathanxps13>
<20220217065938.x2esfdppzypegn5j@alap3.anarazel.de>
<20220217182337.GA3247866@nathanxps13>
<20220217192709.eyf2cnymhxqsals7@alap3.anarazel.de>
<20220217210022.GA3248793@nathanxps13>
<20220217222829.lndzwq72fh4v34c2@alap3.anarazel.de>
On Thu, Feb 17, 2022 at 02:28:29PM -0800, Andres Freund wrote:
> As far as I understand, the primary concern are logical decoding serialized
> snapshots, because a lot of them can accumulate if there e.g. is an old unused
> / far behind slot. It should be easy to reduce the number of those snapshots
> by e.g. eliding some redundant ones. Perhaps we could also make backends in
> logical decoding occasionally do a bit of cleanup themselves.
>
> I've not seen reports of the number of mapping files to be an real issue?
I routinely see all four of these tasks impacting customers, but I'd say
the most common one is the temporary file cleanup. Besides eliminating
some redundant files and having backends perform some cleanup, what do you
think about skipping the logical decoding cleanup during
end-of-recovery/shutdown checkpoints? This was something that Bharath
brought up a while back [0]. As I noted in that thread, startup and
shutdown could still take a while if checkpoints are regularly delayed due
to logical decoding cleanup, but that might still help avoid a bit of
downtime.
> The improvements around deleting temporary files and serialized snapshots
> afaict don't require a dedicated process - they're only relevant during
> startup. We could use the approach of renaming the directory out of the way as
> done in this patchset but perform the cleanup in the startup process after
> we're up.
Perhaps this is a good place to start. As I mentioned above, IME the
temporary file cleanup is the most common problem, so I think even getting
that one fixed would be a huge improvement.
[0] https://postgr.es/m/CALj2ACXkkSL8EBpR7m%3DMt%3DyRGBhevcCs3x4fsp3Bc-D13yyHOg%40mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, andres@anarazel.de, bossartn@amazon.com, bharath.rupireddyforpostgres@gmail.com, orlovmg@gmail.com, sulamul@gmail.com, bruce@momjian.us, robertmhaas@gmail.com
Subject: Re: O(n) tasks cause lengthy startups and checkpoints
In-Reply-To: <20220217225838.GA3292179@nathanxps13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox