Re: [BUG] plpgsql RETURN QUERY with toasted fields -vs- DROP/TRUNCATE

Поиск
Список
Период
Сортировка
От Jehan-Guillaume de Rorthais
Тема Re: [BUG] plpgsql RETURN QUERY with toasted fields -vs- DROP/TRUNCATE
Дата
Msg-id 20200904170213.12547fb8@firost
обсуждение исходный текст
Ответ на Re: [BUG] plpgsql RETURN QUERY with toasted fields -vs- DROP/TRUNCATE  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Sat, 29 Aug 2020 13:47:19 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Jehan-Guillaume de Rorthais <jgdr@dalibo.com> writes:
> > We discovered a bug in plpgsql.
> > When using RETURN QUERY on a relation with some toasted values and when this
> > relaiton is later dropped or truncated, an error is raised at the end of the
> > function.  
> 
> This isn't particularly RETURN QUERY's fault; there are any number of ways
> to produce the same sort of error.  I reproduced it with
> [...]

Indeed. Thanks.

> I guess we could forcibly detoast values in enough places to close all the
> gaps, but the performance costs might be annoying.  I think a case can
> definitely be made for saying "don't do that".

What do you mean? Writing in configuration to not drop a relation in a function
where some past computed results depend on it?

> (Another idea, perhaps, might be to detoast only in volatile functions,
> reasoning that a nonvolatile one can't drop the table.)

Would it be possible to detoast values iif the related relation are dropped
later?

Regards,



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

Предыдущее
От: Jehan-Guillaume de Rorthais
Дата:
Сообщение: Re: [BUG v13] Crash with event trigger in extension
Следующее
От: Jehan-Guillaume de Rorthais
Дата:
Сообщение: Re: BUG #15285: Query used index over field with ICU collation in some cases wrongly return 0 rows