| From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
|---|---|
| To: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM |
| Date: | 2020-07-13 18:01:28 |
| Message-ID: | 20200713180128.GJ23581@telsasoft.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, May 31, 2020 at 10:13:39PM +0000, Bossart, Nathan wrote:
> Here is a rebased version of the patch.
Should bin/vacuumdb support this?
Should vacuumdb have a way to pass an arbitrary option to the server, instead
of tacking on options (which are frequently forgotten on the initial commit to
the backend VACUUM command) ? That has the advantage that vacuumdb could use
new options even when connecting to a new server version than client. I think
it would be safe as long as it avoided characters like ')' and ';'. Maybe
all that's needed is isdigit() || isalpha() || isspace() || c=='_'
+ MAIN_RELATION_CLEANUP [ <replaceable class="parameter">boolean</replaceable> ]
+ TOAST_TABLE_CLEANUP [ <replaceable class="parameter">boolean</replaceable> ]
Maybe should be called TOAST_RELATION_CLEANUP
See attached.
--
Justin
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Add-MAIN_RELATION_CLEANUP-and-SECONDARY_RELATION_CLE.patch | text/x-diff | 13.3 KB |
| 0002-vacuumdb-support.patch | text/x-diff | 3.6 KB |
| 0003-Full-can-be-specified-just-not-enabled.patch | text/x-diff | 911 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2020-07-13 18:29:14 | Re: pg_dump bug for extension owned tables |
| Previous Message | Justin Pryzby | 2020-07-13 17:59:57 | Re: proposal: possibility to read dumped table's name from file |