Hello,
At Thu, 17 Jul 2014 15:54:31 -0400, Tom Lane wrote in
<10710.1405626...@sss.pgh.pa.us>
> Peter Geoghegan writes:
> > On Thu, Jul 17, 2014 at 7:47 AM, Alvaro Herrera
> > wrote:
> >> I don't understand the point of having these GIN_EXCLUSIVE / GIN_SHARED
> >> symbols. It's not like we co
Peter Geoghegan writes:
> On Thu, Jul 17, 2014 at 7:47 AM, Alvaro Herrera
> wrote:
>> I don't understand the point of having these GIN_EXCLUSIVE / GIN_SHARED
>> symbols. It's not like we could do anything different than
>> BUFFER_LOCK_EXCLUSIVE etc instead. It there was a GinLockBuffer() it
>>
On Thu, Jul 17, 2014 at 7:47 AM, Alvaro Herrera
wrote:
> I don't understand the point of having these GIN_EXCLUSIVE / GIN_SHARED
> symbols. It's not like we could do anything different than
> BUFFER_LOCK_EXCLUSIVE etc instead. It there was a GinLockBuffer() it
> might make more sense to have spe
Kyotaro HORIGUCHI wrote:
> Hello,
>
> As far as I see gin seems using GIN_EXCLUSIVE instead of
> BUFFER_LOCK_EXCLUSIVE for LockBuffer, but the raw
> BUFFER_LOCK_EXCLUSIVE appears in ginbuildempty().
>
> Does it has a meaning to fix them to GIN_EXCLUSIVE?
I don't understand the point of having th
Hello,
As far as I see gin seems using GIN_EXCLUSIVE instead of
BUFFER_LOCK_EXCLUSIVE for LockBuffer, but the raw
BUFFER_LOCK_EXCLUSIVE appears in ginbuildempty().
Does it has a meaning to fix them to GIN_EXCLUSIVE?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src