| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Heath Lord <heath(dot)lord(at)crunchydata(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: "could not reattach to shared memory" on buildfarm member dory |
| Date: | 2018-05-01 00:24:19 |
| Message-ID: | 20180501002419.onmikldoe2ssjauq@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Him
On 2018-04-30 20:01:40 -0400, Tom Lane wrote:
> What seems like a plausible theory at this point is that the apparent
> asynchronicity is due to the allocation being triggered by a different
> thread, and the fact that our added monitoring code seems to make the
> failure more likely can be explained by that code changing the timing.
> But what thread could it be? It doesn't really look to me like either
> the signal thread or the timer thread could eat 4MB.
It seems plausible that the underlying allocator allocates larger chunks
to serve small allocations. But we don't seem to have started any threads
at PGSharedMemoryReAttach() time? So it'd have to be something else that
starts threads.
Heath, could you use process explorer or such to check which processes
are running inside a working backend process?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Юрий Соколов | 2018-05-01 01:31:26 | Re: [HACKERS] Clock with Adaptive Replacement |
| Previous Message | Andres Freund | 2018-05-01 00:19:49 | Re: [HACKERS] Clock with Adaptive Replacement |