public inbox for [email protected]
help / color / mirror / Atom feedFrom: Hayato Kuroda (Fujitsu) <[email protected]>
To: 'Amit Kapila' <[email protected]>
To: [email protected] <[email protected]>
To: Sawada Masahiko <[email protected]>
To: Peter Smith <[email protected]>
To: Dilip Kumar <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: RE: Force streaming every change in logical decoding
Date: Tue, 20 Dec 2022 09:16:29 +0000
Message-ID: <TYAPR01MB586604F7A7E27A6A1A695E32F5EA9@TYAPR01MB5866.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <CAA4eK1+vE1_iTty_2Z73_GgA6d26Kh9Oh+kY5uLi6kdterMV1Q@mail.gmail.com>
References: <OSZPR01MB63104E7449DBE41932DB19F1FD1B9@OSZPR01MB6310.jpnprd01.prod.outlook.com>
<CAFiTN-v9r17Ae5uFJbFPQqdQyFtJb5=nZXBu8h1HW6xA9msrtg@mail.gmail.com>
<OSZPR01MB63102546180646AEE1C66C34FDE09@OSZPR01MB6310.jpnprd01.prod.outlook.com>
<CAA4eK1+vE1_iTty_2Z73_GgA6d26Kh9Oh+kY5uLi6kdterMV1Q@mail.gmail.com>
Dear hackers,
> We have discussed three different ways to provide GUC for these
> features. (1) Have separate GUCs like force_server_stream_mode,
> force_server_serialize_mode, force_client_serialize_mode (we can use
> different names for these) for each of these; (2) Have two sets of
> GUCs for server and client. We can have logical_decoding_mode with
> values as 'stream' and 'serialize' for the server and then
> logical_apply_serialize = true/false for the client. (3) Have one GUC
> like logical_replication_mode with values as 'server_stream',
> 'server_serialize', 'client_serialize'.
I also agreed for adding new GUC parameters (and I have already done partially
in parallel apply[1]), and basically options 2 made sense for me. But is it OK
that we can choose "serialize" mode even if subscribers require streaming?
Currently the reorder buffer transactions are serialized on publisher only when
the there are no streamable transaction. So what happen if the
logical_decoding_mode = "serialize" but streaming option streaming is on? If we
break the first one and serialize changes on publisher anyway, it may be not
suitable for testing the normal operation.
Therefore, I came up with the variant of (2): logical_decoding_mode can be
"normal" or "immediate".
"normal" is a default value, which is same as current HEAD. Changes are streamed
or serialized when the buffered size exceeds logical_decoding_work_mem.
When users set to "immediate", the walsenders starts to stream or serialize all
changes. The choice is depends on the subscription option.
In short: +1 for (2) family.
[1]: https://www.postgresql.org/message-id/TYAPR01MB5866160DE81FA2D88B8F22DEF5159%40TYAPR01MB5866.jpnprd0...
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
view thread (61+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: RE: Force streaming every change in logical decoding
In-Reply-To: <TYAPR01MB586604F7A7E27A6A1A695E32F5EA9@TYAPR01MB5866.jpnprd01.prod.outlook.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox