|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||"Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>|
|Cc:||"'jesper(dot)pedersen(at)redhat(dot)com'" <jesper(dot)pedersen(at)redhat(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "fabriziomello(at)gmail(dot)com" <fabriziomello(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>|
|Subject:||Re: pg_upgrade: Pass -j down to vacuumdb|
|Views:||Raw Message | Whole Thread | Download mbox|
On Tue, Jan 29, 2019 at 12:35:30AM +0000, Jamison, Kirk wrote:
> I just checked the patch.
> As per advice, you removed the versioning and specified --jobs.
> The patch still applies, builds and passed the tests successfully.
I would document the optional VACUUM_OPTS on the page of pg_upgrade.
If Peter thinks it is fine to not do so, that's fine for me as well.
It seems to me that the latest patch sent is incorrect for multiple
1) You still enforce -j to use the number of jobs that the caller of
pg_upgrade provides, and we agreed that both things are separate
concepts upthread, no? What has been suggested by Alvaro is to add a
comment so as one can use VACUUM_OPTS with -j optionally, instead of
suggesting a full-fledged vacuumdb command which depends on what
pg_upgrade uses. So there is no actual need for the if/else
2) Perhaps we need to worry about the second vacuumdb --all command,
which may want custom options, which are not necessarily the same as
the options of the first command? I don't think we need to care as it
applies only to an upgraded cluster using something older 8.4, just
|Next Message||Michael Paquier||2019-01-29 05:14:03||Re: Built-in connection pooler|
|Previous Message||Michael Paquier||2019-01-29 04:51:58||Re: Early WIP/PoC for inlining CTEs|