Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-14 22:46:01 -0400, Tom Lane wrote: > > Hm. Doing so I found the following in 9.3: > > > /home/andres/src/postgresql-9.3/src/bin/pg_dump/parallel.c:561:23: error: > > initializer for aggregate is not a compile-time constant > > [-Werror,-Wc99-extensions] > > int

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

Andres Freund writes: > On 2016-04-13 23:31:21 -0700, Andres Freund wrote: >> I'm also putting up an animal with clang that uses >> CFLAGS='-std=c89 -Wc99-extensions -Werror=c99-extensions' >> which actually catches this. > Hm. Doing so I found the following in 9.3: >

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-13 23:31:21 -0700, Andres Freund wrote: > I'm also putting up an animal with clang that uses > CFLAGS='-std=c89 -Wc99-extensions -Werror=c99-extensions' > which actually catches this. Hm. Doing so I found the following in 9.3:

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-13 20:09:46 -0400, Tom Lane wrote: > Andres Freund 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

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

Andres Freund 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...

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-13 11:20:19 -0700, Andres Freund wrote: > On 2016-04-13 14:16:15 -0400, Tom Lane wrote: > > Good point, it would be absolutely duplicative. What I'd suggest, > > actually, is that we convert this to the same info as what elog > > provides (file+line+function name). > > Heh, I was

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-13 14:16:15 -0400, Tom Lane wrote: > Good point, it would be absolutely duplicative. What I'd suggest, > actually, is that we convert this to the same info as what elog > provides (file+line+function name). Heh, I was wondering the same aftering sending the last email. Will do that

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

Andres Freund writes: > On 2016-04-12 11:52:01 -0400, Tom Lane wrote: >> It strikes me that that means you could stick with this initialization >> method if you made the macro argument be a literal constant string name, >> like "buffer spinlock", and printed that rather than

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-12 11:52:01 -0400, Tom Lane wrote: > I wrote: > > It looks like that compiler adheres to the C89 restriction that an > > initializer for an array or struct must contain only link-time-constant > > expressions, even if the target object is of dynamic scope. > > The macro works with a

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-12 07:00, Andres Freund wrote: On 2016-04-12 00:32:13 -0400, Tom Lane wrote: I wrote: This commit has broken buildfarm member gaur, and no doubt pademelon will be equally unhappy once it catches up to HEAD. Spoke too soon, actually: pademelon did not get as far as initdb. cc:

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

I wrote: > It looks like that compiler adheres to the C89 restriction that an > initializer for an array or struct must contain only link-time-constant > expressions, even if the target object is of dynamic scope. > The macro works with a link-time-constant pointer argument, but not > with one

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

Andres Freund writes: > On 2016-04-12 00:32:13 -0400, Tom Lane wrote: >> Apparently, assigning the result of init_spin_delay() is not as portable >> as you thought. > Hm. I'm not sure why not though? Is it because delayStatus isn't static > or global scope? It looks like

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-12 00:32:13 -0400, Tom Lane wrote: > I wrote: > > This commit has broken buildfarm member gaur, and no doubt pademelon > > will be equally unhappy once it catches up to HEAD. > > Spoke too soon, actually: pademelon did not get as far as initdb. > > cc: "bufmgr.c", line 4032: error

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

I wrote: > This commit has broken buildfarm member gaur, and no doubt pademelon > will be equally unhappy once it catches up to HEAD. Spoke too soon, actually: pademelon did not get as far as initdb. cc: "bufmgr.c", line 4032: error 1521: Incorrect initialization. cc: "bufmgr.c", line 4058:

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

Andres Freund writes: > Allow Pin/UnpinBuffer to operate in a lockfree manner. This commit has broken buildfarm member gaur, and no doubt pademelon will be equally unhappy once it catches up to HEAD. The reason is that you've caused localbuf.c to perform a whole bunch of