Re: Bus error in pg_logical_slot_get_changes (9.4.7, sparc)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Bus error in pg_logical_slot_get_changes (9.4.7, sparc)
Date: 2016-04-14 22:22:42
Message-ID: 20160414222242.ec4m74aqsh4eshde@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2016-04-14 15:14:37 -0400, Tom Lane wrote:
> I've been looking around and testing some more. I noticed that the only
> caller of ReorderBufferRestoreChange always passes a maxaligned buffer,
> so most of the changes I suggested are unnecessary. AFAICT, it's only
> the second fetch of t_len that is at any risk.

I think so too. And I agree that a comment about this would have been
rather helpful...

> 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...

> I have a suspicion that
> something in the impenetrable thicket that passes for prefix/suffix
> optimization in log_heap_update is forcing the WAL-logged tuple length to
> be rounded off to sizeof(int) (*not* MAXALIGN).

I don't think so, because the prefix optimization is essentially
disabled for logical...

> So I now think my previous patch is overkill, and we should instead use
> something like the attached.

Looks good to me. Thanks!

- Andres

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message IanB 2016-04-14 22:49:53 Re: BUG #14083: 'postgresql95-setup initdb' breaks inside docker container
Previous Message Tom Lane 2016-04-14 19:24:40 Re: Bus error in pg_logical_slot_get_changes (9.4.7, sparc)