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
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 |