Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune()
От | Noah Misch |
---|---|
Тема | Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() |
Дата | |
Msg-id | 20240109214447.88@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune()
|
Список | pgsql-bugs |
On Tue, Jan 09, 2024 at 03:59:19PM -0500, Peter Geoghegan wrote: > On Sat, Jan 6, 2024 at 3:24 PM Noah Misch <noah@leadboat.com> wrote: > > On Sun, Dec 31, 2023 at 03:53:34PM -0800, Peter Geoghegan wrote: > > > I am aware of a production database that appears to run into the same > > > problem. Inserts and concurrent cross-partition updates are used > > > heavily on this instance (the table in question uses partitioning). > > > Perhaps you happened upon a similar problematic production database, > > > and found this thread when researching the issue? Maybe we've both > > > seen the same problem in the wild? > > > > I did find this thread while researching the symptoms I was seeing. No > > partitioning where I saw them. > > I'm starting to think that partitioning was just a red herring. The > instance had problems in the presence of DELETEs, not UPDATEs (or > cross-partition UPDATEs). > > Did the affected system that you investigated happen to have an > atypically high number of databases? The system 15.4 system that I saw > the problem on had almost 3,000 databases. No, single-digit database count here.
В списке pgsql-bugs по дате отправления: