Re: Bus error in pg_logical_slot_get_changes (9.4.7, sparc)

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2016-04-14 15:14:37 -0400, Tom Lane wrote:
>> Even there, at least in
>> HEAD, I cannot construct a test case in which the first tuple's t_len is
>> not a multiple of 4.

> That's really kinda weird. It's a tuple from WAL, and the length's from
> the record; the same way wal replay gets it. Wonder if this might not
> indicate a relevant bug somewhere...

Got it: it's a testing deficiency. What I was not aware of is that this
code path (with two tuples to be restored) seems to only be entered for
updates that change the primary key. And guess what, there are only a
couple of instances of that in the test_decoding tests, and all of them
have old tuples that are a multiple of 4 long. I'd been modifying the
tests in a way that didn't produce any new exercise of the target code
path at all :-(

I have a test addition now that produces a bus error on gaur, and probably
on every alignment-picky platform:

diff --git a/contrib/test_decoding/sql/ddl.sql b/contrib/test_decoding/sql/ddl.sql
index b1f7bf6..e99b2d3 100644
*** a/contrib/test_decoding/sql/ddl.sql
--- b/contrib/test_decoding/sql/ddl.sql
*************** INSERT INTO tr_etoomuch(data) SELECT g.i
*** 116,121 ****
--- 116,123 ----
SELECT 'tx logical msg' FROM pg_logical_emit_message(true, 'test', 'tx logical msg');
DELETE FROM tr_etoomuch WHERE id < 5000;
UPDATE tr_etoomuch SET data = - data WHERE id > 5000;
+ CREATE TABLE tr_oddlength (id text primary key, data text);
+ INSERT INTO tr_oddlength VALUES('ab', 'foo');
COMMIT;

/* display results, but hide most of the output */
*************** ORDER BY 1,2;
*** 128,133 ****
--- 130,137 ----
BEGIN;
CREATE TABLE spoolme AS SELECT g.i FROM generate_series(1, 5000) g(i);
UPDATE tr_etoomuch SET id = -id WHERE id = 5000;
+ UPDATE tr_oddlength SET id = 'x', data = 'quux';
+ UPDATE tr_oddlength SET id = 'yy', data = 'a';
DELETE FROM spoolme;
DROP TABLE spoolme;
COMMIT;

Will commit this along with the fix.

Meanwhile, there's still the question of why Christoph's sparc machine got
a bus error on a case where other picky platforms don't. But I'm prepared
to write that off as some code-generation vagary.

regards, tom lane