Date: Thu, 22 Feb 2024 14:38:15 +0900 (JST)
Message-Id: <20240222.143815.1856873109774774353.horikyota.ntt@gmail.com>
To: tndrwang@gmail.com
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18354: Aborted transaction aborted during cleanup when
 temp_file_limit exceeded
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
In-Reply-To: <CAHewXN=ZEL1Rvw2fJmt8k3sO_3fb58gijv7GR-JnY8ujgGP0UA@mail.gmail.com>
References: <18354-140864c09686b5a6@postgresql.org>
	<20240222.114600.1019580904613326727.horikyota.ntt@gmail.com>
	<CAHewXN=ZEL1Rvw2fJmt8k3sO_3fb58gijv7GR-JnY8ujgGP0UA@mail.gmail.com>
User-Agent: Mew version 6.8 on Emacs 27.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/20240222.143815.1856873109774774353.horikyota.ntt%40gmail.com>
Precedence: bulk

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)

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