| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Heath Lord <heath(dot)lord(at)crunchydata(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, joseph(dot)ayers(at)crunchydata(dot)com |
| Subject: | Re: "could not reattach to shared memory" on buildfarm member dory |
| Date: | 2019-04-02 14:09:00 |
| Message-ID: | 18088.1554214140@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)com> writes:
> I can reproduce the 4 MiB allocations described
> in https://postgr.es/m/29823.1525132900@sss.pgh.pa.us; a few times per
> "vcregress check", they emerge in the middle of PGSharedMemoryReAttach().
> The 4 MiB allocations are stacks for new threads of the default thread
> pool[1].
Hah! It is great to finally have an understanding of what is happening
here.
I worry that your proposed fix is unstable, in particular this assumption
seems shaky:
> + * ... The idea is that, if the allocator handed out
> + * REGION1 pages before REGION2 pages at one occasion, it will do so whenever
> + * both regions are free.
I wonder whether it's possible to address this by configuring the "default
thread pool" to have only one thread? It seems like the extra threads are
just adding backend startup overhead to no benefit, since we won't use 'em.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-04-02 15:07:09 | Re: partitioned tables referenced by FKs |
| Previous Message | Michael Banck | 2019-04-02 14:02:59 | Re: Progress reporting for pg_verify_checksums |