From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | addRangeTableEntry() relies on pstate, contrary to its documentation |
Date: | 2015-01-04 17:18:31 |
Message-ID: | 20150104171831.GA3370@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Since at least 61e532820824504aa92ad93c427722d3fa9c1632 from 2009,
addRangeTableEntry() relies pstate being != NULL via its call to
isLockedRefname() even though its documentation says:
* If pstate is NULL, we just build an RTE and return it without adding it
* to an rtable list.
I think we should just remove the above sentence and code supporting it
from addRangeTableEntry* and add asserts ensuring its passed in.
Off list Tom commented that suggestion with:
> NAK. I'm absolutely certain that there is, or at least once was, code
> that relied on that feature. Maybe not for addRangeTableEntry itself,
> but for at least one of its siblings.
Yea, there had to be, for the code to be written that way. I'm not
exactly an expert in that area of the code, and lots of it predates my
involvement in the project...
> Before removing the feature I'd
> want to see a trace-down of where that usage went away and an analysis
> of why the need for it won't come back.
Ok. I've only cursorily checked callers. The number of callchains to all
of them make it hard to verify it conclusively :(
> An easy alternative fix, of course, is to not call isLockedRefname if
> we don't have a pstate (or else put the pstate==NULL test inside it).
I'm not a big fan of that - won't that essentially cause the wrong
locklevel to be used and thus open the door for lock upgrade deadlocks?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2015-01-04 17:20:09 | event trigger test exception message |
Previous Message | Peter Geoghegan | 2015-01-04 08:14:19 | Re: Problems with approach #2 to value locking (INSERT ... ON CONFLICT UPDATE/IGNORE patch) |