Re: error context for vacuum to include block number

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: error context for vacuum to include block number
Date: 2020-03-27 19:04:29
Message-ID: 20200327190428.GS20103@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 27, 2020 at 11:50:30AM +0530, Amit Kapila wrote:
> > > The crash scenario I'm trying to avoid would be like statement_timeout or other
> > > asynchronous event occurring between two non-atomic operations.
> > >
> > +if (errinfo->phase==VACUUM_ERRCB_PHASE_VACUUM_INDEX && errinfo->indname==NULL)
> > +{
> > +kill(getpid(), SIGINT);
> > +pg_sleep(1); // that's needed since signals are delivered asynchronously
> > +}
> > I'm not sure if those are possible outside of "induced" errors. Maybe the
> > function is essentially atomic due to no CHECK_FOR_INTERRUPTS or similar?
>
> Yes, this is exactly the point. I think unless you have
> CHECK_FOR_INTERRUPTS in that function, the problems you are trying to
> think won't happen.

Hm, but I caused a crash *without* adding CHECK_FOR_INTERRUPTS, just
kill+sleep. The kill() could come from running pg_cancel_backend(). And the
sleep() just encourages a context switch, which can happen at any time. I'm
not convinced that the function couldn't be interrupted by a signal.

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergei Kornilov 2020-03-27 19:15:50 Re: Improve handling of parameter differences in physical replication
Previous Message Tom Lane 2020-03-27 18:59:56 Re: Reinitialize stack base after fork (for the benefit of rr)?