Re: Something fishy happening on frogmouth

On Wed, Oct 30, 2013 at 9:26 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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