RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5
От | Hayato Kuroda (Fujitsu) |
---|---|
Тема | RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 |
Дата | |
Msg-id | OSCPR01MB14966C14006CDF9FB0CC151B4F575A@OSCPR01MB14966.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (vignesh C <vignesh21@gmail.com>) |
Список | pgsql-bugs |
Dear hackers, > Attached are the patches, including those required for the back branches. While reviewing patch for PG13, I found the doubtful point in ReorderBufferCommit(). ``` /* * Every time the CommandId is incremented, we could * see new catalog contents, so execute all * invalidations. */ ReorderBufferExecuteInvalidations(txn->ninvalidations, txn->invalidations); ``` This is called when REORDER_BUFFER_CHANGE_INTERNAL_COMMAND_ID is dequeued from the change queue, and this part exists only in PG13 codebase. We are not sure whether we should execute txn->invalidations_distributed as well. This can affect below case: txn1: BEGIN; INSERT INTO d VALUES ('d1'); txn2: ALTER PUBLICATION pb ADD TABLE d; txn1: CREATE TABLE another (id int); txn1: INSERT INTO d VALUES ('d2'); txn1: COMMIT; -> PG13 - no output -> PG13 + v13 patch - no output -> PG13 + v13 patch + additional inval execution - d2 can be replicated -> (master - d2 can be replicated) Personally I think txn->invalidations_distributed is not needed to be executed because the spec seems bit complex, but I want to know other opinion. Best regards, Hayato Kuroda FUJITSU LIMITED
В списке pgsql-bugs по дате отправления: