Re: long-standing data loss bug in initial sync of logical replication - Mailing list pgsql-hackers

From Shlok Kyal
Subject Re: long-standing data loss bug in initial sync of logical replication
Date
Msg-id CANhcyEXQ=qYD-vQ0VhrTORZsVxV7v2ti_MJ5B6WUXNy1KedNCw@mail.gmail.com
Whole thread Raw
In response to RE: long-standing data loss bug in initial sync of logical replication  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
On Mon, 30 Sept 2024 at 16:56, Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> > 2.
> > Similarly with above, the relcache won't be invalidated when ALTER
> > PUBLICATION
> > OWNER TO is executed. This means that privilage checks may be ignored if the
> > entry
> > is still valid. Not sure, but is there a possibility this causes an inconsistency?
>
> Hmm, IIUC, the attribute pubowner is not used for now. The paragpargh
> "There are currently no privileges on publications...." [1] may show the current
> status. However, to keep the current behavior, I suggest to invalidate the relcache
> of pubrelations when the owner is altered.
>
> [1]: https://www.postgresql.org/docs/devel/logical-replication-security.html

I have shared the updated patch [1].
So now, when 'ALTER .. PUBLICATION .. OWNER TO ..' is executed the
relcache is invalidated for that specific publication.

[1] : https://www.postgresql.org/message-id/CANhcyEWEXL3rxvKH9-Xtx-DgGX0D62EktHpW%2BnG%2BMSSaMVUVig%40mail.gmail.com

Thanks and Regards,
Shlok Kyal



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Address the -Wuse-after-free warning in ATExecAttachPartition()
Next
From: Amit Langote
Date:
Subject: Re: general purpose array_sort