Re: simplifying foreign key/RI checks

From: Tatsuro Yamada <tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: simplifying foreign key/RI checks
Date: 2021-01-27 07:07:01
Message-ID: 45ddca3d-5534-799d-ae71-ee21b3c6659c@nttcom.co.jp_1
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Amit-san,

> + case TM_Invisible:
> + elog(ERROR, "attempted to lock invisible tuple");
> + break;
> +
> + case TM_SelfModified:
> + case TM_BeingModified:
> + case TM_WouldBlock:
> + elog(ERROR, "unexpected table_tuple_lock status: %u", res);
> + break;
>
> + default:
> + elog(ERROR, "unrecognized table_tuple_lock status: %u", res);
>
> All of these are meant as debugging elog()s for cases that won't
> normally occur. IIUC, the discussion at the linked thread excludes
> those from consideration.

Thanks for your explanation.
Ah, I reread the thread, and I now realized that user visible log messages
are the target to replace. I understood that that elog() for the cases won't
normally occur. Sorry for the noise.

Regards,
Tatsuro Yamada

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-01-27 07:09:14 Re: FailedAssertion in heap_index_delete_tuples at heapam.c:7220
Previous Message Masahiko Sawada 2021-01-27 06:58:43 Re: New IndexAM API controlling index vacuum strategies