Andres Freund <and...@anarazel.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
