| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Xuneng Zhou <xunengzhou(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fix a relcache reference leak in reorderbuffer.c |
| Date: | 2026-08-19 02:34:56 |
| Message-ID: | aoUWUK0HyQ28Rk2h@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Aug 19, 2026 at 10:18:53AM +0800, Chao Li wrote:
> I just took a deeper look at the code. If we handle the continue
> defensively, then in theory nrelations could be 0. We should also
> defensively skip ReorderBufferApplyTruncate() when nrelations ==
> 0. Looking at a callback function, for example, pgoutput_truncate()
> in src/backend/replication/pgoutput/pgoutput.c appears to assume
> that nrelations > 0, it doesn't specially handle nrelations == 0.
Right. We tend to be careful in terms of the closes in
reorderbuffer.c anyway, so I've just applied the patch.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-08-19 02:36:15 | Re: pg_stat_database.checksum_failures misses single-page failures in backups |
| Previous Message | Chao Li | 2026-08-19 02:18:53 | Re: Fix a relcache reference leak in reorderbuffer.c |