On Sat, Dec 10, 2022 at 5:03 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Tue, Dec 6, 2022 at 11:53 AM shiy.f...@fujitsu.com > <shiy.f...@fujitsu.com> wrote: > > > > Hi hackers, > > > > In logical decoding, when logical_decoding_work_mem is exceeded, the > > changes are > > sent to output plugin in streaming mode. But there is a restriction that the > > minimum value of logical_decoding_work_mem is 64kB. I tried to add a GUC to > > allow sending every change to output plugin without waiting until > > logical_decoding_work_mem is exceeded. > > > > This helps to test streaming mode. For example, to test "Avoid streaming the > > transaction which are skipped" [1], it needs many XLOG_XACT_INVALIDATIONS > > messages. With the new option, it can be tested with fewer changes and in > > less > > time. Also, this new option helps to test more scenarios for "Perform > > streaming > > logical transactions by background workers" [2]. > > Some comments on the patch > ... > This GUC name "force_stream_mode" somehow appears like we are forcing > this streaming mode irrespective of whether the > subscriber has requested for this mode or not. But actually it is not > that, it is just streaming each change if > it is enabled. So we might need to think on the name (at least we > should avoid using *mode* in the name IMHO). >
I thought the same. Names like those shown below might be more appropriate: stream_checks_work_mem = true/false stream_mode_checks_size = true/false stream_for_large_tx_only = true/false ... etc. The GUC name length could get a bit unwieldy but isn't it better for it to have the correct meaning than to have a shorter but slightly ambiguous name? Anyway, it is a developer option so I guess longer names are less of a problem. ------ Kind Regards, Peter Smith. Fujitsu Australia