On 2019-Feb-07, Tom Lane wrote:
> Alvaro Herrera writes:
> > So,
>
> > "The error recovery code can either do PG_RE_THROW to propagate the
> > error outwards, or do a (sub)transaction abort. Failure to do so may
> > leave the system in an inconsistent state for further processing."
>
> WFM.
T
Alvaro Herrera writes:
> So,
> "The error recovery code can either do PG_RE_THROW to propagate the
> error outwards, or do a (sub)transaction abort. Failure to do so may
> leave the system in an inconsistent state for further processing."
WFM.
regards, tom lane
> On 2019-02-06 13:09:59 -0300, Alvaro Herrera wrote:
> > This is obviously wrong; while we have a couple of codesites that omit
> > it, it's not a generally available coding pattern. I think we should
> > amend that comment. I propose: "The error recovery code must normally
> > do PG_RE_THROW()
Alvaro Herrera writes:
> elog.h claims that PG_RE_THROW is "optional":
> * (The braces are not actually necessary, but are recommended so that
> * pgindent will indent the construct nicely.) The error recovery code
> * can optionally do PG_RE_THROW() to propagate the same error outwards.
> T
On 2019-02-06 13:09:59 -0300, Alvaro Herrera wrote:
> In https://postgr.es/m/1676.1548726...@sss.pgh.pa.us Tom Lane wrote:
>
> > Sure: every errcode we have is unsafe to treat this way.
> >
> > The backend coding rule from day one has been that a thrown error requires
> > (sub)transaction cleanup
In https://postgr.es/m/1676.1548726...@sss.pgh.pa.us Tom Lane wrote:
> Sure: every errcode we have is unsafe to treat this way.
>
> The backend coding rule from day one has been that a thrown error requires
> (sub)transaction cleanup to be done to make sure that things are back in a
> good state.
