Re: simplifying foreign key/RI checks - Mailing list pgsql-hackers

From Tatsuro Yamada
Subject Re: simplifying foreign key/RI checks
Date
Msg-id 8c17a76f-bd60-dcc0-dca7-6a438f57f23d@nttcom.co.jp_1
Whole thread Raw
In response to Re: simplifying foreign key/RI checks  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: simplifying foreign key/RI checks  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
Hi Amit-san,

On 2021/01/25 18:19, Amit Langote wrote:
> On Mon, Jan 25, 2021 at 9:24 AM Corey Huinker <corey.huinker@gmail.com> wrote:
>> On Sun, Jan 24, 2021 at 6:51 AM Amit Langote <amitlangote09@gmail.com> wrote:
>>> Here's v5.
>>
>> v5 patches apply to master.
>> Suggested If/then optimization is implemented.
>> Suggested case merging is implemented.
>> Passes make check and make check-world yet again.
>> Just to confirm, we don't free the RI_CompareHashEntry because it points to an entry in a hash table which is
TopMemoryContextaka lifetime of the session, correct?
 
> 
> Right.
> 
>> Anybody else want to look this patch over before I mark it Ready For Committer?
> 
> Would be nice to have others look it over.  Thanks.


Thanks for creating the patch!

I tried to review the patch. Here is my comment.

* According to this thread [1], it might be better to replace elog() with
   ereport() in the patch.

[1]: https://www.postgresql.org/message-id/flat/92d6f545-5102-65d8-3c87-489f71ea0a37%40enterprisedb.com

Thanks,
Tatsuro Yamada




pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: pg_replication_origin_drop API potential race condition
Next
From: Peter Smith
Date:
Subject: Re: Single transaction in the tablesync worker?