Re: Something fishy happening on frogmouth
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Andrew Dunstan <andrew@dunslane.net>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2013-10-30T13:37:18Z
Lists: pgsql-hackers
On 2013-10-30 09:26:42 -0400, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > If I'm reading this correctly, the last three runs on frogmouth have > > all failed, and all of them have failed with a complaint about, > > specifically, Global/PostgreSQL.851401618. Now, that really shouldn't > > be happening, because the code to choose that number looks like this: > > > dsm_control_handle = random(); > > Isn't this complaining about the main shm segment, not a DSM extension? Don't think so, that has a ":" in the name. But I think this touches a fair point, I think we need to make all the dsm error messages more distinctive. The history since this has been committed makes it likely that there will be more errors. > Also, why is the error "not enough space", rather than something about > a collision? And if this is the explanation, why didn't the previous > runs probing for allowable shmem size fail? Yea, I don't think this explains the issue but something independent that needs to be fixed. > BTW, regardless of the specific properties of random(), surely you ought > to have code in there that would cope with a name collision. There actually is code that retries, but only for EEXISTS. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Initialize random() in bootstrap/stand-alone postgres and in initdb.
- 402da7054f34 9.3.25 landed
- 401228183a63 9.4.20 landed
- d68d5adfdcae 9.5.15 landed
- 89f2b64da370 11.0 landed
- 4232cff11b84 10.6 landed
- 329cacb90270 9.6.11 landed
- d18f6674bd60 12.0 landed
-
Modify dynamic shared memory code to use Size rather than uint64.
- d2aecaea1555 9.4.0 cited