| 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/
| 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 |