On Tue, May 6, 2014 at 11:15 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, May 6, 2014 at 1:14 PM, Andres Freund <and...@2ndquadrant.com> wrote: > > On 2014-05-06 08:48:57 -0400, Robert Haas wrote: > >> On Tue, May 6, 2014 at 8:43 AM, Andres Freund <and...@2ndquadrant.com> wrote: > >> > The break because of refcnt == 1 doesn't generally seem to be a good > >> > idea. Why are we bailing if there's *any* segment that's in the process > >> > of being removed? I think the check should be there *after* the > >> > dsm_control->item[i].handle == seg->handle check? > >> > >> You are correct. Good catch. > > > > Fix attached. > > Committed, thanks. >
dsm_create(Size size, int flags)
{
..
/* Lock the control segment so we can register the new segment. */
LWLockAcquire(DynamicSharedMemoryControlLock, LW_EXCLUSIVE);
..
/* Verify that we can support an additional mapping. */
if (nitems >= dsm_control->maxitems)
{
if ((flags & DSM_CREATE_NULL_IF_MAXSEGMENTS) != 0)
{
dsm_impl_op(DSM_OP_DESTROY, seg->handle, 0, &seg->impl_private,
&seg->mapped_address, &seg->mapped_size, WARNING);
if (seg->resowner != NULL)
ResourceOwnerForgetDSM(seg->resowner, seg);
dlist_delete(&seg->node);
pfree(seg);
return NULL;
}
..
}
Is there a reason lock is not released in case we return NULL in above
code?
I am facing an issue in case we need to create many segments for
large inheritance hierarchy. Attached patch fixes the problem for me.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
release_lock_dsm_v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
