From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: add timing information to pg_upgrade |
Date: | 2023-08-22 09:49:33 |
Message-ID: | 632b1c6b-fc51-816b-4848-4063551777b0@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01.08.23 17:45, Nathan Bossart wrote:
> On Tue, Aug 01, 2023 at 09:46:02AM +0200, Peter Eisentraut wrote:
>> On 31.07.23 20:37, Nathan Bossart wrote:
>>> - prep_status("Checking for incompatible \"aclitem\" data type in user tables");
>>> + prep_status("Checking for \"aclitem\" data type in user tables");
>>
>> Why these changes? I think this is losing precision about what it's doing.
>
> The message is too long, so there's no space between it and the "ok"
> message:
>
> Checking for incompatible "aclitem" data type in user tablesok
>
> Instead of altering the messages, we could bump MESSAGE_WIDTH from 60 to
> 62 or 64. Do you prefer that approach? (BTW this probably needs to be
> back-patched to v16.)
Let's change MESSAGE_WIDTH to 62 in v16, and then pursue the larger
restructuring leisurely.
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2023-08-22 09:51:38 | Re: Support run-time partition pruning for hash join |
Previous Message | Richard Guo | 2023-08-22 09:43:26 | Re: Support run-time partition pruning for hash join |