On Tue, Jun 04, 2019 at 04:18:30PM -0400, Alvaro Herrera wrote:
> Yeah, I was not quite understanding why it was being blamed on a commit
> that actually *removed* one other callsite that did the same thing. (I
> didn't actually realize at the time that this bug was there, mind.)
I completely
On 2019-May-23, Mark Dilger wrote:
> On Thu, May 23, 2019 at 5:24 PM Michael Paquier wrote:
> > Looking closer, this code is not new as of v12. We have that since
> > e7b3349 which has introduced CREATE TABLE OF.
Yeah, I was not quite understanding why it was being blamed on a commit
that
On Thu, May 23, 2019 at 5:24 PM Michael Paquier wrote:
>
> On Thu, May 23, 2019 at 08:27:19AM -0700, Mark Dilger wrote:
> > On Thu, May 23, 2019 at 7:54 AM Tom Lane wrote:
> >> Are we sure that's not just a newly-introduced bug, ie it has not
> >> been tested in cases where the tlist could
On Thu, May 23, 2019 at 08:27:19AM -0700, Mark Dilger wrote:
> On Thu, May 23, 2019 at 7:54 AM Tom Lane wrote:
>> Are we sure that's not just a newly-introduced bug, ie it has not
>> been tested in cases where the tlist could become empty? My first
>> thought would be to assign the list pointer
On Thu, May 23, 2019 at 7:54 AM Tom Lane wrote:
>
> Michael Paquier writes:
> > On Wed, May 22, 2019 at 06:20:01PM -0700, Mark Dilger wrote:
> >> What to do about this is harder to say. In the following
> >> patch, I'm just doing what I think is standard for callers
> >> of list_delete_cell,
Michael Paquier writes:
> On Wed, May 22, 2019 at 06:20:01PM -0700, Mark Dilger wrote:
>> What to do about this is harder to say. In the following
>> patch, I'm just doing what I think is standard for callers
>> of list_delete_cell, and assigning the return value back
>> to the list (similar to
On Wed, May 22, 2019 at 10:21 PM Michael Paquier wrote:
>
> On Wed, May 22, 2019 at 06:20:01PM -0700, Mark Dilger wrote:
> > What to do about this is harder to say. In the following
> > patch, I'm just doing what I think is standard for callers
> > of list_delete_cell, and assigning the return
On Wed, May 22, 2019 at 06:20:01PM -0700, Mark Dilger wrote:
> What to do about this is harder to say. In the following
> patch, I'm just doing what I think is standard for callers
> of list_delete_cell, and assigning the return value back
> to the list (similar to how a call to repalloc should
Hackers,
I have been auditing the v12 source code for places
which inappropriately ignore the return value of a function
and have found another example which seems to me
a fertile source of future bugs.
In src/backend/nodes/list.c, list_delete_cell frees the list
and returns NIL when you delete
