Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: tndrwang(at)gmail(dot)com
Cc: exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded
Date: 2024-02-22 05:38:15
Message-ID: 20240222.143815.1856873109774774353.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

At Thu, 22 Feb 2024 11:49:29 +0800, Tender Wang <tndrwang(at)gmail(dot)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)

Right. Regarding this type of error, the best we can do is to be
careful not to cause exceptions (elog/ereport(>=ERROR)) within the
abort code path. This is somewhat similar to the case of the
interaction between malloc() and signal handler.

First I tried to skip flushing in BufFileClose based on transaction
state and isInterXact state. However, that didn't seem that simple. We
could provide some flag to signal we're in the state where we cannot
error out, which BufFileClose refers to. That in turn can cause other
issues.

I mentioned that I haven't checked for the similar potential issues
BufFileClose can cause, but if nodeMaterial is that, the new function
could be usable for that.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kyotaro Horiguchi 2024-02-22 07:00:27 Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded
Previous Message PG Bug reporting form 2024-02-22 05:25:39 BUG #18358: I am not able to change the existing SQL connection to Postgres connection in existing application