Re: logical decoding - reading a user catalog table - Mailing list pgsql-hackers

From Steve Singer
Subject Re: logical decoding - reading a user catalog table
Date
Msg-id BLU436-SMTP7916FD4D25D99A9B58D5E1DC8C0@phx.gbl
Whole thread Raw
In response to Re: logical decoding - reading a user catalog table  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: logical decoding - reading a user catalog table  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 11/13/2014 02:44 PM, Andres Freund wrote:
> H

> I've pushed a fix for a bug that could possibly also cause
> this. Although it'd be odd that it always hits the user catalog
> table. Except if your tests mostly modify the slony tables, but do not
> do much DDL otherwise?

The test I was running doesn't do DDL, so only the user catalog tables 
would have changes being tracked.

I still sometimes get the error. When I get sometime on the weekend I'll 
work on some detailed  instructions on how to grab and setup the various 
components to replicate this test.

Also since updating (to 2c267e47afa4f9a7c) I've seen a assertion failure 
in a normal client connection, not the walsender

#3  0x00000000006b4978 in GetSerializableTransactionSnapshotInt (    snapshot=snapshot@entry=0xbfa8a0
<CurrentSnapshotData>,   sourcexid=sourcexid@entry=0) at predicate.c:1738
 
#4  0x00000000006b66c3 in GetSafeSnapshot (origSnapshot=<optimized out>)    at predicate.c:1517
#5  GetSerializableTransactionSnapshot (    snapshot=0xbfa8a0 <CurrentSnapshotData>) at predicate.c:1598
#6  0x00000000007d16dd in GetTransactionSnapshot () at snapmgr.c:200
#7  0x00000000006c0e35 in exec_simple_query (    query_string=0x1fd01b8 "select ev_origin, ev_seqno, 
ev_timestamp,        ev_snapshot, 
\"pg_catalog\".txid_snapshot_xmin(ev_snapshot), 
\"pg_catalog\".txid_snapshot_xmax(ev_snapshot), 
coalesce(ev_provider_xid,\""...)    at postgres.c:959
#8  PostgresMain (argc=<optimized out>, argv=argv@entry=0x1f5ab50,


I have no idea if this has anything to do with your recent changes or 
some other change. I haven't so far been able to replicate that since 
the first time I saw it.



>> I'll send you tar of the data directory off list with things in this state.
>>
>>> Do you have a testcase that would allow me to easily reproduce the
>>> problem?
>> I don't have a isolated test case that does this.  The test that I'm hitting
>> this with does lots of stuff and doesn't even always hit this.
> If it still happens, could you send me instructions of how to reproduce
> the problem after cloning the necessary source repositories? It's quite
> hard to validate a possible fix otherwise.
>
> Greetings,
>
> Andres Freund
>




pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: On the warpath again about ill-considered inclusion nests
Next
From: Sam Saffron
Date:
Subject: Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4