Re: SKIP LOCKED DATA (work in progress)

On 16 May 2014 13:21, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> On 05/16/2014 04:46 PM, Craig Ringer wrote:
> >
> > I'll follow up with the patch and a git tree when it's ready, hopefully
> > tonight.
>
> Here's a rebased version of Simon's original patch that runs on current
> master.
>
> I still need to merge the isolation tests for it merged and sorted out,
> and after re-reading it I'd like to change "waitMode" into an enum, not
> just some #defines .
>
> Hope it's useful for comparison and ideas.

Thank you! At first glance they're sort of similar which is reassuring.
I'm especially interested in the buffer release semantics which I was
confused about and will look into that (to resolve the TODO notes in my
patch).

I noticed that in applyLockingClause, Simon has "rc->waitMode |= waitMode".
Is that right? The values are 0, 1, and 2, but if you had both NOWAIT and
SKIP LOCKED somewhere in your query you could up with rc->waitMode == 3
unless I'm mistaken. In my patch I have code that would give precedence to
NOWAIT, though looking at it again it could be simpler. (One reviewer
pointed out, that it should really be a single unified enum. In fact I have
been a bit unsure about what scope such an enumeration should have in the
application -- could it even be used in parser code? I tried to follow
existing examples which is why I used #define macros in gram.y).

From a bikeshed colour point of view:
* I used SKIP LOCKED DATA like DB2, and Simon used SKIP LOCKED like
Oracle, and I guess shorter is sweeter
* I used the term wait_policy and an enum, Simon used waitMode and an int
* I had noWait and skipLocked travelling separately in some places, Simon
had a single parameter, which is much better

Best regards,
Thomas Munro