Re: error context for vacuum to include block number
Justin Pryzby <pryzby@telsasoft.com>
From: Justin Pryzby <pryzby@telsasoft.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-03-25T05:08:19Z
Lists: pgsql-hackers
On Wed, Mar 25, 2020 at 10:22:21AM +0530, Amit Kapila wrote:
> On Wed, Mar 25, 2020 at 10:05 AM Masahiko Sawada
> <masahiko.sawada@2ndquadrant.com> wrote:
> >
> > On Wed, 25 Mar 2020 at 12:44, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Tue, Mar 24, 2020 at 7:51 PM Masahiko Sawada
> > > <masahiko.sawada@2ndquadrant.com> wrote:
> > > >
> > > >
> > > > I got the point. But if we set the error context before that, I think
> > > > we need to change the error context message. The error context message
> > > > of heap truncation phase is "while truncating relation \"%s.%s\" to %u
> > > > blocks", but cbarg->blkno will be the number of blocks of the current
> > > > relation.
> > > >
> > > > case VACUUM_ERRCB_PHASE_TRUNCATE:
> > > > if (BlockNumberIsValid(cbarg->blkno))
> > > > errcontext("while truncating relation \"%s.%s\" to %u blocks",
> > > > cbarg->relnamespace, cbarg->relname, cbarg->blkno);
> > > > break;
> > > >
> > >
> > > Do you mean to say that actually we are just prefetching or reading
> > > the pages in count_nondeletable_pages() but the message doesn't have
> > > any such indication? If not that, what problem do you see with the
> > > message? What is your suggestion?
> >
> > I meant that with the patch, suppose that the table has 100 blocks and
> > we're truncating it to 50 blocks in RelationTruncate(), the error
> > context message will be "while truncating relation "aaa.bbb" to 100
> > blocks", which is not correct. I think it should be "while truncating
> > relation "aaa.bbb" to 50 blocks". We can know the relation can be
> > truncated to 50 blocks by the result of count_nondeletable_pages(). So
> > if we update the arguments before it we will use the number of blocks
> > of relation before truncation.
> >
>
> Won't the latest patch by Justin will fix this as he has updated the
> block count after count_nondeletable_pages? Apart from that, I feel
The issue is if the error happens *during* count_nondeletable_pages().
We don't want it to say "truncating relation to 100 blocks".
> the first call to update_vacuum_error_cbarg in lazy_truncate_heap
> should have input parameter as vacrelstats->nonempty_pages instead of
> new_rel_pages to indicate the remaining pages after truncation?
Yea, I think that addresses the issue.
--
Justin
Commits
-
Avoid calls to RelationGetRelationName() and RelationGetNamespace() in
- ef75140fe756 13.0 landed
-
Introduce vacuum errcontext to display additional information.
- b61d161c1463 13.0 landed
-
Fix mesurement of elapsed time during truncating heap in VACUUM.
- 007491979461 13.0 cited
-
Allow vacuum command to process indexes in parallel.
- 40d964ec997f 13.0 cited
-
Refactor code dedicated to index vacuuming in vacuumlazy.c
- 1ab41a3c8edc 13.0 landed
-
Remove duplicated progress reporting during heap scan of VACUUM
- e5a02e0fc68b 13.0 landed