Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner. - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.
Date
Msg-id 20160414063121.d6neaimawvffo3mh@alap3.anarazel.de
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 2016-04-13 20:09:46 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2016-04-13 11:20:19 -0700, Andres Freund wrote:
> >> Heh, I was wondering the same aftering sending the last email.  Will do
> >> that then.
> 
> > Pushed. Let's see what pademelon says...
> 
> I lit off a run, but it'll be a few hours till we have results...

In hindsight obviously, this isn't sufficient because s_lock reports the
caller's file/line/function, not __FILE__ etc. So I guess we're left
moving initialization to an inline function - will do so tomorrow.

I'm also putting up an animal with clang that uses
CFLAGS='-std=c89 -Wc99-extensions -Werror=c99-extensions'
which actually catches this.

I'd previously tested with gcc and "-Wc90-c99-compat -Werror=c90-c99-compat
-Wno-long-long -Wno-error=long-long -std=c90", but that doesn't catch
that error.

(both find a couple trailing commas in enums, will fix)


- Andres



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Postgres_fdw join pushdown - INNER - FULL OUTER join combination generating wrong result
Next
From: Amit Langote
Date:
Subject: Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan.