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
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) |