The function does following: TransactionId new_xmin = (TransactionId) PG_GETARG_INT64(1);
This should be reasonable enough though; down-casting it will discard the high bits but that's fine when we know there's nothing interesting there.
TransactionId is a uint32 anyway, but I had a reason for the above. There's no cast from integer to xid, which is why I used bigint here, since we don't have a uint32 native SQL type. What I *should've* done is simply used quoted-literal arguments like
XID '1234'
or cast via text
1234::text::xid
so there was no need to use a bigint instead. I'll adjust appropriately so it uses PG_GETARG_TRANSACTIONID(1) and is declared as accepting 'xid'.
And we are passing NULL as that parameter, that could explain this.
If we're on an int64-by-value platform that'd be wrong but still work, it'd just be zero. On an int64-by-reference platform it could indeed segfault. So yes, I'd say that's the cause.
Also while reading it I wonder if the function should be defined with xid type rather than bigint and use similar input code as xid.c.
