| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Fix publisher-side sequence permission reporting |
| Date: | 2026-06-18 15:36:06 |
| Message-ID: | CAHGQGwGNTaXnBKUV510_P1KwhdbHT+kgZ4zU5njBHy7nCqdhzg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Fix-misreporting-of-publisher-sequence-permission.patch | application/octet-stream | 11.2 KB |
| v1-0002-doc-Clarify-pg_get_sequence_data-privileges-and-N.patch | application/octet-stream | 2.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2026-06-18 15:37:49 | Re: fix pg_mkdir_p to tolerate concurrent directory creation |
| Previous Message | Tom Lane | 2026-06-18 15:34:46 | Re: [PATCH] Doc: document standard_conforming_strings dump/restore incompatibility |