overflowing - Search results
Mailing lists >> pgsql-bugs >> Thread
2025-06-06 09:54:51 | RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (Hayato Kuroda (Fujitsu))
OVERFLOWED; + elog(LOG, "RBTXN_DISTR_INVAL_OVERFLOWED is set to the transaction") ``` Method how I count
Mailing lists >> pgsql-bugs >> Thread
2025-06-06 06:43:28 | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (Amit Kapila)
overflow code path. One minor point to consider is that at the time, the value
Mailing lists >> pgsql-bugs >> Thread
2025-06-06 06:21:54 | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (Amit Kapila)
overflowed) for backbranches? In the previous email, you seemed to agree with the performance impact
Mailing lists >> pgsql-bugs >> Thread
2025-06-06 00:59:12 | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (Masahiko Sawada)
OVERFLOWED to RBTXN_DISTR_INVAL_OVERFLOWED, and it includes some comment updates. Please review them
Mailing lists >> pgsql-bugs >> Thread
2025-06-05 22:21:21 | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (Masahiko Sawada)
overflowed, we should mark other transactions as overflowed instead of distributing inval messages. Regards, -- Masahiko
Mailing lists >> pgsql-bugs >> Thread
2025-06-05 20:43:25 | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (Masahiko Sawada)
overflow cases and non-overflow cases also in test cases added in the future, improving
Mailing lists >> pgsql-bugs >> Thread
2025-06-05 15:14:43 | RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (Hayato Kuroda (Fujitsu))
OVERFLOWED flag is set [650552] STATEMENT: START_REPLICATION SLOT "test" LOGICAL 0/0 ("proto_version" '4', "publication
Mailing lists >> pgsql-bugs >> Thread
2025-06-05 14:07:22 | RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (Hayato Kuroda (Fujitsu))
overflow happens 7. S1: COMMIT; 8. S2: INSERT INTO d VALUES ('d3'); 9. S2: COMMIT
Mailing lists >> pgsql-bugs >> Thread
2025-06-05 13:28:30 | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (vignesh C)
OVERFLOWED txn. I have added comments for this, feel free to reword it if some
Mailing lists >> pgsql-bugs >> Thread
2025-06-05 09:20:04 | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (Amit Kapila)
overflowed(txn))" in function ReorderBufferAddInvalidations(). What is the need of such a check in this
Mailing lists >> pgsql-bugs >> Thread
2025-06-05 00:48:54 | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (Masahiko Sawada)
overflowed, we would miss executing the txn->invalidations here. Probably the same is true for ReorderBufferForget
Mailing lists >> pgsql-bugs >> Thread
2025-06-03 22:43:50 | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (Masahiko Sawada)
OVERFLOWED, it would explain the state of the transaction clearer. --- Can we have a reasonable
Mailing lists >> pgsql-bugs >> Thread
2025-05-30 07:01:19 | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (vignesh C)
overflow scenario. c) setting the newly added nentries_distr to -1, to indicate an overflow