Re: [HACKERS] Assertion failure in REL9_5_STABLE

2017-04-28 Thread Pavan Deolasee
On Wed, Apr 19, 2017 at 11:19 AM, Andrew Gierth wrote: > > "Pavan" == Pavan Deolasee writes: > > Pavan> I am attaching a patch that throws a similar ERROR during > Pavan> planning even for 9.5. AFAICS in presence of grouping sets, we

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2017-04-18 Thread Pavan Deolasee
On Wed, Apr 19, 2017 at 11:19 AM, Andrew Gierth wrote: > > "Pavan" == Pavan Deolasee writes: > > Pavan> I am attaching a patch that throws a similar ERROR during > Pavan> planning even for 9.5. AFAICS in presence of grouping sets, we

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2017-04-18 Thread Andrew Gierth
> "Pavan" == Pavan Deolasee writes: Pavan> I am attaching a patch that throws a similar ERROR during Pavan> planning even for 9.5. AFAICS in presence of grouping sets, we Pavan> always decide to use sort-based implementation for grouping, but Pavan> do not check

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-09-09 Thread Alvaro Herrera
Marko Tiikkaja wrote: > Hi, > > Running one specific test from our application against REL9_5_STABLE > (current as of today) gives me this: Just pushed the fix. Thanks for the report! -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-17 Thread Alvaro Herrera
Marko Tiikkaja wrote: > Running one specific test from our application against REL9_5_STABLE > (current as of today) gives me this: > > #2 0x7effb59595be in ExceptionalCondition ( > conditionName=conditionName@entry=0x7effb5b27a88 "!(CritSectionCount > 0 > ||

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-16 Thread Alvaro Herrera
Andres Freund wrote: > Phew. Alvaro, are you tackling this? Sure. Marko Tiikkaja wrote: > There's a rolled back subtransaction that also did some magic on the rows > AFAICT. I can try and spend some time producing a smaller test case over > the weekend. No hurry since this missed the

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-16 Thread Andres Freund
On 2016-08-11 11:01:18 +0200, Marko Tiikkaja wrote: > On 11/08/16 8:48 AM, Michael Paquier wrote: > > On Thu, Aug 11, 2016 at 8:09 AM, Marko Tiikkaja wrote: > > > On 2016-08-11 12:09 AM, Alvaro Herrera wrote: > > > > > > > > BTW this is not a regression, right? It's been broken

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-11 Thread Marko Tiikkaja
On 11/08/16 8:48 AM, Michael Paquier wrote: On Thu, Aug 11, 2016 at 8:09 AM, Marko Tiikkaja wrote: On 2016-08-11 12:09 AM, Alvaro Herrera wrote: BTW this is not a regression, right? It's been broken all along. Or am I mistaken? You're probably right. I just hadn't realized

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-11 Thread Michael Paquier
On Thu, Aug 11, 2016 at 8:09 AM, Marko Tiikkaja wrote: > On 2016-08-11 12:09 AM, Alvaro Herrera wrote: >> >> BTW this is not a regression, right? It's been broken all along. Or am >> I mistaken? > > > You're probably right. I just hadn't realized I could run our app against > 9.5

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Marko Tiikkaja
On 2016-08-11 12:09 AM, Alvaro Herrera wrote: BTW this is not a regression, right? It's been broken all along. Or am I mistaken? You're probably right. I just hadn't realized I could run our app against 9.5 with --enable-cassert until last week. .m -- Sent via pgsql-hackers mailing

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Marko Tiikkaja
On 2016-08-10 11:01 PM, Alvaro Herrera wrote: Oh, I see ... so there's an update chain, and you're updating a earlier tuple. But the later tuple has a multixact and one of the members is the current transaction. I wonder how can you lock a tuple that's not the latest, where that update chain

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Alvaro Herrera
BTW this is not a regression, right? It's been broken all along. Or am I mistaken? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Alvaro Herrera
Marko Tiikkaja wrote: > On 2016-08-10 19:28, Alvaro Herrera wrote: > >Umm. AFAICS HeapTupleSatisfiesUpdate() only returns SelfUpdated after > >already calling HeapTupleHeaderGetCmax() (which obviously hasn't caught > >the same assertion). Something is odd there ... > >

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Marko Tiikkaja
On 2016-08-10 19:28, Alvaro Herrera wrote: Umm. AFAICS HeapTupleSatisfiesUpdate() only returns SelfUpdated after already calling HeapTupleHeaderGetCmax() (which obviously hasn't caught the same assertion). Something is odd there ... HeapTupleSatisfiesUpdate() returns HeapTupleBeingUpdated in

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Alvaro Herrera
Marko Tiikkaja wrote: > Hi, > > Running one specific test from our application against REL9_5_STABLE > (current as of today) gives me this: > > #2 0x7effb59595be in ExceptionalCondition ( > conditionName=conditionName@entry=0x7effb5b27a88 "!(CritSectionCount > 0 > ||

Re: [HACKERS] Assertion failure in REL9_5_STABLE

2016-08-10 Thread Tom Lane
Marko Tiikkaja writes: > The failure is a number of levels down a call stack of PL/PgSQL > functions, but I can reproduce it at will by calling the function. I > unfortunately can't narrow it down to a smaller test case, but attached > is an xlogdump of the session. The query