From: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(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 <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: error context for vacuum to include block number |
Date: | 2020-03-29 03:33:57 |
Message-ID: | CA+fd4k7Tmvh+6dbOjGrUjUiz-HCeqc0Lw9uA0Qor0zZoaqPGFA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 28 Mar 2020 at 13:23, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Sat, Mar 28, 2020 at 7:04 AM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> >
> > 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(at)telsasoft(dot)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.
> >
>
> Please find attached the updated patch with all the changes discussed.
> Let me know if I have missed anything?
>
Thank you for updating the patch! Looks good to me.
Regards,
--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2020-03-29 03:35:22 | Re: Improving connection scalability: GetSnapshotData() |
Previous Message | James Coleman | 2020-03-29 03:23:32 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |