Re: Force streaming every change in logical decoding
От | Amit Kapila |
---|---|
Тема | Re: Force streaming every change in logical decoding |
Дата | |
Msg-id | CAA4eK1Lt21s8cK7pMYB-2vUT79n5j+6o1MduRyNm5D=R_Y=mVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Force streaming every change in logical decoding ("shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>) |
Ответы |
Re: Force streaming every change in logical decoding
Re: Force streaming every change in logical decoding |
Список | pgsql-hackers |
On Tue, Dec 6, 2022 at 11:53 AM shiy.fnst@fujitsu.com <shiy.fnst@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]. > Yeah, I think this can also help in reducing the time for various tests in test_decoding/stream and src/test/subscription/t/*_stream_*.pl file by reducing the number of changes required to invoke streaming mode. Can we think of making this GUC extendible to even test more options on server-side (publisher) and client-side (subscriber) cases? For example, we can have something like logical_replication_mode with the following valid values: (a) server_serialize: this will serialize each change to file on publishers and then on commit restore and send all changes; (b) server_stream: this will stream each change as currently proposed in your patch. Then if we want to extend it for subscriber-side testing then we can introduce new options like client_serialize for the case being discussed in the email [1]. Thoughts? [1] - https://www.postgresql.org/message-id/CAD21AoAVUfDrm4-%3DykihNAmR7bTX-KpHXM9jc42RbHePJv5k1w%40mail.gmail.com -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: