Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded
От | Kyotaro Horiguchi |
---|---|
Тема | Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded |
Дата | |
Msg-id | 20240222.160027.62383325429446607.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | pgsql-bugs |
At Thu, 22 Feb 2024 14:38:15 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > At Thu, 22 Feb 2024 11:49:29 +0800, Tender Wang <tndrwang@gmail.com> wrote in > > Changing the behavior of tuplestore can work for this issue, but I'm not > > sure if this change will affect other components which depend on > > BufFile(like nodeMaterial) In the case of nodeMaterial, tuplestore is simply discarded and underlying files are removed without flushing by the resource owner mechanism. On the other hand, in the case of this bug report, the files in the problem tuplestore are not managed by a resource owner. As a result, PortalDrop have to explicitly call tuplestore_end to release resources used by the tuplestore. > /* > * Delete tuplestore if present. We should do this even under error > * conditions; since the tuplestore would have been using cross- > * transaction storage, its temp files need to be explicitly deleted. > */ > if (portal->holdStore) > { > MemoryContext oldcontext; > > oldcontext = MemoryContextSwitchTo(portal->holdContext); > tuplestore_end(portal->holdStore); As far as I can see, there are no caller sites to tuplestore_end in the abort path or any error handling path. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-bugs по дате отправления: