Re: POC: enable logical decoding when wal_level = 'replica' without a server restart

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Peter Smith <smithpb2250(at)gmail(dot)com>
Cc: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Date: 2025-01-10 09:27:23
Message-ID: CAD21AoC07DV5LzppipBZmZfstKWhtx8rP470rssA6xQqtU6YUA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Tue, Jan 7, 2025 at 11:30 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> Hi Sawada-San.
>
> FWIW, I also thought it was a good idea suggested by Bertrand [1] to
> "hide" everything behind the slot create/delete, and thereby eliminate
> the need for user intervention using those new
> pg_activate/deactivate_logical_decoding functions.
>
> But, one concern doing it this way is how to prevent a user
> (accidentally?) getting themselves into a different replication mode
> without realising it? Or say they change the mode and then "forget"
> that they did that.

I think that as long as there is at least one logical replication slot
users still have the will to execute logical decoding, so they require
logical info WAL-logging. I think it would rather be good for users to
be able to forget about that.

> For example, If wal_level=replica and then somebody does CREATE
> PUBLICATION/SUBSCRIPTION won't that implicitly enable the logical
> decoding and then leave it enabled until all the logical replication
> slots are eventually dropped?

Yes.

> Now, when the user examines wal_level it
> is still going to show 'replica', which could be misleading --- e.g.
> how will they even know that they can't really trust that anymore, and
> they must also check the pg_get_logical_decoding_status?

I think that if we automatically enable logical decoding even when
wal_level=replica, we would not need pg_get_logical_decoding_status().
These changes would break compatibility tools checking if wal_level is
'logical', but I guess that tools will not need to check that anymore.
Users can simply understand that if there is at least one logical
replication slot the system writes necessary information to use it.
Having said that we anyway need to mention it in the doc and raising
NOTICE/WARNING would also be a good idea as you mentioned.

>
> Meanwhile, although it is premature to give detailed code review
> comments for what is still a PoC, during my reading of your patch I
> made copious notes for myself, so I thought I might as well post what
> I have regardless. See the details below in this post. Ignore, or do
> with them as you wish. But, hopefully, a lot of the following feedback
> will still be relevant regardless of any design changes.

Thank you for reviewing the patch! It seems that most comments are
about wording, typos, suggestions for variable names and function
names etc. Since the patch is in the PoC/design phase where we might
need to change the whole design, I'll refer to these comments when
updating the patch next time.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Antonin Houska 2025-01-10 09:31:47 Re: why there is not VACUUM FULL CONCURRENTLY?
Previous Message Amit Langote 2025-01-10 09:22:13 Re: Some ExecSeqScan optimizations