On Tue, Oct 17, 2017 at 3:02 AM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Yeah, me too. If you see another way to fix the problem, let's discuss
> it.
I doubt that there is a better way.
> I think a possible way is to avoid considering that the relfrozenxid
> value computed by the caller is final.
While that alternative seems possible, it also seems riskier.
> One thing I didn't quite investigate is why this bug only shows up with
> multixacts so far. Is it just because multixacts provide an easy way to
> reproduce it, and that there are others, more difficult ways to cause
> the same problem without involving multixacts? If so, then the problem
> is likely present in 9.2 as well.
The obvious explanation (although not necessarily the correct one) is
that freezing didn't have a MultiXactIdGetUpdateXid() call in 9.2. The
way we pass down both cutoff_xid and cutoff_multi to
FreezeMultiXactId() seems like it might be involved in the data
corruption that we saw (the incorrect pruning/failed to find parent
tuple thing).
I might spend some time figuring this out later in the week. It's hard
to pin down, and I've only really started to learn about MultiXacts in
the past few months.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
