Kyotaro Horiguchi writes:
> FWIW, the following change makes sense to me according to the spec of
> validate_exec()...
> diff --git a/src/bin/pg_upgrade/exec.c b/src/bin/pg_upgrade/exec.c
> index fadeea12ca..3cff186213 100644
> --- a/src/bin/pg_upgrade/exec.c
> +++ b/src/bin/pg_upgrade/exec.c
> @
Peter Eisentraut writes:
> On 14.06.22 20:57, Tom Lane wrote:
>> Hence, the patch below removes trailing newlines from all of
>> pg_upgrade's message strings, and teaches its logging infrastructure
>> to print them where appropriate. As in logging.c, there's now an
>> Assert that no format string
On 14.06.22 20:57, Tom Lane wrote:
Hence, the patch below removes trailing newlines from all of
pg_upgrade's message strings, and teaches its logging infrastructure
to print them where appropriate. As in logging.c, there's now an
Assert that no format string passed to pg_log() et al ends with
Greg Stark writes:
> On Wed, 15 Jun 2022 at 11:54, Tom Lane wrote:
>> Yeah, that is sort of the inverse problem. I think those are there
>> to ensure that the text appears on a fresh line even if the current
>> line has transient status on it. We could get rid of those perhaps
>> if we teach pg
On Wed, 15 Jun 2022 at 11:54, Tom Lane wrote:
>
> Yeah, that is sort of the inverse problem. I think those are there
> to ensure that the text appears on a fresh line even if the current
> line has transient status on it. We could get rid of those perhaps
> if we teach pg_log_v to remember wheth
Kyotaro Horiguchi writes:
> Also leading newlines and just "\n" bug me when I edit message
> catalogues with poedit. I might want a line-spacing function like
> pg_log_newline(PG_REPORT) if we need line-breaks in the ends of a
> message.
Yeah, that is sort of the inverse problem. I think those a
On 14.06.22 20:57, Tom Lane wrote:
I'll stick this in the CF queue, but I wonder if there is any case
for squeezing it into v15 instead of waiting for v16.
Let's stick this into 16 and use it as a starting point of tidying all
this up in pg_upgrade.
At Wed, 15 Jun 2022 13:05:52 +0900 (JST), Kyotaro Horiguchi
wrote in
> By the way, I noticed that pg_upgrade complains wrong way when the
> specified binary path doesn't contain "postgres" file.
>
> $ pg_upgrade -b /tmp -B /tmp -d /tmp -D /tmp
>
> check for "/tmp/postgres" failed: not a regula
By the way, I noticed that pg_upgrade complains wrong way when the
specified binary path doesn't contain "postgres" file.
$ pg_upgrade -b /tmp -B /tmp -d /tmp -D /tmp
check for "/tmp/postgres" failed: not a regular file
Failure, exiting
I think it should be a quite common mistake to specify the
At Tue, 14 Jun 2022 14:57:40 -0400, Tom Lane wrote in
> Per the discussion at [1], pg_upgrade currently doesn't use
> common/logging.c's functions. Making it do so looks like a
> bigger lift than is justified, but there is one particular
> inconsistency that I think we ought to remove: pg_upgra
Per the discussion at [1], pg_upgrade currently doesn't use
common/logging.c's functions. Making it do so looks like a
bigger lift than is justified, but there is one particular
inconsistency that I think we ought to remove: pg_upgrade
expects (most) message strings to end in newlines, while logg
11 matches
Mail list logo
