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 OSCPR01MB14966C8D376CB550AB5FA6040F56FA@OSCPR01MB14966.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Список pgsql-bugs
>0. S1: CREATE TABLE d(data text not null);
>1. S1: BEGIN;
>2. S1: INSERT INTO d VALUES ('d1')
>3.                         S2: BEGIN;
>4.                         S2: INSERT INTO d VALUES ('d2')
>5. S1: ALTER PUBLICATION pb ADD TABLE d;
>6. S1: ... lots of DDLs so overflow happens
>7. S1: COMMIT;
>8.                         S2: INSERT INTO d VALUES ('d3');
>9.                         S2: COMMIT;
>10.                        S2: INSERT INTO d VALUES ('d4');
>
> In this case, the inval message generated by step 5 is discarded at step 6. No
> invalidation messages are distributed in the
> SnapBuildDistributeSnapshotAndInval().
> While decoding S2, relcache cannot be discarded and tuples d3 and d4 won't be
> replicated. Do you think this can happen?

Before running the workload, pg_recvlogical was run to check the output.
At step 6, I created and dropped the same table several times until the debug log was output:

```
[650552] LOG:  RBTXN_INVAL_OVERFLOWED flag is set
[650552] STATEMENT:  START_REPLICATION SLOT "test" LOGICAL 0/0 ("proto_version" '4', "publication_names" 'pb')
```

After that I executed till 10 but no output was done by pg_recvlogical

Best regards,
Hayato Kuroda
FUJITSU LIMITED


Вложения

В списке pgsql-bugs по дате отправления: