| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: Potential deadlock in pgaio_io_wait() |
| Date: | 2025-08-04 06:34:41 |
| Message-ID: | CA+hUKG+Pymq0tgBC7b1opt-fnNrnxg8UMVFOEsFcofPVwfiqig@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Mon, Aug 4, 2025 at 5:54 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> I doubt it's very easy to reproduce with simple queries, but I assume
> if you had a SQL function that acquires a central LWLock and you ran
> concurrent queries SELECT COUNT(*) FROM t WHERE locking_function(x)
Hmm, that's a bad example as it has the wrong lock scope. Probably
would need a dedicated test to demonstrate with low level functions.
What I was trying to convey is that it's not a problem that can be hit
in practice without great effort as far as I know, but it does break
an intended pgaio architectural principle as I understand it.
Also I accidentally sent that to -bugs by fat fingering an
autocompletion. Moving to -hackers.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2025-08-04 08:34:38 | BUG #19008: Problems downloading metadata for dnf - probably missing private key (GPG signature) |
| Previous Message | Thomas Munro | 2025-08-04 05:54:45 | Potential deadlock in pgaio_io_wait() |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2025-08-04 06:37:58 | Re: CREATE PUBLICATION with 'publish_generated_columns' parameter specified but unassigned |
| Previous Message | Peter Smith | 2025-08-04 06:23:36 | CREATE PUBLICATION with 'publish_generated_columns' parameter specified but unassigned |