| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | potential stuck lock in SaveSlotToPath() |
| Date: | 2020-03-18 15:46:23 |
| Message-ID: | 56a138c5-de61-f553-7e8f-6789296de785@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
When SaveSlotToPath() is called with elevel=LOG, the early exits don't
release the slot's io_in_progress_lock. Fix attached.
This could result in a walsender being stuck on the lock forever. A
possible way to get into this situation is if the offending code paths
are triggered in a low disk space situation. (This is how it was found;
maybe there are other ways.)
Pavan Deolasee and Craig Ringer worked on this issue. I'm forwarding it
on their behalf.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Drop-slot-s-LWLock-before-returning-from-SaveSlotToP.patch | text/plain | 2.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2020-03-18 15:53:26 | Re: Multivariate MCV list vs. statistics target |
| Previous Message | Magnus Hagander | 2020-03-18 15:37:21 | Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side |