On Mon, Nov 14, 2016 at 10:23 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sat, Nov 12, 2016 at 10:28 AM, Andres Freund <and...@anarazel.de> wrote: >>> On 2016-08-30 07:38:10 -0400, Tom Lane wrote: >>>> I think this is probably wrong, or at least very dangerous to remove. >>>> The reason for the feature is that the slot may continue to point at >>>> the tuple after the scan has moved on. > >>> FWIW, that's not safe to assume in upper layers *anyway*. If you want to >>> do that, the slot has to be materialized, and that'd make a local >>> copy. If you don't materialize tts_values/isnull can point into random >>> old memory (common e.g. for projections and virtual tuples in general). > >> So, I think you are arguing in favor of proceeding with this patch? > > I don't believe Andres' claim anyway. There are certainly cases where an > allegedly-valid slot could be pointing at garbage, but table scans aren't > one of them, precisely because of the pin held by the slot. It would take > a fairly wide-ranging code review to convince me that it's okay to lose > that mechanism.
I don't understand your objection. It seems to me that the TupleTableSlot is holding a pin, and the scan is also holding a pin, so one of them is redundant. You speculated that the slot could continue to point at the tuple after the scan has moved on, but how could such a thing actually happen? Once the scan finds a tuple, it's going to store the tuple in the slot and return. It won't get control back to advance the scan until the next time it's asked for a tuple, and then it has to update the slot before returning. So I don't see the problem. If in the future somebody wants to write an executor node that does random extra work - like advancing the scan - before returning the tuple the scan already found, they'll have to take special precautions, but why should anybody want to do that? I'm kind of puzzled, here. Perhaps I am missing something obvious. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
