Re: Handle concurrent drop when doing whole database vacuum - Mailing list pgsql-hackers

From cca5507
Subject Re: Handle concurrent drop when doing whole database vacuum
Date
Msg-id tencent_8F84EE14BED66AA768C854E0E11E14D8850A@qq.com
Whole thread
In response to Re: Handle concurrent drop when doing whole database vacuum  (surya poondla <suryapoondla4@gmail.com>)
List pgsql-hackers
Hi Surya,

Thanks for the comments!

> A couple of points on the patch itself:
> 1. The bug is racy but the injection_points framework (src/test/modules/injection_points) can make it deterministic.
> We can put an INJECTION_POINT() inside the heap_getnext() loop in get_all_vacuum_rels() and adding an isolation spec
thatparks 
> VACUUM there, runs DROP TABLE in another session, then resumes VACUUM and asserts it completes with a WARNING.
>
> 2. Minor comment vacuum_open_relation() already emits an identically-worded
> "relation no longer exists" message with errcode(ERRCODE_UNDEFINED_TABLE).
> Worth adding the same errcode to the two new ereports so the SQLSTATE stays consistent for the same logical event.

Fixed. Please see the v2 patches.

--
Regards,
ChangAo Chen

Attachment

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Unexpected behavior after OOM errors
Next
From: Ashutosh Sharma
Date:
Subject: Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication