From: Justin Pryzby <pryzby@telsasoft.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: error context for vacuum to include block number
Date: Fri, 27 Mar 2020 20:34:34 -0500
Message-ID: <20200328013434.GZ20103@telsasoft.com> (raw)
In-Reply-To: <CAA4eK1KVMvdBqOp2w2Z-WPkY7dbbsGdnPnQwN9UmJ8qeiovGgg@mail.gmail.com>
References: <20200326150457.GB17431@telsasoft.com>
<20200326221752.GR17431@telsasoft.com>
<CAA4eK1+b5-aJcbpvqCFB7Qi0zLKTZNJmA+Js644M2YeiEyTZtw@mail.gmail.com>
<20200327044424.GD20103@telsasoft.com>
<20200327061601.GE20103@telsasoft.com>
<CAA4eK1LKYnDV8bcx59TdR5-s2Cfk75g_wfAjRyy-cL8S+WvHXw@mail.gmail.com>
<20200327190428.GS20103@telsasoft.com>
<CAA4eK1LuHowu1Gm++_miME9RSL0OiuqMpK_K-L0SqDaxJEKMcg@mail.gmail.com>
<20200328011632.GY20103@telsasoft.com>
<CAA4eK1KVMvdBqOp2w2Z-WPkY7dbbsGdnPnQwN9UmJ8qeiovGgg@mail.gmail.com>
On Sat, Mar 28, 2020 at 06:59:10AM +0530, Amit Kapila wrote:
> On Sat, Mar 28, 2020 at 6:46 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> >
> > On Sat, Mar 28, 2020 at 06:28:38AM +0530, Amit Kapila wrote:
> > > > 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.
> > >
> > > pg_sleep internally uses CHECK_FOR_INTERRUPTS() due to which it would
> > > have accepted the signal sent via pg_cancel_backend(). Can you try
> > > your scenario by temporarily removing CHECK_FOR_INTERRUPTS from
> > > pg_sleep() or maybe better by using OS Sleep call?
> >
> > Ah, that explains it. Right, I'm not able to induce a crash with usleep().
> >
> > Do you want me to resend a patch without that change ? I feel like continuing
> > to trade patches is more likely to introduce new errors or lose someone else's
> > changes than to make much progress. The patch has been through enough
> > iterations and it's very easy to miss an issue if I try to eyeball it.
>
> I can do it but we have to agree on the other two points (a) I still
> feel that switching to the truncate phase should be done at the place
> from where we are calling lazy_truncate_heap and (b)
> lazy_cleanup_index should switch back the error phase after calling
> index_vacuum_cleanup. I have explained my reasoning for these points
> a few emails back.
I have no objection to either. It was intuitive to me to do it how I
originally wrote it but I'm not wedded to it.
--
Justin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com, amit.kapila16@gmail.com, masahiko.sawada@2ndquadrant.com, alvherre@2ndquadrant.com, andres@anarazel.de, michael@paquier.xyz
Subject: Re: error context for vacuum to include block number
In-Reply-To: <20200328013434.GZ20103@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox