From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Georgy Buranov <gburanov(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PostgreSQL logical decoder output plugin - unchanged toast data |
Date: | 2018-09-04 16:42:40 |
Message-ID: | 20180904164240.mehuqs6ghkapqgw5@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-09-04 11:45:10 +0200, Georgy Buranov wrote:
> Hi Andres. Thank you very much for your help.
>
> I tried the following solution and I have some problems.
>
> * I have 9.6 postgres and I do not have separate field for rd_pkindex
> * All I have is rd_replidindex field. Usually (when REPLICA IDENTITY
> is NOT FULL), it still contains the primary key
> * But in the case of REPLICA IDENTITY FULL - rd_replidindex is NULL
> and rd_pkindex does not exist
>
> So, is there a way to get the primary key on 9.6 postgres?
You have to to query the syscache yourself, in that case. I know
nothing about what you're doing in your output plugin. In the ones I
wrote there's a side-cache for per-relation output plugin specific data,
do you have something like that? You can probably just crib the code
for the lookup from dblink.c:get_pkey_attnames(). If you have a cache,
itmight be worth caching the results.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-09-04 16:50:25 | Re: pointless check in RelationBuildPartitionDesc |
Previous Message | Andrew Gierth | 2018-09-04 16:38:50 | Re: Bug fix for glibc broke freebsd build in REL_11_STABLE |