Re: logical decoding - reading a user catalog table

From: Steve Singer <steve(at)ssinger(dot)info>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: logical decoding - reading a user catalog table
Date: 2014-11-14 03:23:02
Message-ID: BLU436-SMTP7916FD4D25D99A9B58D5E1DC8C0@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)entry=0xbfa8a0 <CurrentSnapshotData>,
sourcexid=sourcexid(at)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(at)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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sam Saffron 2014-11-14 03:31:39 Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4
Previous Message Stephen Frost 2014-11-14 02:18:17 Re: On the warpath again about ill-considered inclusion nests