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 1s2wUt-007cfZ-8S for pgsql-hackers@arkaria.postgresql.org; Fri, 03 May 2024 17:14:59 +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 1s2wTr-00ApIv-Je for pgsql-hackers@arkaria.postgresql.org; Fri, 03 May 2024 17:13:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s2wTr-00ApIn-A5 for pgsql-hackers@lists.postgresql.org; Fri, 03 May 2024 17:13:56 +0000 Received: from mail-io1-xd2d.google.com ([2607:f8b0:4864:20::d2d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s2wTp-001NFC-7W for pgsql-hackers@postgresql.org; Fri, 03 May 2024 17:13:55 +0000 Received: by mail-io1-xd2d.google.com with SMTP id ca18e2360f4ac-7d5e4097a9aso385086839f.3 for ; Fri, 03 May 2024 10:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714756430; x=1715361230; darn=postgresql.org; h=content-disposition:mime-version:message-id:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=tSjayJGUKefI/4b89D46qD6BPQk6F34aVXkhe41Km5I=; b=Q9PjNGpyrjZ+Uj7ZvTyTwUVeTkOqPTJLxIdd4P8ACKAr128CI+yJNcEOeGWqYSlYKp kFN65j3j5WhR7d1nEccVTyqKsVNOdv6mYMW5X8ijcTDH9Ri5yF6kXdETj5pQDW9eA5Qi KaJ3ZT10rEUhS3xhGbPP+PuHO/8KS/cktdRXBwiuU9c88BYUN9QnZlO6zEmtdO9wk8s4 6sfdLhxHo/KBhrKyKKxvJ96UYRouL4tfklDMoY8XHrhIw6zW/Vc+77Es6oIG4qiMB/GQ TTvDCGycS9cu4bd2Mxs/0hsaGKiS8eKq0hLSMPEP8Gg9GmvnOGpkdMIou/ERVk/wuCBs PQKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714756430; x=1715361230; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tSjayJGUKefI/4b89D46qD6BPQk6F34aVXkhe41Km5I=; b=P0M+tyZyZcekN0iYxKeTYDgGvhDyPK3tDREnk+7Q2/fK/RChLpGNu9fFNpK7seH0XA vLhFoDhYsXGbQ80ONDZLJCjAgHRkuYvzB41EynVkF+1xReh65qj1+ok2LamWlDkxuu+x CKhQZw0wwknbSRzLIkmhOu5vh2gBreRavzhvVIP1F+9yhnutXV8bhkZkPoJBmZNn64UA Jh+PgWSKH3d+Hm1BGS2DgJQw6HjopLqvm+mww6VlV7c3QIvwJyrjrm3ymOEUX8+sA8/Y j6qHUnG037UVnrbv12OswATNKUL7G+VaUC35oaoWgXsn+0FFzrp8vp7jWoFQsKgpkD+X 0uiQ== X-Gm-Message-State: AOJu0YwPVOPwehBSmHK8sfuYdr+VxJw1CE9YMbnXlzSUVti58ySHbtYY W/WaDQL6oLxKSeFveCZK2E20OdwgACY+Q4gW3hvhFFrJUfbcJbeF7pMC/Q== X-Google-Smtp-Source: AGHT+IFxNvuMQqMtopUTc2FkzdW7DqU2EdztOZKSaXFoznmRoCSHaZqrVPbcRHaTwr4asCMmqfjzFg== X-Received: by 2002:a5e:9805:0:b0:7de:c3f9:7413 with SMTP id s5-20020a5e9805000000b007dec3f97413mr4121703ioj.1.1714756430330; Fri, 03 May 2024 10:13:50 -0700 (PDT) Received: from nathanxps13 (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id cl11-20020a0566383d0b00b0047f14f6a3f8sm898521jab.107.2024.05.03.10.13.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 May 2024 10:13:49 -0700 (PDT) Date: Fri, 3 May 2024 12:13:48 -0500 From: Nathan Bossart To: pgsql-hackers@postgresql.org Subject: add --no-sync to pg_upgrade's calls to pg_dump and pg_dumpall Message-ID: <20240503171348.GA1731524@nathanxps13> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="DocE+STaALJfprDB" Content-Disposition: inline List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This is likely small potatoes compared to some of the other pg_upgrade-related improvements I've proposed [0] [1] or plan to propose, but this is easy enough, and I already wrote the patch, so here it is. AFAICT there's no reason to bother syncing these dump files to disk. If someone pulls the plug during pg_upgrade, it's not like you can resume pg_upgrade from where it left off. Also, I think we skipped syncing before v10, anyway, as the --no-sync flag was only added in commit 96a7128, which added the code to sync dump files, too. [0] https://postgr.es/m/20240418041712.GA3441570%40nathanxps13 [1] https://postgr.es/m/20240503025140.GA1227404%40nathanxps13 -- Nathan Bossart Amazon Web Services: https://aws.amazon.com --DocE+STaALJfprDB Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v1-0001-add-no-sync-to-pg_upgrade-s-calls-to-pg_dump-all.patch" From 998613046fb5ff5c6618964c821109b573bfa89b Mon Sep 17 00:00:00 2001 From: Nathan Bossart Date: Fri, 3 May 2024 10:35:21 -0500 Subject: [PATCH v1 1/1] add --no-sync to pg_upgrade's calls to pg_dump[all] --- src/bin/pg_upgrade/dump.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/bin/pg_upgrade/dump.c b/src/bin/pg_upgrade/dump.c index 29fb45b928..f052a4985c 100644 --- a/src/bin/pg_upgrade/dump.c +++ b/src/bin/pg_upgrade/dump.c @@ -22,9 +22,10 @@ generate_old_dump(void) /* run new pg_dumpall binary for globals */ exec_prog(UTILITY_LOG_FILE, NULL, true, true, "\"%s/pg_dumpall\" %s --globals-only --quote-all-identifiers " - "--binary-upgrade %s -f \"%s/%s\"", + "--binary-upgrade %s %s -f \"%s/%s\"", new_cluster.bindir, cluster_conn_opts(&old_cluster), log_opts.verbose ? "--verbose" : "", + GET_MAJOR_VERSION(old_cluster.major_version) >= 1000 ? "--no-sync" : "", log_opts.dumpdir, GLOBALS_DUMP_FILE); check_ok(); @@ -53,9 +54,10 @@ generate_old_dump(void) parallel_exec_prog(log_file_name, NULL, "\"%s/pg_dump\" %s --schema-only --quote-all-identifiers " - "--binary-upgrade --format=custom %s --file=\"%s/%s\" %s", + "--binary-upgrade --format=custom %s %s --file=\"%s/%s\" %s", new_cluster.bindir, cluster_conn_opts(&old_cluster), log_opts.verbose ? "--verbose" : "", + GET_MAJOR_VERSION(old_cluster.major_version) >= 1000 ? "--no-sync" : "", log_opts.dumpdir, sql_file_name, escaped_connstr.data); -- 2.25.1 --DocE+STaALJfprDB--