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