Re: optimizing pg_upgrade's once-in-each-database steps - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: optimizing pg_upgrade's once-in-each-database steps
Date
Msg-id Zt9JvRyYcFBVhoAJ@nathan
Whole thread Raw
In response to Re: optimizing pg_upgrade's once-in-each-database steps  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: optimizing pg_upgrade's once-in-each-database steps
List pgsql-hackers
On Thu, Sep 05, 2024 at 01:32:34PM +0200, Daniel Gustafsson wrote:
> I've read and tested through the latest version of this patchset and I think
> it's ready to go in.

Thanks for reviewing.  I'm aiming to commit it later this week.

> The one concern I have is that tasks can exit(1) on libpq
> errors tearing down perfectly functional connections without graceful shutdown.
> Longer term I think it would make sense to add similar exit handler callbacks
> to the ones in pg_dump for graceful cleanup of connections.  However, in order
> to keep goalposts in clear view I don't think this patch need to have it, but
> it would be good to consider once in.

This did cross my mind.  I haven't noticed any problems in my testing, and
it looks like there are several existing places in pg_upgrade that call
pg_fatal() with open connections, so I'm inclined to agree that this is a
nice follow-up task that needn't hold up this patch set.

> Spotted a small typo in the comments:
> 
> +     * nothing to process.  This is primarily intended for the inital step in
> s/inital/initial/

Will fix.

-- 
nathan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: access numeric data in module
Next
From: Maciek Sakrejda
Date:
Subject: Re: Opinion poll: Sending an automated email to a thread when it gets added to the commitfest