On April 23, 2014 8:51:21 PM CEST, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>Bruce Momjian wrote:
>> On Wed, Apr 23, 2014 at 03:42:14PM -0300, Alvaro Herrera wrote:
>> > > > I still don't know under what circumstances this situation
>could arise.
>> > > > This seems most strange to me. I would wonder about this to be
>just
>> > > > papering over a different bug elsewhere, except that we know
>this tuple
>> > > > comes from a pg_upgraded table and so I think the only real
>solution is
>> > > > to cope.
>> > >
>> > > Shouldn't we log something at least if we are unsure of the
>cause?
>> >
>> > I don't know. Is it possible that XMAX_IS_MULTI got set because of
>> > cosmic rays? At this point that's the only explanation that makes
>sense
>> > to me. And I'm not sure what to do about this until we know more
>--
>> > more user reports of this problem, for instance.
>> >
>> > I don't see any reasonable way to distinguish this particular kind
>of
>> > multixact-out-of-bounds situation from any other, so not sure what
>else
>> > to log either (you can see that we already emit an error message.)
>>
>> I guess I am lost then. I thought it supressed the error. What does
>> the patch do?
>
>You're right, it does. I am not sure I would apply it.
I think this patch is a seriously bad idea. For one, it's not actually doing anything about the problem - the tuple can
beaccessed without freezing getting involved. For another, it will increase wall traffic for freezing of short lived
tuplesconsiderably, without any benefit.
Andres
--
Please excuse brevity and formatting - I am writing this on my mobile phone.
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
