On Thu, May 09, 2024 at 05:19:47PM +1200, Thomas Munro wrote:
> On Thu, Dec 28, 2023 at 11:42 AM Tom Lane wrote:
> > Thomas Munro writes:
> > > In CommitTransaction() there is a stretch of code beginning s->state =
> > > TRANS_COMMIT and ending s->state = TRANS_DEFAULT, from which we call
> > > o
On Thu, Dec 28, 2023 at 11:42 AM Tom Lane wrote:
> Thomas Munro writes:
> > In CommitTransaction() there is a stretch of code beginning s->state =
> > TRANS_COMMIT and ending s->state = TRANS_DEFAULT, from which we call
> > out to various subsystems' AtEOXact_XXX() functions. There is no way
> >
ft >STATEMENT: commit
> < 2023-12-25 04:06:20.062 MST telsasoft >WARNING: AbortTransaction while in
> COMMIT state
> < 2023-12-25 04:06:20.062 MST telsasoft >PANIC: cannot abort transaction
> 2737414167, it was already committed
> < 2023-12-25 04:06:20.473 M
On Thu, Dec 28, 2023 at 11:33:16AM +1300, Thomas Munro wrote:
> I guess the large object usage isn't directly relevant (that module's
> EOXact stuff seems to be finished before TRANS_COMMIT, but I don't
> know that code well). Everything later is supposed to be about
> closing/releasing/cleaning u
Thomas Munro writes:
> In CommitTransaction() there is a stretch of code beginning s->state =
> TRANS_COMMIT and ending s->state = TRANS_DEFAULT, from which we call
> out to various subsystems' AtEOXact_XXX() functions. There is no way
> to roll back in that state, so anything that throws ERROR f
On Thu, Dec 28, 2023 at 4:02 AM Justin Pryzby wrote:
> My main question is why an IO error would cause the DB to abort, rather
> than raising an ERROR.
In CommitTransaction() there is a stretch of code beginning s->state =
TRANS_COMMIT and ending s->state = TRANS_DEFAULT, from which we call
out t
Transaction while in
COMMIT state
< 2023-12-25 04:06:20.062 MST telsasoft >PANIC: cannot abort transaction
2737414167, it was already committed
< 2023-12-25 04:06:20.473 MST >LOG: server process (PID 14678) was terminated
by signal 6: Aborted
The application is a daily cronjob whi
