| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pg19b1: stuck in LockBuffer |
| Date: | 2026-07-30 19:09:41 |
| Message-ID: | CAH2-WznnOwoemfN6O43gYK=sbhF1CrJXWq4Kc-x8+VCANMpdxA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2026-07-30 19:12:00 | Re: [PATCH] Release replication slot on error in SQL-callable slot functions |
| Previous Message | Ayush Tiwari | 2026-07-30 17:56:39 | Re: datachecksums: handle invalid and dropped databases during enable |