After some further testing, I noticed a case that wasn't handled in
heap_update, which I also fixed. I reworded some comments here and
there, and pushed to all branches.
Further testing and analysis is welcome.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development,
Robert Haas wrote:
> I see the patch, but I don't see much explanation of why the patch is
> correct, which I think is pretty scary in view of the number of
> mistakes we've already made in this area. The comments just say:
>
> + * A tuple that has HEAP_XMAX_IS_MULTI and HEAP_XMAX_LOCK_ONLY but
Alvaro Herrera wrote:
> Robert Haas wrote:
> > On Fri, Jun 17, 2016 at 9:33 AM, Andrew Gierth
> > wrote:
> > >> "Robert" == Robert Haas writes:
> > > >> Why is the correct rule not "check for and ignore pre-upgrade mxids
> > > >> before even trying to fetch members"?
> > >
> > > Robert> I
Robert Haas wrote:
> On Fri, Jun 17, 2016 at 9:33 AM, Andrew Gierth
> wrote:
> >> "Robert" == Robert Haas writes:
> > >> Why is the correct rule not "check for and ignore pre-upgrade mxids
> > >> before even trying to fetch members"?
> >
> > Robert> I entirely believe that's the correct ru
On Fri, Jun 17, 2016 at 9:33 AM, Andrew Gierth
wrote:
>> "Robert" == Robert Haas writes:
> >> Why is the correct rule not "check for and ignore pre-upgrade mxids
> >> before even trying to fetch members"?
>
> Robert> I entirely believe that's the correct rule, but doesn't
> Robert> implem
Alvaro Herrera wrote:
> Andrew Gierth wrote:
> > Why is the correct rule not "check for and ignore pre-upgrade mxids
> > before even trying to fetch members"?
>
> I propose something like the attached patch, which implements that idea.
Here's a backpatch of that to 9.3 and 9.4.
I tested this by
Andrew Gierth wrote:
> > "Alvaro" == Alvaro Herrera writes:
>
> >> (It can, AFAICT, be inside the currently valid range due to
> >> wraparound, i.e. without there being a valid pg_multixact entry for
> >> it, because AFAICT in 9.2, once the mxid is hinted dead it is never
> >> again eithe
> "Robert" == Robert Haas writes:
>> Why is the correct rule not "check for and ignore pre-upgrade mxids
>> before even trying to fetch members"?
Robert> I entirely believe that's the correct rule, but doesn't
Robert> implementing it require a crystal balll?
Why would it? Pre-9.3 mxids
On Thu, Jun 16, 2016 at 4:50 AM, Andrew Gierth
wrote:
> Why is the correct rule not "check for and ignore pre-upgrade mxids
> before even trying to fetch members"?
I entirely believe that's the correct rule, but doesn't implementing
it require a crystal balll?
--
Robert Haas
EnterpriseDB: http:
> "Alvaro" == Alvaro Herrera writes:
>> (It can, AFAICT, be inside the currently valid range due to
>> wraparound, i.e. without there being a valid pg_multixact entry for
>> it, because AFAICT in 9.2, once the mxid is hinted dead it is never
>> again either looked up or cleared, so it can
Alvaro Herrera wrote:
> Andrew Gierth wrote:
> > Why is the correct rule not "check for and ignore pre-upgrade mxids
> > before even trying to fetch members"?
>
> I propose something like the attached patch, which implements that idea.
Hm, this doesn't apply cleanly to 9.4. I'll need to come up
Andrew Gierth wrote:
> But that leaves an obvious third issue: it's all very well to ignore the
> pre-upgrade (pre-9.3) mxid if it's older than the cutoff or it's in the
> future, but what if it's actually inside the currently valid range?
> Looking it up as though it were a valid mxid in that cas
> "Alvaro" == Alvaro Herrera writes:
Alvaro> I think that was a good choice in general so that
Alvaro> possibly-data-eating bugs could be reported, but there's a
Alvaro> problem in the specific case of tuples carried over by
Alvaro> pg_upgrade whose Multixact is "further in the future" co
Stephen Frost wrote:
> Greetings,
>
> Looks like we might not be entirely out of the woods yet regarding
> MultiXactId's. After doing an upgrade from 9.2.6 to 9.3.4, we saw the
> following:
>
> ERROR: MultiXactId 6849409 has not been created yet -- apparent wraparound
>
> The table c
On 2014-04-23 16:30:05 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > I think this patch is a seriously bad idea. For one, it's not actually
> > doing anything about the problem - the tuple can be accessed without
> > freezing getting involved.
>
> Normal access other than freeze is no
Andres Freund wrote:
> I think this patch is a seriously bad idea. For one, it's not actually
> doing anything about the problem - the tuple can be accessed without
> freezing getting involved.
Normal access other than freeze is not a problem, because other code
paths do check for HEAP_XMAX_INVAL
On April 23, 2014 8:51:21 PM CEST, Alvaro Herrera
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
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
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
> >
Bruce Momjian wrote:
> On Wed, Apr 23, 2014 at 03:01:02PM -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > On 2014-03-31 08:54:53 -0300, Alvaro Herrera wrote:
> > > > My conclusion here is that some part of the code is failing to examine
> > > > XMAX_INVALID before looking at the value s
On Wed, Apr 23, 2014 at 03:01:02PM -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2014-03-31 08:54:53 -0300, Alvaro Herrera wrote:
> > > My conclusion here is that some part of the code is failing to examine
> > > XMAX_INVALID before looking at the value stored in xmax itself. There
>
Andres Freund wrote:
> On 2014-03-31 08:54:53 -0300, Alvaro Herrera wrote:
> > My conclusion here is that some part of the code is failing to examine
> > XMAX_INVALID before looking at the value stored in xmax itself. There
> > ought to be a short-circuit. Fortunately, this bug should be pretty
>
On Mon, Mar 31, 2014 at 09:36:03AM -0400, Stephen Frost wrote:
> Andres,
>
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > Without having looked at the code, IIRC this looks like some place
> > misses passing allow_old=true where it's actually required. Any chance
> > you can get a backtrace
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > I think this rule is wrong. I think the rule ought to be something like
> > "if the XMAX_INVALID bit is set, then reset whatever is there if there
> > is something; if the bit is not set, proceed as today". Otherwise we
> > risk reading garba
Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2014-03-31 08:54:53 -0300, Alvaro Herrera wrote:
> > > My conclusion here is that some part of the code is failing to examine
> > > XMAX_INVALID before looking at the value stored in xmax itself. There
> > > ought to be a short-circuit. Fortunat
Andres Freund wrote:
> On 2014-03-31 08:54:53 -0300, Alvaro Herrera wrote:
> > My conclusion here is that some part of the code is failing to examine
> > XMAX_INVALID before looking at the value stored in xmax itself. There
> > ought to be a short-circuit. Fortunately, this bug should be pretty
>
Stephen Frost wrote:
> Further review leads me to notice that both HEAP_XMAX_IS_MULTI and
> HEAP_XMAX_INVALID are set:
>
> t_infomask | 6528
>
> 6528 decimal -> 0x1980
>
> 0001 1001 1000
>
> Which gives us:
>
> 1000 - HEAP_XMAX_LOCK_ONLY
> 0001 - HEAP_XMIN_
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-03-31 09:09:08 -0400, Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > I guess I wasn't expecting that too-old values would last longer than a
> > > full wraparound cycle. Maybe the right fix is just to have
Andres,
* Andres Freund (and...@2ndquadrant.com) wrote:
> Without having looked at the code, IIRC this looks like some place
> misses passing allow_old=true where it's actually required. Any chance
> you can get a backtrace for the error message? I know you said somewhere
> below that you'd worked
On 2014-03-31 09:09:08 -0400, Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > I guess I wasn't expecting that too-old values would last longer than a
> > full wraparound cycle. Maybe the right fix is just to have the second
> > check also conditional on allow_old.
>
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> I guess I wasn't expecting that too-old values would last longer than a
> full wraparound cycle. Maybe the right fix is just to have the second
> check also conditional on allow_old.
I don't believe this was a wraparound case.
> Anyway, it's n
Andres Freund wrote:
> On 2014-03-31 09:19:12 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > On 2014-03-31 08:54:53 -0300, Alvaro Herrera wrote:
> > > > My conclusion here is that some part of the code is failing to examine
> > > > XMAX_INVALID before looking at the value stored in xma
On 2014-03-31 09:19:12 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2014-03-31 08:54:53 -0300, Alvaro Herrera wrote:
> > > My conclusion here is that some part of the code is failing to examine
> > > XMAX_INVALID before looking at the value stored in xmax itself. There
> > > ought to
Andres Freund wrote:
> On 2014-03-31 08:54:53 -0300, Alvaro Herrera wrote:
> > My conclusion here is that some part of the code is failing to examine
> > XMAX_INVALID before looking at the value stored in xmax itself. There
> > ought to be a short-circuit. Fortunately, this bug should be pretty
>
On 2014-03-31 08:54:53 -0300, Alvaro Herrera wrote:
> My conclusion here is that some part of the code is failing to examine
> XMAX_INVALID before looking at the value stored in xmax itself. There
> ought to be a short-circuit. Fortunately, this bug should be pretty
> harmless.
>
> .. and after
Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > I have the pre-upgrade database and can upgrade/rollback/etc that pretty
> > easily. Note that the table contents weren't changed during the
> > upgrade, of course, and so the 9.2.6 instance has HEAP_XMAX_IS_MULTI set
> > while
Hi,
On 2014-03-30 00:00:30 -0400, Stephen Frost wrote:
> Greetings,
>
> Looks like we might not be entirely out of the woods yet regarding
> MultiXactId's. After doing an upgrade from 9.2.6 to 9.3.4, we saw the
> following:
>
> ERROR: MultiXactId 6849409 has not been created yet -- app
* Stephen Frost (sfr...@snowman.net) wrote:
> I have the pre-upgrade database and can upgrade/rollback/etc that pretty
> easily. Note that the table contents weren't changed during the
> upgrade, of course, and so the 9.2.6 instance has HEAP_XMAX_IS_MULTI set
> while t_xmax is 6849409 for the tupl
All,
* Stephen Frost (sfr...@snowman.net) wrote:
> Looks like we might not be entirely out of the woods yet regarding
> MultiXactId's. After doing an upgrade from 9.2.6 to 9.3.4, we saw the
> following:
>
> ERROR: MultiXactId 6849409 has not been created yet -- apparent wraparound
Whil
Greetings,
Looks like we might not be entirely out of the woods yet regarding
MultiXactId's. After doing an upgrade from 9.2.6 to 9.3.4, we saw the
following:
ERROR: MultiXactId 6849409 has not been created yet -- apparent wraparound
The table contents can be select'd out and match t
40 matches
Mail list logo
