On Tue, Dec 6, 2022 at 5:23 PM 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]. > > [1] > https://www.postgresql.org/message-id/CAFiTN-tHK=7lzfrps8fbt2ksrojgqbzywcgxst2bm9-rjja...@mail.gmail.com > [2] > https://www.postgresql.org/message-id/flat/CAA4eK1%2BwyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw%40mail.gmail.com >
Hi, I've been doing some testing that makes use of this new developer GUC `force_stream_mode`. IIUC this GUC is used by the walsender during the logic of the ReorderBufferCheckMemoryLimit(). Also, AFAIK the only way that the walsender is going to know this GUC value is by inheritance from the parent publisher at the time the walsender process gets launched. I may be overthinking this. Isn't there potential for this to become quite confusing depending on the timing of when this GUC is modified? E.g.1 When the walsender is launched, it will use whatever is the current value of this GUC. E.g.2 But if the GUC is changed after the walsender is already launched, then that will have no effect on the already running walsender. Is that understanding correct? ------ Kind Regards, Peter Smith. Fujitsu Australia.
