Re: logical decoding - reading a user catalog table

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: logical decoding - reading a user catalog table
Дата
Msg-id 20141028173154.GC5873@awork2.anarazel.de
обсуждение исходный текст
Ответ на logical decoding - reading a user catalog table  (Steve Singer <steve@ssinger.info>)
Ответы Re: logical decoding - reading a user catalog table
Список pgsql-hackers
On 2014-10-25 18:18:07 -0400, Steve Singer wrote:
> My logical decoding plugin is occasionally getting this  error
> 
> "could not resolve cmin/cmax of catalog tuple"
> 
> I get this when my output plugin is trying to read one of the user defined
> catalog tables (user_catalog_table=true)

Hm. That should obviously not happen.

Could you describe how that table is modified? Does that bug happen
initially, or only after a while?

Do you have a testcase that would allow me to easily reproduce the
problem?

> I am not sure if this is a bug in the time-travel support in the logical
> decoding support of if I'm just using it wrong (ie not getting a sufficient
> lock on the relation or something).

I don't know yet...

> This is the interesting part of the stack trace
> 
> #4  0x000000000091bbc8 in HeapTupleSatisfiesHistoricMVCC
> (htup=0x7fffcf42a900,
>     snapshot=0x7f786ffe92d8, buffer=10568) at tqual.c:1631
> #5  0x00000000004aedf3 in heapgetpage (scan=0x28d7080, page=0) at
> heapam.c:399
> #6  0x00000000004b0182 in heapgettup_pagemode (scan=0x28d7080,
>     dir=ForwardScanDirection, nkeys=0, key=0x0) at heapam.c:747
> #7  0x00000000004b1ba6 in heap_getnext (scan=0x28d7080,
>     direction=ForwardScanDirection) at heapam.c:1475
> #8  0x00007f787002dbfb in lookupSlonyInfo (tableOid=91754, ctx=0x2826118,
>     origin_id=0x7fffcf42ab8c, table_id=0x7fffcf42ab88,
> set_id=0x7fffcf42ab84)
>     at slony_logical.c:663
> #9  0x00007f787002b7a3 in pg_decode_change (ctx=0x2826118, txn=0x28cbec0,
>     relation=0x7f787a3446a8, change=0x7f786ffe3268) at slony_logical.c:237
> #10 0x00000000007497d4 in change_cb_wrapper (cache=0x28cbda8, txn=0x28cbec0,
>     relation=0x7f787a3446a8, change=0x7f786ffe3268) at logical.c:704
> 
> 
> 
> Here is what the code in lookupSlonyInfo is doing
> ------------------
> 
>   sltable_oid = get_relname_relid("sl_table",slony_namespace);
> 
>   sltable_rel = relation_open(sltable_oid,AccessShareLock);
>   tupdesc=RelationGetDescr(sltable_rel);
>   scandesc=heap_beginscan(sltable_rel,
> GetCatalogSnapshot(sltable_oid),0,NULL);
>   reloid_attnum = get_attnum(sltable_oid,"tab_reloid");
> 
>   if(reloid_attnum == InvalidAttrNumber)
>       elog(ERROR,"sl_table does not have a tab_reloid column");
>   set_attnum = get_attnum(sltable_oid,"tab_set");
> 
>   if(set_attnum == InvalidAttrNumber)
>       elog(ERROR,"sl_table does not have a tab_set column");
>   tableid_attnum = get_attnum(sltable_oid, "tab_id");
> 
>   if(tableid_attnum == InvalidAttrNumber)
>       elog(ERROR,"sl_table does not have a tab_id column");
> 
>   while( (tuple = heap_getnext(scandesc,ForwardScanDirection) ))

(Except missing spaces ;)) I don't see anything obviously wrong with
this.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: "snapshot too large" error when initializing logical replication (9.4)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WIP: Access method extendability