Re: Pinning a buffer in TupleTableSlot is unnecessary

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Pinning a buffer in TupleTableSlot is unnecessary
Дата
Msg-id 20161114175628.dyeihhmmm46yde7l@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Pinning a buffer in TupleTableSlot is unnecessary  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Pinning a buffer in TupleTableSlot is unnecessary
Список pgsql-hackers
On 2016-11-14 12:32:53 -0500, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
> > On 11/14/2016 06:18 PM, Tom Lane wrote:
> >> You're implicitly assuming that a scan always returns its results in the
> >> same slot, and that no other slot could contain a copy of that data, but
> >> there is no guarantee of either.  See bug #14344 and d8589946d for a
> >> pretty recent example where that failed to be true --- admittedly, for
> >> a tuplesort scan not a table scan.
> 
> > It's the other way round. ExecProcNode might not always return its 
> > result in the same slot, but all the callers must assume that it might.
> 
> Basically my concern is that this restriction isn't documented anywhere
> and I'm not entirely certain it's been adhered to everywhere.  I'd feel
> much better about it if there were some way we could verify that.

Would support for valgrind complaining about access to unpinned buffers
suffice?

Andres



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Pinning a buffer in TupleTableSlot is unnecessary
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Pinning a buffer in TupleTableSlot is unnecessary