On Tue, Dec 20, 2022 at 2:46 PM Hayato Kuroda (Fujitsu) <kuroda.hay...@fujitsu.com> wrote: > > 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. >
I think the change will be streamed as soon as the next change is processed even if we serialize based on this option. See ReorderBufferProcessPartialChange. However, I see your point that when the streaming option is given, the value 'serialize' for this GUC may not make much sense. > 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. > The other possibility to achieve what you are saying is that we allow a minimum value of logical_decoding_work_mem as 0 which would mean stream or serialize each change depending on whether the streaming option is enabled. I think we normally don't allow a minimum value below a certain threshold for other *_work_mem parameters (like maintenance_work_mem, work_mem), so we have followed the same here. And, I think it makes sense from the user's perspective because below a certain threshold it will just add overhead by either writing small changes to the disk or by sending those over the network. However, it can be quite useful for testing/debugging. So, not sure, if we should restrict setting logical_decoding_work_mem below a certain threshold. What do you think? -- With Regards, Amit Kapila.
