> On 3 Mar 2021, at 09:57, Peter Eisentraut
> wrote:
> I committed this. I added a pg_strip_crlf() so that there are no newlines in
> the error message.
Right, that's much better, thanks!
--
Daniel Gustafsson https://vmware.com/
On 02.03.21 22:51, Daniel Gustafsson wrote:
The commit message says something about "to ensure the health of the target
cluster", which doesn't make sense to me. Maybe find a better wording.
Reworded in the attached updated version.
The name find_exec() seems not very accurate. It doesn't
> On 2 Mar 2021, at 14:20, Peter Eisentraut
> wrote:
>
> On 23.02.21 17:14, Daniel Gustafsson wrote:
>> This exports validate_exec to reduce duplication, and implements a custom
>> find_other_exec-like function in pg_upgrade to check each binary for the
>> version number. Keeping a local copy o
On 23.02.21 17:14, Daniel Gustafsson wrote:
This exports validate_exec to reduce duplication, and implements a custom
find_other_exec-like function in pg_upgrade to check each binary for the
version number. Keeping a local copy of validate_exec is easy to do if it's
deemed not worth it to export
> On 27 Jul 2019, at 08:42, Peter Eisentraut
> wrote:
>
> On 2019-07-25 16:33, Daniel Gustafsson wrote:
>> Fair enough, those are both excellent points. I’ve shuffled the code around
>> to
>> move back the check for exec_path to setup (albeit earlier than before due to
>> where we perform dire
> On 2 Sep 2019, at 19:59, Alvaro Herrera wrote:
>
> On 2019-Jul-30, Daniel Gustafsson wrote:
>
>> I’ll take a stab at tidying all of this up to require less duplication, we’ll
>> see where that ends up.
>
> Hello Daniel, are you submitting a new version soon?
I am working on an updated versio
On 2019-Jul-30, Daniel Gustafsson wrote:
> I’ll take a stab at tidying all of this up to require less duplication, we’ll
> see where that ends up.
Hello Daniel, are you submitting a new version soon?
Thanks,
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development,
On Wed, Jul 31, 2019 at 3:13 AM Daniel Gustafsson wrote:
> > On 27 Jul 2019, at 08:42, Peter Eisentraut
> > wrote:
> > I have committed 0002, 0003, and 0004.
>
> Thanks!
>
> > The implementation in 0001 (Only allow upgrades by the same exact
> > version new bindir) has a problem. It compares (n
> On 27 Jul 2019, at 08:42, Peter Eisentraut
> wrote:
> I have committed 0002, 0003, and 0004.
Thanks!
> The implementation in 0001 (Only allow upgrades by the same exact
> version new bindir) has a problem. It compares (new_cluster.bin_version
> != PG_VERSION_NUM), but new_cluster.bin_versio
On 2019-07-25 16:33, Daniel Gustafsson wrote:
> Fair enough, those are both excellent points. I’ve shuffled the code around
> to
> move back the check for exec_path to setup (albeit earlier than before due to
> where we perform directory checking). This does mean that the directory
> checking in
> On 24 Jul 2019, at 22:32, Peter Eisentraut
> wrote:
>
> On 2019-07-23 17:30, Daniel Gustafsson wrote:
>> The reason for moving is that we print default values in usage(), and that
>> requires the value to be computed before calling usage(). We already do this
>> for resolving environment valu
On 2019-07-23 17:30, Daniel Gustafsson wrote:
> The reason for moving is that we print default values in usage(), and that
> requires the value to be computed before calling usage(). We already do this
> for resolving environment values in parseCommandLine(). If we do it in setup,
> then we’d hav
> On 22 Jul 2019, at 10:46, Peter Eisentraut
> wrote:
>
> On 2019-04-04 15:40, Daniel Gustafsson wrote:
>> On Wednesday, March 27, 2019 1:43 PM, Christoph Berg wrote:
>>
>>> Re: Daniel Gustafsson 2019-03-26
>>> pC-NMmh4vQLQP76YTwY4AuoD4OdNw9egikekyQpXFpgqmTlGjIZXOTd2W5RDZPpRski5N3ADRrLYgLk6QU
On 2019-04-04 15:40, Daniel Gustafsson wrote:
> On Wednesday, March 27, 2019 1:43 PM, Christoph Berg wrote:
>
>> Re: Daniel Gustafsson 2019-03-26
>> pC-NMmh4vQLQP76YTwY4AuoD4OdNw9egikekyQpXFpgqmTlGjIZXOTd2W5RDZPpRski5N3ADRrLYgLk6QUuvmuT5fWC9acPAYyDU1AVxJcU=@yesql.se
>>
>>> 0003 - Make -B default
On Wednesday, March 27, 2019 1:43 PM, Christoph Berg wrote:
> Re: Daniel Gustafsson 2019-03-26
> pC-NMmh4vQLQP76YTwY4AuoD4OdNw9egikekyQpXFpgqmTlGjIZXOTd2W5RDZPpRski5N3ADRrLYgLk6QUuvmuT5fWC9acPAYyDU1AVxJcU=@yesql.se
>
> > 0003 - Make -B default to CWD and remove the exec_path check
> > Defaulting
Re: Daniel Gustafsson 2019-03-26
> 0003 - Make -B default to CWD and remove the exec_path check
>
> Defaulting to CWD for the new bindir has the side effect that the default
> sockdir is in the bin/ directory which may be less optimal.
Hmm, I would have thought that the default for the new bind
On Tuesday, March 19, 2019 12:35 AM, Tom Lane wrote:
> I noticed a few things that seem a bit fishy about pg_upgrade.
Attached are three patches which takes a stab at the issues raised here (and
the discussion in this thread):
0001 - Enforces the version check to the full version including the
Re: Peter Eisentraut 2019-03-22
<57769959-8960-a9ca-fc9c-4dbb12629...@2ndquadrant.com>
> I'm still in favor of defaulting --new-bindir appropriately. It seems
> silly not to. We know where the directory is, we don't have to ask anyone.
Fwiw I've been wondering why I have to pass that option eve
On 2019-03-19 16:51, Tom Lane wrote:
> I'm not really getting your point here. Packagers ordinarily tie
> those versions together anyway, I'd expect --- there's no upside
> to not doing so, and plenty of risk if one doesn't, because of
> exactly the sort of coordinated-changes hazard I'm talking a
Peter Eisentraut writes:
> On 2019-03-19 00:35, Tom Lane wrote:
>> 2. check_cluster_versions() insists that the target version be the
>> same major version as pg_upgrade itself, but is that really good enough?
>> As things stand, it looks like pg_upgrade 11.3 would happily use pg_dump
>> 11.1, or
On 2019-03-19 00:35, Tom Lane wrote:
> 2. check_cluster_versions() insists that the target version be the
> same major version as pg_upgrade itself, but is that really good enough?
> As things stand, it looks like pg_upgrade 11.3 would happily use pg_dump
> 11.1, or vice versa.
I'd hesitate to tie
On Tuesday, March 19, 2019 7:55 AM, Bruce Momjian wrote:
> On Tue, Mar 19, 2019 at 02:43:49AM -0400, Bruce Momjian wrote:
>
> > > 3. Actually, I'm kind of wondering why pg_upgrade has a --new-bindir
> > > option at all, rather than just insisting on finding the new-version
> > > executab
On Tue, Mar 19, 2019 at 02:43:49AM -0400, Bruce Momjian wrote:
> > 3. Actually, I'm kind of wondering why pg_upgrade has a --new-bindir
> > option at all, rather than just insisting on finding the new-version
> > executables in the same directory it is in. This seems like, at best,
> > a hangover
On Mon, Mar 18, 2019 at 07:35:17PM -0400, Tom Lane wrote:
> While poking around trying to find an explanation for the pg_upgrade
> failure described here:
> https://www.postgresql.org/message-id/flat/CACmJi2JUhGo2ZxqDkh-EPHNjEN1ZA1S64uHLJFWHBhUuV4492w%40mail.gmail.com
> I noticed a few things that
24 matches
Mail list logo
