Fix publisher-side sequence permission reporting
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-06-18T15:36:06Z
Lists: pgsql-hackers
Attachments
- v1-0001-Fix-misreporting-of-publisher-sequence-permission.patch (application/octet-stream) patch v1-0001
- v1-0002-doc-Clarify-pg_get_sequence_data-privileges-and-N.patch (application/octet-stream) patch v1-0002
Hi,
While testing logical replication sequence synchronization, I found
that a publisher-side permission problem can be reported as a
misleading "missing sequence on publisher" warning.
The issue can be reproduced as follows:
1. On the publisher:
CREATE SEQUENCE myseq;
CREATE PUBLICATION mypub FOR ALL SEQUENCES;
CREATE ROLE foo LOGIN REPLICATION NOSUPERUSER;
2. On the subscriber:
CREATE SEQUENCE myseq;
CREATE SUBSCRIPTION mysub
CONNECTION 'user=foo dbname=postgres ...'
PUBLICATION mypub;
The subscriber currently emits:
WARNING: missing sequence on publisher ("public.myseq")
even though the sequence still exists on the publisher. The real
problem is that the replication connection lacks SELECT privilege to
read the sequence data.
The cause is that; sequence synchronization obtains sequence data using
pg_get_sequence_data(). When the user lacks SELECT privilege on
the sequence, pg_get_sequence_data() returns a row containing all NULL
values. Sequence synchronization currently treats that the same as
a missing sequence, so publisher-side permission failures and
genuinely missing sequences are not distinguished, leading to
the misleading warning.
Patch 0001 fixes this by distinguishing the two cases during sequence
synchronization. It checks whether the replication connection has the
required privilege for each published sequence and reports
publisher-side permission failures separately.
While working on this, I also noticed that the documented privilege
requirement for pg_get_sequence_data() does not match the
implementation. The documentation says that USAGE or SELECT privilege
is sufficient, but the implementation requires SELECT.
Patch 0002 updates the documentation to match the current behavior.
I chose to update the documentation rather than broaden the
implementation for two reasons.
First, commit c8b06bb969b, which introduced the predecessor of
pg_get_sequence_data(), described it as a substitute for SELECT
from a sequence, and its implementation has always required
SELECT privilege.
Second, the logical replication documentation already states that
replicating sequence data requires SELECT privilege.
Patches attached.
Regards,
--
Fujii Masao
Commits
-
Fix unlogged sequence corruption after standby promotion
- d2980067bc3b 15 (unreleased) landed
- 913d3b610ccd 16 (unreleased) landed
- a1ed6a9a031a 17 (unreleased) landed
- 627605713074 18 (unreleased) landed
- 22af34b98362 19 (unreleased) landed
- 8e684ce11dda master landed
-
doc: Clarify pg_get_sequence_data() privileges and NULL results
- 031904048aa2 19 (unreleased) landed
-
Fix misreporting of publisher sequence permissions during sync
- d4a657b0a4db 19 (unreleased) landed
-
Introduce pg_sequence_read_tuple().
- c8b06bb969bf 18.0 cited