Re: optimizing pg_upgrade's once-in-each-database steps

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: optimizing pg_upgrade's once-in-each-database steps
Date: 2024-07-01 19:58:16
Message-ID: CA+TgmoaBof36-ZuRWtu=+8rnhGTNQFFGNcmVB0x3aQawfc_JxA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 1, 2024 at 3:47 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> 0001 introduces a new API for registering callbacks and running them in
> parallel on all databases in the cluster. This new system manages a set of
> "slots" that follow a simple state machine to asynchronously establish a
> connection and run the queries. It uses system() to wait for these
> asynchronous tasks to complete. Users of this API only need to provide two
> callbacks: one to return the query that should be run on each database and
> another to process the results of that query. If multiple queries are
> required for each database, users can provide multiple sets of callbacks.

I do really like the idea of using asynchronous communication here. It
should be significantly cheaper than using multiple processes or
threads, and maybe less code, too. But I'm confused about why you
would need or want to use system() to wait for asynchronous tasks to
complete. Wouldn't it be something like select()?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2024-07-01 20:00:53 Re: optimizing pg_upgrade's once-in-each-database steps
Previous Message Ranier Vilela 2024-07-01 19:58:06 Re: Avoid incomplete copy string (src/backend/access/transam/xlog.c)