Re: BUG #17928: Standby fails to decode WAL on termination of primary
От | Michael Paquier |
---|---|
Тема | Re: BUG #17928: Standby fails to decode WAL on termination of primary |
Дата | |
Msg-id | ZNrqTmKGnZwz9gPI@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #17928: Standby fails to decode WAL on termination of primary (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: BUG #17928: Standby fails to decode WAL on termination of primary
|
Список | pgsql-bugs |
On Tue, Aug 15, 2023 at 02:36:10PM +1200, Thomas Munro wrote: > Yeah, I think that sounds quite promising, and funnily enough I was > just now working on some Perl code that appends controlled junk to the > WAL in a test like that so we can try to hit all the error paths... I am pretty sure that adding some junk in a controlled manner is the only cheap and rather-reliable way to get something.. Not sure if that will help, but what I was playing with some stuff in the lines of: -- Store the length up to page boundary. select setting::int - ((pg_current_wal_insert_lsn() - '0/0') % setting::int) as boundary from pg_settings where name = 'wal_block_size' \gset -- Generate record up to boundary (56 bytes for base size of the record, -- stop at 12 bytes before the end of the page. select pg_logical_emit_message(false, '', repeat('a', :boundary - 56 - 12)); Then by injecting some FF's on the last page written and forcing replay I am able to force some of the error code paths, so I guess that's what you were basically doing? -- Michael
Вложения
В списке pgsql-bugs по дате отправления: