Re: FlexLocks

On Thu, Nov 17, 2011 at 10:01 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

>
> I am not convinced that that's a better API.  I mean, consider
> something like this:
>
>    /*
>     * OK, let's do it.  First let other backends know I'm in ANALYZE.
>     */
>    LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
>    MyProc->vacuumFlags |= PROC_IN_ANALYZE;
>    LWLockRelease(ProcArrayLock);

> I'm not sure exactly how you'd proposed to rewrite that, but I think
> it's almost guaranteed to be more than three lines of code.

I would guess the ReqRes will look something like this where
ReqResRequest/Response would probably be union of all various requests
and responses, one for each type of request:

struct ReqRes {
ReqResRequestType reqtype;
ReqResRequest req;
ReqResResponse res;
}

The code above can be rewritten as:

reqRes.reqtype = RR_PROC_SET_VACUUMFLAGS;
reqRes.req.set_vacuumflags.flags = PROC_IN_ANALYZE;
LWLockExecute(ProcArrayLock, LW_EXCLUSIVE, &reqRes);

I mean, I agree it doesn't look exactly elegant and the number of
requests types and their handling may go up a lot, but we need to do
this only for those heavily contended locks. Other callers can
continue with the current code style. But with this general
infrastructure, there will be still be a way to do this.

>  Also, you
> can't assume that the "work" can be done equally well by any backend.
> In this case it could, because the PGPROC structures are all in shared
> memory, but that won't work for something like GetSnapshotData(),
> which needs to copy a nontrivial amount of data into backend-local
> memory.

Yeah, I am not suggesting we should do (even though I think it should
be possible with appropriate input/output data) this everywhere. But
places where this can done, like end-transaction stuff, the
infrastructure might be quite useful.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com