Re: logical decoding - reading a user catalog table

Поиск
Список
Период
Сортировка
От Steve Singer
Тема Re: logical decoding - reading a user catalog table
Дата
Msg-id BLU436-SMTP7916FD4D25D99A9B58D5E1DC8C0@phx.gbl
обсуждение исходный текст
Ответ на Re: logical decoding - reading a user catalog table  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: logical decoding - reading a user catalog table  (Andres Freund <andres@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: On the warpath again about ill-considered inclusion nests
Следующее
От: Sam Saffron
Дата:
Сообщение: Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4