Re: tablecmds: Open pg_class only when an update is required

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: tablecmds: Open pg_class only when an update is required
Date: 2025-12-12 03:14:22
Message-ID: F061684B-840F-4905-A58C-2D72B3BA162D@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Dec 11, 2025, at 21:17, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> On Thu, Dec 11, 2025 at 12:45 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>>
>> Hi Hackers,
>>
>> I just noticed that relation_mark_replica_identity() unconditionally opened pg_class with RowExclusiveLock even in cases where relreplident has no change, which incurred unnecessary relation opens, lock acquisition.
>>
>> I just made a tiny refactor that defers opening pg_class until we know that an update to relreplident is required.
>
> I think we need to lock the relation before fetching the tuple so that
> the field being read remains consistent. Instead of upgrading the lock
> which can deadlock, we get hold of row exclusive lock right at the
> beginning.
>
> --
> Best Wishes,
> Ashutosh Bapat

Hi Ashutosh,

Thanks for the explanation, so I withdraw this patch.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2025-12-12 03:22:55 Re: Improve pg_sync_replication_slots() to wait for primary to advance
Previous Message Chao Li 2025-12-12 02:59:53 Re: enhance wraparound warnings