Re: subplan resets wrong hashtable

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: subplan resets wrong hashtable
Date: 2020-02-10 22:08:31
Message-ID: 30426.1581372511@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> On Sun, Feb 09, 2020 at 08:01:26PM -0800, Andres Freund wrote:
>> Ugh, that indeed looks wrong. Did you check whether it can actively
>> cause wrong query results? If so, did you do theoretically, or got to a
>> query returning wrong results?

> Actually .. I can "theoretically" prove that there's no wrong results from that
> patch...since in that file it has no effect, the tested variables being zeroed
> few lines earlier:

Right. So the incorrect ResetTupleHashTable call is unreachable
(and a look at the code coverage report confirms that). The whole
thing obviously is a bit hasty and unreviewed, but it doesn't have
a live bug AFAICS ... or at least, if there's a bug, it's a memory
leakage issue across repeat executions, not a crash hazard. I'm
not too clear on whether the context reset just above those pointer
assignments will get rid of all traces of the old hash tables,
but it sort of looks like it might not anymore.

Anyway, not going to hold up the releases for a fix for this.
We've lived with it for a year, so it can wait another quarter.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Quan Zongliang 2020-02-10 23:38:48 Re: Restore replication settings when modifying a field type
Previous Message Andres Freund 2020-02-10 21:46:04 Re: pgsql: walreceiver uses a temporary replication slot by default