Re: longfin and tamandua aren't too happy but I'm not sure why - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: longfin and tamandua aren't too happy but I'm not sure why
Date
Msg-id CAFiTN-t71ciSckMzixAhrF9py7oRO6xszKi4mTRwjuucXr5tpw@mail.gmail.com
Whole thread Raw
In response to Re: longfin and tamandua aren't too happy but I'm not sure why  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: longfin and tamandua aren't too happy but I'm not sure why
List pgsql-hackers
On Wed, Sep 28, 2022 at 9:40 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Wed, Sep 28, 2022 at 2:59 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > ... also, lapwing's not too happy [1].  The alter_table test
> > expects this to yield zero rows, but it doesn't:
>
> By looking at regression diff as shown below, it seems that we are
> able to get the relfilenode from the Oid using
> pg_relation_filenode(oid) but the reverse mapping
> pg_filenode_relation(reltablespace, relfilenode) returned NULL.
>

It was a silly mistake, I used the F_OIDEQ function instead of
F_INT8EQ. Although this was correct on the 0003 patch where we have
removed the tablespace from key, but got missed in this :(

I have locally reproduced this in a 32 bit machine consistently and
the attached patch is fixing the issue for me.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: In-placre persistance change of a relation
Next
From: "wangw.fnst@fujitsu.com"
Date:
Subject: RE: Data is copied twice when specifying both child and parent table in publication