Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lELMa-0006Wm-Od for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Feb 2021 00:15:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lELMY-0005mS-OM for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Feb 2021 00:15:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lELMY-0005mL-C6 for pgsql-hackers@lists.postgresql.org; Tue, 23 Feb 2021 00:15:38 +0000 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lELMW-0006hO-1y for pgsql-hackers@lists.postgresql.org; Tue, 23 Feb 2021 00:15:37 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 4F214A50; Mon, 22 Feb 2021 19:15:34 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 22 Feb 2021 19:15:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=tIXchOnFJHSVEX3BqE8KymT4hkKbY+1N/ilYh9TWCz4=; b=Jq05rdAX BADEaUCdGjAcGG+Mm1uOcT3fimu7UqK838zJYkZur5lwFeH4/hqLhaEmqwEUSDC7 RSzhzS0wnHrCeV9zAR/NBSwG1TW5bYwMWfpwdypEKRJQXt8Zj1w9QV4kL6E8U/lQ yjRj7b1q0R/iUdg7lw5Gibmktlqcuw+rHIGbPZ2v8kY/hDyCCKfuUtJLrA9m5TBz 2QBq1BCetfblZ2g9rhh4QjCnl+xDR+O3HQnsQ/zJSarYVQcq5qp3F5ys2wQjnmD1 tIAD5PSY05TeeCg2FotNn5ThtMBxZRRGix91GU1VLuJVuUeTJ67qn0jIk3G8PSRE F3xpDIlId3EZMA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeeggddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtugfgjggfsehmkeerredtredunecuhfhrohhmpemllhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeevheetfeektefgfeevhfehtdevhfffheetuefgleeggfef iefgvefhheelledtveenucffohhmrghinhepphhoshhtghhrvghsqhhlrdhorhhgnecukf hppeduledtrdelhedrudelrddujeejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 4B24A1080066; Mon, 22 Feb 2021 19:15:33 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 83B2F2A0F80; Mon, 22 Feb 2021 21:15:31 -0300 (-03) Date: Mon, 22 Feb 2021 21:15:31 -0300 From: =?iso-8859-1?Q?=C1lvaro?= Herrera To: Matthias van de Meent Cc: Masahiko Sawada , Hamid Akhtar , PostgreSQL Hackers Subject: Re: {CREATE INDEX, REINDEX} CONCURRENTLY improvements Message-ID: <20210223001531.GA29197@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210222155642.GA26534@alvherre.pgsql> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2021-Feb-22, Álvaro Herrera wrote: > Here's an updated patch. > > I haven't added commentary or documentation to account for the new > assumption, per Matthias' comment and Robert's discussion thereof. Done that. I also restructured the code a bit, since one line in ComputedXidHorizons was duplicative. -- Álvaro Herrera 39°49'30"S 73°17'W Tom: There seems to be something broken here. Teodor: I'm in sackcloth and ashes... Fixed. http://archives.postgresql.org/message-id/482D1632.8010507@sigaev.ru --1yeeQ81UyVL57Vl7 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v3-0001-Teach-VACUUM-to-ignore-CIC.patch" From 98fa9ae33cb890e1d24a0c9be3a14139f15fdafe Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Fri, 15 Jan 2021 14:03:14 -0300 Subject: [PATCH v3] Teach VACUUM to ignore CIC Discussion: https://postgr.es/m/20210115133858.GA18931@alvherre.pgsql --- src/backend/storage/ipc/procarray.c | 39 +++++++++++++++++++++++------ src/backend/utils/misc/guc.c | 2 +- 2 files changed, 32 insertions(+), 9 deletions(-) diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c index a5daea8957..9c88f58c7f 100644 --- a/src/backend/storage/ipc/procarray.c +++ b/src/backend/storage/ipc/procarray.c @@ -1610,7 +1610,13 @@ TransactionIdIsActive(TransactionId xid) * relations that's not required, since only backends in my own database could * ever see the tuples in them. Also, we can ignore concurrently running lazy * VACUUMs because (a) they must be working on other tables, and (b) they - * don't need to do snapshot-based lookups. + * don't need to do snapshot-based lookups. Similarly, for the non-catalog + * horizon, we can ignore CREATE INDEX CONCURRENTLY and REINDEX CONCURRENTLY + * when they are working on non-partial, non-expressional indexes, for the + * same reasons and because they can't run in transaction blocks. (They are + * not possible to ignore for catalogs, because CIC and RC do some catalog + * operations.) Do note that this means that CIC and RC must use a lock level + * that conflicts with VACUUM. * * This also computes a horizon used to truncate pg_subtrans. For that * backends in all databases have to be considered, and concurrently running @@ -1660,9 +1666,6 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h) bool in_recovery = RecoveryInProgress(); TransactionId *other_xids = ProcGlobal->xids; - /* inferred after ProcArrayLock is released */ - h->catalog_oldest_nonremovable = InvalidTransactionId; - LWLockAcquire(ProcArrayLock, LW_SHARED); h->latest_completed = ShmemVariableCache->latestCompletedXid; @@ -1682,6 +1685,7 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h) h->oldest_considered_running = initial; h->shared_oldest_nonremovable = initial; + h->catalog_oldest_nonremovable = initial; h->data_oldest_nonremovable = initial; /* @@ -1752,7 +1756,7 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h) if (statusFlags & (PROC_IN_VACUUM | PROC_IN_LOGICAL_DECODING)) continue; - /* shared tables need to take backends in all database into account */ + /* shared tables need to take backends in all databases into account */ h->shared_oldest_nonremovable = TransactionIdOlder(h->shared_oldest_nonremovable, xmin); @@ -1773,11 +1777,26 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h) MyDatabaseId == InvalidOid || proc->databaseId == MyDatabaseId || proc->databaseId == 0) /* always include WalSender */ { - h->data_oldest_nonremovable = - TransactionIdOlder(h->data_oldest_nonremovable, xmin); + /* + * We can ignore this backend if it's running CREATE INDEX + * CONCURRENTLY or REINDEX CONCURRENTLY on a "safe" index -- but + * only on vacuums of user-defined tables. + */ + if (!(statusFlags & PROC_IN_SAFE_IC)) + h->data_oldest_nonremovable = + TransactionIdOlder(h->data_oldest_nonremovable, xmin); + + /* Catalog tables need to consider all backends. */ + h->catalog_oldest_nonremovable = + TransactionIdOlder(h->catalog_oldest_nonremovable, xmin); + } } + /* catalog horizon should never be later than data */ + Assert(TransactionIdPrecedesOrEquals(h->catalog_oldest_nonremovable, + h->data_oldest_nonremovable)); + /* * If in recovery fetch oldest xid in KnownAssignedXids, will be applied * after lock is released. @@ -1799,6 +1818,8 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h) TransactionIdOlder(h->shared_oldest_nonremovable, kaxmin); h->data_oldest_nonremovable = TransactionIdOlder(h->data_oldest_nonremovable, kaxmin); + h->catalog_oldest_nonremovable = + TransactionIdOlder(h->catalog_oldest_nonremovable, kaxmin); /* temp relations cannot be accessed in recovery */ } else @@ -1825,6 +1846,9 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h) h->data_oldest_nonremovable = TransactionIdRetreatedBy(h->data_oldest_nonremovable, vacuum_defer_cleanup_age); + h->catalog_oldest_nonremovable = + TransactionIdRetreatedBy(h->catalog_oldest_nonremovable, + vacuum_defer_cleanup_age); /* defer doesn't apply to temp relations */ } @@ -1847,7 +1871,6 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h) h->shared_oldest_nonremovable = TransactionIdOlder(h->shared_oldest_nonremovable, h->slot_catalog_xmin); - h->catalog_oldest_nonremovable = h->data_oldest_nonremovable; h->catalog_oldest_nonremovable = TransactionIdOlder(h->catalog_oldest_nonremovable, h->slot_catalog_xmin); diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c index 260ec7b97e..d626731723 100644 --- a/src/backend/utils/misc/guc.c +++ b/src/backend/utils/misc/guc.c @@ -2583,7 +2583,7 @@ static struct config_int ConfigureNamesInt[] = NULL }, &vacuum_defer_cleanup_age, - 0, 0, 1000000, + 0, 0, 1000000, /* see ComputeXidHorizons */ NULL, NULL, NULL }, -- 2.20.1 --1yeeQ81UyVL57Vl7--