On 2019-Jan-31, Arseny Sher wrote: > My colleague Alexander Lakhin has noticed an assertion failure in > reorderbuffer.c:1330. Here is a simple snippet reproducing it: > > SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot', > 'test_decoding'); > > create table t(k int); > begin; > savepoint a; > alter table t alter column k type text; > rollback to savepoint a; > alter table t alter column k type bigint; > commit; > > SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL, > 'include-xids', '0', 'skip-empty-xacts', '1');
Hmm, the new test introduced by your patch fails in early branches (at least 9.4): the transaction is decoded like this: ! data ! ----------------------------------------------------- BEGIN table public.tr_sub_ddl: INSERT: data[integer]:42 + table public.pg_temp_16445: INSERT: data[bigint]:42 table public.tr_sub_ddl: INSERT: data[bigint]:43 COMMIT ! (5 rows) note the additional pg_temp_XYZ row in the middle. This is caused by the rewrite in ALTER TABLE. Peter E fixed that in Pg11 in commit 325f2ec55; I don't think there's much to do in the backbranches other than hide the pesky record to avoid it breaking the test. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services