| From: | Tomas Vondra <tomas(at)vondra(dot)me> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: scalability bottlenecks with (many) partitions (and more) |
| Date: | 2024-09-12 23:44:58 |
| Message-ID: | c7282183-6a74-4797-9659-92e948e713b5@vondra.me |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Turns out there was a bug in EXEC_BACKEND mode, causing failures on the
Windows machine in CI. AFAIK the reason is pretty simple - the backends
don't see the number of fast-path groups postmaster calculated from
max_locks_per_transaction.
Fixed that by calculating it again in AttachSharedMemoryStructs, which
seems to have done the trick. With this the CI builds pass just fine,
but I'm not sure if EXEC_BACKENDS may have some other issues with the
PGPROC changes. Could it happen that the shared memory gets mapped
differently, in which case the pointers might need to be adjusted?
regards
--
Tomas Vondra
| Attachment | Content-Type | Size |
|---|---|---|
| v20240913-0001-Increase-the-number-of-fast-path-lock-slot.patch | text/x-patch | 13.9 KB |
| v20240913-0002-Set-fast-path-slots-using-max_locks_per_tr.patch | text/x-patch | 14.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2024-09-13 00:10:02 | Re: Avoid dead code (contrib/pg_visibility/pg_visibility.c) |
| Previous Message | Alexander Korotkov | 2024-09-12 23:38:40 | Re: type cache cleanup improvements |