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
> Pavan> always decide to use sort-based implementation
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
> Pavan> always decide to use sort-based implementation
> "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 if the columns support ord
Hi All,
I stumbled upon this test case from the master that sets an assertion
failure (see stack trace at the end) on REL9_5_STABLE.
create temp table gstest4(id integer, v integer,
unhashable_col bit(4), unsortable_col xid);
insert into gstest4
values (1,1,b'','1'),
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 DBA,
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
> || TransactionIdIsCurrentTransa
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 today's
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 all along. Or am
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 I could run ou
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 with --enable-
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 lis
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 wa
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
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 ...
>
> HeapTupleSatisfiesUpdate()
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
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
> || TransactionIdIsCurre
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 that finally bre
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 || TransactionIdIsCurrentTransactionId((
(!((tup)->t_inf
18 matches
Mail list logo
