Re: pg19b1: stuck in LockBuffer

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Subject: Re: pg19b1: stuck in LockBuffer
Date: 2026-07-30 20:29:54
Message-ID: amu0Qn8KVWz4cL8r@pryzbyj2023
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

No, I can't recreate the problem on demand.
It look ~7 weeks running pg19b1 before we hit the issue.
I already upgraded the instance, so let's wait to see what happens.

@Chao Li: thanks for pointing out that patch.

On Thu, Jul 30, 2026 at 03:09:41PM -0400, Peter Geoghegan wrote:
> On Wed, Jul 29, 2026 at 11:12 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> > Very possibly. It does seem plausible that the patch mentioned by Chao
> > Li could explain this. Do you agree?
>
> That definitely seems possible, but hard to say with much confidence.
> Even if it isn't the bug fix he mentioned, it could be another one. I
> noticed that we're vacuuming the catalog index
> pg_attribute_relid_attnam_index, and it's possible that that matters
> here (this was probably triggered by churning through temp tables or
> something, you didn't say anything about the workload you were
> testing).
>
> Can you recreate the problem on demand using the same build? If you
> can recreate the problem that way, it would certainly be useful to try
> running the same steps against Postgres 19 git tip as of today, to see
> if the problem goes away. That experiment seems most likely to be
> informative/useful, at least to me.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David K 2026-07-30 20:36:00 Re: Bug: XLogReader mishandles oversized multi-page xl_tot_len (potential memory corruption)
Previous Message Sami Imseih 2026-07-30 19:56:30 Re: Improve pg_stat_statements scalability