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-13 18:16:15 |
Message-ID: | 16708.1460571375@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> 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 the address in
>> s_lock_stuck. This would be different from what we do now, but not
>> necessarily any less useful.
> I'm not sure anybody really benefits from those addresses; I guess the
> idea was that they'd allow you to figure out which exact spinlock got
> stuck; file + line doesn't necessarily help there. But it doesn't seem
> super useful, ASLR makes the addesses unpredictable, so you need a core
> file anyway - in which case you can just walk the stack.
True.
> So I think I'm on board with replacing the argument; although I'm
> wondering if we shouldn't just remove it entirely, rather than replacing
> it with a string that's likely just going to duplicate the file/line
> information.
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). The line number is often hard
to decipher if you're not sure exactly what PG version you're dealing
with, so I think having the function name would be a sufficient advance
to rebut any claim that we'd gone backwards.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-04-13 18:20:19 | Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner. |
Previous Message | Andres Freund | 2016-04-13 18:04:14 | Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner. |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-04-13 18:20:19 | Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner. |
Previous Message | Robert Haas | 2016-04-13 18:11:54 | Re: Odd system-column handling in postgres_fdw join pushdown patch |