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
> >
On Wed, Dec 27, 2023 at 09:02:25AM -0600, Justin Pryzby wrote:
> We had this:
>
> < 2023-12-25 04:06:20.062 MST telsasoft >ERROR: could not open file
> "pg_tblspc/16395/PG_16_202307071/16384/121010871": Input/output error
> < 2023-12-25 04:06:20.062 MST telsasoft >STATEMENT: commit
> < 2023-12-
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
