On Wed, Oct 30, 2013 at 9:26 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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?
No. That's why the identifier being assigned to has "dsm" in it. I'll respond to this in more detail in a separate post. > 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? Good questions. I think that my previous theory was wrong, and that the patch from Amit which I pushed a while ago should fix the breakage. > BTW, regardless of the specific properties of random(), surely you ought > to have code in there that would cope with a name collision. I do have code in there to cope with a name collision. However, that doesn't mean it's good for it to choose the same name for the segment by default every time. If we were going to do it that way I ought to have just made it serial (PostgreSQL.0, 1, 2, 3, ...) instead of using random numbers to name them. The reason I didn't do that is to minimize the chances of collisions actually happening - and especially to minimize the chances of a large number of collisions happening. Especially for System V shared memory, the namespace is rather constrained, so bouncing around randomly through the namespace makes it unlikely that we'll hit a whole bunch of identifiers in a row that are all already in use by some other postmaster or, indeed, a process unrelated to PostgreSQL. A linear scan starting at any fixed value wouldn't have that desirable property. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers