From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Assorted improvements in pg_dump
Date: Thu, 21 Oct 2021 10:53:58 -0400
Message-ID: <2408275.1634828038@sss.pgh.pa.us> (raw)
In-Reply-To: <20211021142852.GD741@telsasoft.com>
References: <20211021142852.GD741@telsasoft.com>
Justin Pryzby <pryzby@telsasoft.com> writes:
> On Wed, Oct 20, 2021 at 05:14:45PM -0400, Tom Lane wrote:
>> Arguably, 0003 is a bug fix that we should consider back-patching.
>> However, I've not heard field reports of the problems it fixes,
>> so maybe there's no need to bother.
> FYI, I see this issue happen in production environment.
> I never reported it, since I think it's a documented issue, and it's no great
> problem, so long as it runs the next day. But it'd be a pain to find that the
> backup was incomplete when we needed it. Also, I use the backups to migrate to
> new servers, and it would be a pain to start the job at a calculated time
> expecting it to finish at the beginning of a coordinated maintenance window,
> but then discover that it had failed and needs to be rerun with fingers
> crossed.
Yeah, if you're dropping tables all the time, pg_dump is going to have
a problem with that. The fix I'm suggesting here would only ensure
that you get a "clean" failure at the LOCK TABLE command --- but from
an operational standpoint, that's little improvement.
The natural response is to consider retrying the whole dump after a lock
failure. I'm not sure if it'd be practical to do that within pg_dump
itself, as opposed to putting a loop in whatever script calls it.
regards, tom lane
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: tgl@sss.pgh.pa.us, pryzby@telsasoft.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Assorted improvements in pg_dump
In-Reply-To: <2408275.1634828038@sss.pgh.pa.us>
* 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