From: | Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Inconsistency in vacuum behavior |
Date: | 2023-01-16 08:18:08 |
Message-ID: | 21b7e2834ed78f527336cddde54846d4@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi.
We've run regress isolation tests on partitioned tables and found
interesting VACUUM behavior. I'm not sure, if it's intended.
In the following example, partitioned tables and regular tables behave
differently:
CREATE TABLE vacuum_tab (a int) PARTITION BY HASH (a);
CREATE TABLE vacuum_tab_1 PARTITION OF vacuum_tab FOR VALUES WITH
(MODULUS 2, REMAINDER 0);
CREATE TABLE vacuum_tab_2 PARTITION OF vacuum_tab FOR VALUES WITH
(MODULUS 2, REMAINDER 1);
CREATE ROLE regress_vacuum_conflict;
In the first session:
begin;
LOCK vacuum_tab IN SHARE UPDATE EXCLUSIVE MODE;
In the second:
SET ROLE regress_vacuum_conflict;
VACUUM vacuum_tab;
WARNING: permission denied to vacuum "vacuum_tab", skipping it <----
hangs here, trying to lock vacuum_tab_1
In non-partitioned case second session exits after emitting warning. In
partitioned case, it hangs, trying to get locks.
This is due to the fact that in expand_vacuum_rel() we skip parent table
if vacuum_is_permitted_for_relation(), but don't perform such check for
its child.
The check will be performed later in vacuum_rel(), but after
vacuum_open_relation(), which leads to hang in the second session.
Is it intended? Why don't we perform vacuum_is_permitted_for_relation()
check for inheritors in expand_vacuum_rel()?
--
Best regards,
Alexander Pyhalov,
Postgres Professional
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2023-01-16 09:27:07 | Improve LATERAL join case in test memoize.sql |
Previous Message | Masahiko Sawada | 2023-01-16 08:18:02 | Re: [PoC] Improve dead tuple storage for lazy vacuum |