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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.
Date: 2016-04-12 15:52:01
Message-ID: 3736.1460476321@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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 that must be evaluated at runtime.

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 the address in
s_lock_stuck. This would be different from what we do now, but not
necessarily any less useful. I'm pretty dubious of the usefulness of
the addresses you're printing right now, because most of them are indeed
not the spinlock itself.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Kevin Grittner 2016-04-12 16:49:25 pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Previous Message Tom Lane 2016-04-12 15:42:12 pgsql: Improve API of GenericXLogRegister().

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2016-04-12 15:53:51 Re: Some other things about contrib/bloom and generic_xlog.c
Previous Message Tom Lane 2016-04-12 15:42:46 Re: Some other things about contrib/bloom and generic_xlog.c