Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1safpt-00AUmc-PR for pgsql-hackers@arkaria.postgresql.org; Sun, 04 Aug 2024 18:20:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1safpr-009tTa-Aa for pgsql-hackers@arkaria.postgresql.org; Sun, 04 Aug 2024 18:20:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1safpq-009tTS-Sn for pgsql-hackers@lists.postgresql.org; Sun, 04 Aug 2024 18:20:02 +0000 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1safpo-0033Wn-5T for pgsql-hackers@postgresql.org; Sun, 04 Aug 2024 18:20:01 +0000 Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-42803bbf842so88816605e9.1 for ; Sun, 04 Aug 2024 11:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722795598; x=1723400398; darn=postgresql.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ldiNJ/EnWQkLHKou6bzqDNi8GfPxIboKslNxSENAr78=; b=c1gUnjC3U/6YNZt3g7e6a5oARVW096q0QiYl6E6nf/9FxaVi2CDOP08H9KU2pbDIh7 ZCjG79EFuFsWBY7GWyuiE7QqbXN7qd3HunEOkJyJc+2ChDAAHBzBV+HSvzKa63h8xQr6 7XvzC1RXpjh1UPeD4Etn8R1rQ7vQT2/Haozm4nB+v6P6RBn4zEEppImcJ4jK/JW87m5s Au5MGTjYCW1m5O+JiJxEmB+lXS8BR/IHAi5H3W/YJxaeIZQsXyspbCCRw4qCjmeABWlw biAVCFggRgOwgQFLMm50WXx1zvYj/ULcTm//xf8Noibbzqp6Ofb8M6bueeKvAS9kfXQe EoyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722795598; x=1723400398; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ldiNJ/EnWQkLHKou6bzqDNi8GfPxIboKslNxSENAr78=; b=B8GAM0D3FHjPNYAwghYPFzMflpy3IZCJsm24agXCRW0K+SHQTv33OO5Rmvl0d1h3MN f8smx0CfhPre4KlBJXScui7u8rsiWhaXLwXTcHPKmvdd4lyQ5ByJMI5IPU/GhRGUTw+w Pb3JqojP99O5vTx9JzV4cEYxiU14Rq0eLLc369sq1990bVPMcB6NrRbWvmnq2iq4a3LZ UMu5VFNHVb7RY4niYZvcDqcLIiusZ4hbwSCR/jkQwkJTaxgRHxhZ8KxqGaXGO7iJ2S+8 7Q5RwJyE/3AxEVyaeU0CW1+WlVFbPnlTi6bCCEjAZRcr2RCFcHsXlXqwH+gqETCAbyBw Hn2Q== X-Forwarded-Encrypted: i=1; AJvYcCWbw81Tj21Yj640C0MVyYp2rotr46p76KGbqHTg1gcv1FIP1x8zAXan7OZrQVe6e+x6FAGKrbpNPzqThdjN@postgresql.org X-Gm-Message-State: AOJu0Yy8u7hiIlWllo8QEXcwAPGCwFLISc5faEtV+9WTnvEXZ1SfDQ/U erkJ9cxShlG4zCod7jx8Gi4qw0/H2UG7yXzvCIkT8a6L7fK+x3V3 X-Google-Smtp-Source: AGHT+IHbjC899Kc/T7yYs0ShB73AVGA74Di5ycFmdLAxUrYkrvKig5EZOyGDy1plspSXxtXOl/TukQ== X-Received: by 2002:a05:600c:5489:b0:426:6b14:1839 with SMTP id 5b1f17b1804b1-428e6a5f361mr94492235e9.0.1722795598049; Sun, 04 Aug 2024 11:19:58 -0700 (PDT) Received: from ?IPV6:2a01:4b00:c00c:a500:8255:347a:5b8f:b7e2? ([2a01:4b00:c00c:a500:8255:347a:5b8f:b7e2]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-428e6dfbc3bsm108667815e9.11.2024.08.04.11.19.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 Aug 2024 11:19:57 -0700 (PDT) Message-ID: <60cbc507-4c36-4037-9af7-028b1c8455b5@gmail.com> Date: Sun, 4 Aug 2024 19:19:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: optimizing pg_upgrade's once-in-each-database steps To: Nathan Bossart Cc: Daniel Gustafsson , Robert Haas , Jeff Davis , PostgreSQL Hackers References: <26742670-9539-4F30-B6FA-9C1DB743BC23@yesql.se> <4493D323-9726-48F7-A702-E71FB991F76B@yesql.se> <10c1c8dd-4685-46d4-80be-56bdfca8659a@gmail.com> Content-Language: en-US From: Ilya Gladyshev In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 01.08.2024 22:41, Nathan Bossart wrote: > Here is a new patch set. Besides rebasing, I've added the recursive call > to process_slot() mentioned in the quoted text, and I've added quite a bit > of commentary to async.c. That's much better now, thanks! Here's my code review, note that I haven't tested the patches yet: +void +async_task_add_step(AsyncTask *task, +                    AsyncTaskGetQueryCB query_cb, +                    AsyncTaskProcessCB process_cb, bool free_result, +                    void *arg) Is there any reason to have query as a callback function instead of char *? From what I see right now, it doesn't give any extra flexibility, as the query has to be static anyway (can't be customized on a per-database basis) and will be created once before all the callbacks are run. While passing in char * makes the API simpler, excludes any potential error of making the query dependent on the current database and removes the unnecessary malloc/free of the static strings. +static void +dispatch_query(const ClusterInfo *cluster, AsyncSlot *slot, +               const AsyncTask *task) +{ +    ... +    if (!PQsendQuery(slot->conn, cbs->query)) +        conn_failure(slot->conn); +} This will print "connection failure: connection pointer is NULL", which I don't think makes a lot of sense to the end user. I'd prefer something like pg_fatal("failed to allocate a new connection").      if (found) -        pg_fatal("Data type checks failed: %s", report.data); +    { +        pg_fatal("Data type checks failed: %s", data_type_check_report.data); +        termPQExpBuffer(&data_type_check_report); +    } `found` should be removed and replaced with `data_type_check_failed`, as it's not set anymore. Also the termPQExpBuffer after pg_fatal looks unnecessary. +static bool *data_type_check_results; +static bool data_type_check_failed; +static PQExpBufferData data_type_check_report; IMO, it would be nicer to have these as a local state, that's passed in as an arg* to the AsyncTaskProcessCB, which aligns with how the other checks do it. -- End of review -- Regarding keeping the connections, the way I envisioned it entailed passing a list of connections from one check to the next one (or keeping a global state with connections?). I didn't concretely look at the code to verify this, so it's just an abstract idea.