date:20240520

Re: broken tables on hot standby after migration on PostgreSQL 16 (3x times last month)

2024-05-20 Thread Pavel Stehule

Hi



>
> Another question: Do you use pg_repack or such?
>

pg_repack was used for some tables, but I found broken tables, where
pg_repack was not used.

Regards

Pavel

>
> Greetings,
>
> Andres Freund
>

Re: Speed up clean meson builds by ~25%

2024-05-20 Thread Peter Eisentraut


On 19.05.24 00:09, Andres Freund wrote:

On 2024-05-18 00:35:08 +0200, Peter Eisentraut wrote:

I retested the patch from 2024-04-07 (I think that's the one that "fixed
that"?  There are multiple "v1" patches in this thread.) using gcc-14 and
clang-18, with ccache disabled of course.  The measured effects of the patch
are:

gcc-14:   1% slower
clang-18: 3% faster

So with that, it doesn't seem very interesting.

I wonder whether the reason you're seing less benefit than Jelte is that - I'm
guessing - you now used ninja 1.12 and Jelte something older.  Ninja 1.12
prioritizes building edges using a "critical path" heuristic, leading to
scheduling nodes with more incoming dependencies, and deeper in the dependency
graph earlier.


Yes!  Very interesting!

With ninja 1.11 and gcc-14, I see the patch gives about a 17% speedup.

Re: Cleaning up perl code

2024-05-20 Thread Michael Paquier

On Tue, May 21, 2024 at 06:00:00AM +0300, Alexander Lakhin wrote:
> I reviewed my collection of unica I gathered for several months, but had
> found some of them too minor/requiring more analysis.
> Then I added more with perlcritic's policy UnusedVariables, and also
> checked for unused subs with a script from blogs.perl.org (and it confirmed
> my only previous find of that kind).

Nice catches from both of you.  The two ones in
generate-wait_event_types.pl are caused by me, actually.

Not sure about the changes in the errcodes scripts, though.  The
current state of thing can be also useful when it comes to debugging
the parsing, and it does not hurt to keep the parsing rules the same
across the board.

>> The scripts parsing errcodes.txt really should be refactored into using
>> a common module, but that's a patch for another day.
> 
> Agree, and I would leave 005_negotiate_encryption.pl (with $node_conf,
> $server_config unused since d39a49c1e) aside for another day too.

I'm not sure about these ones as each one of these scripts have their
own local tweaks.  Now, if there is a cleaner picture with a .pm
module I don't see while reading the whole, why not as long as it
improves the code.
--
Michael


signature.asc
Description: PGP signature

Re: inconsistent quoting in error messages

2024-05-20 Thread Peter Smith

On Tue, May 21, 2024 at 2:56 PM Kyotaro Horiguchi
 wrote:
>
> I noticed that there are slightly inconsistent messages regarding
> quoting policies.
>
> > This happens if you temporarily set "wal_level=minimal" on the server.
> > WAL generated with "full_page_writes=off" was replayed during online backup
>
> > pg_log_standby_snapshot() can only be used if "wal_level" >= "replica"
>
> > WAL streaming ("max_wal_senders" > 0) requires "wal_level" to be "replica" 
> > or "logical"
>
> I think it's best to quote variable names and values separately, like
> "wal_level" = "minimal" (but not use quotes for numeric values), as it
> seems to be the most common practice. Anyway, we might want to unify
> them.
>
>
> Likewise, I saw two different versions of values with units.
>
> > "max_stack_depth" must not exceed %ldkB.
> > "vacuum_buffer_usage_limit" must be 0 or between %d kB and %d kB
>
> I'm not sure, but it seems like the latter version is more common.
>
> regards.
>

Hi,

I think it might be better to keep all the discussions about GUC
quoting and related topics like this confined to the main thread here
[1]. Otherwise, we might end up with a bunch of competing patches.

==
[1] 
https://www.postgresql.org/message-id/CAHut%2BPv-kSN8SkxSdoHano_wPubqcg5789ejhCDZAcLFceBR-w%40mail.gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia

inconsistent quoting in error messages

2024-05-20 Thread Kyotaro Horiguchi

I noticed that there are slightly inconsistent messages regarding
quoting policies.

> This happens if you temporarily set "wal_level=minimal" on the server.
> WAL generated with "full_page_writes=off" was replayed during online backup
 
> pg_log_standby_snapshot() can only be used if "wal_level" >= "replica"

> WAL streaming ("max_wal_senders" > 0) requires "wal_level" to be "replica" or 
> "logical"

I think it's best to quote variable names and values separately, like
"wal_level" = "minimal" (but not use quotes for numeric values), as it
seems to be the most common practice. Anyway, we might want to unify
them.


Likewise, I saw two different versions of values with units.

> "max_stack_depth" must not exceed %ldkB.
> "vacuum_buffer_usage_limit" must be 0 or between %d kB and %d kB

I'm not sure, but it seems like the latter version is more common.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Re: Postgres and --config-file option

2024-05-20 Thread Michael Paquier

On Mon, May 20, 2024 at 12:20:02PM +0300, Aleksander Alekseev wrote:
> Robert Haas  writes:
>> I agree that it's not necessary or particularly useful for this hint
>> to be exhaustive.  I could get behind your suggestion of
>> s/You must specify/Specify/, but I also think it's fine to do nothing.
> 
> Fair enough, let's leave the help message as is then. I closed the
> corresponding CF entry.

I'm OK to leave this be, as well.
--
Michael


signature.asc
Description: PGP signature

Re: doc regexp_replace replacement string \n does not explained properly

2024-05-20 Thread David G. Johnston

On Monday, May 20, 2024, jian he  wrote:

> hi.
>
> https://www.postgresql.org/docs/current/functions-
> matching.html#FUNCTIONS-POSIX-REGEXP
>
>
>  If there is a match,
> the source string is returned with the replacement string substituted
> for the matching substring.


>
This happens regardless of the presence of parentheses.


>
>  The replacement string can contain \n,
> where n is 1 through 9, to indicate that the source substring matching
> the n'th parenthesized subexpression of the pattern should be
> inserted, and it can contain \& to indicate that the substring
> matching the entire pattern should be inserted.


 Then if the replacement text contains “\n” expressions those are replaced
with text captured from the corresponding parentheses group.


> <<
> i think it explained example like:
> SELECT regexp_replace('foobarbaz', 'b(..)', 'X\1Y', 'g');


global - find two matches to process.

foobarbaz
fooX\1YX\1Y
fooXarYXazY


>
> but it does not seem to explain cases like:
> SELECT regexp_replace('foobarbaz', 'b(..)', 'X\2Y', 'g');
>
>
foobarbaz
fooX\2YX\2Y
fooX{empty string, no second capture group}YX{empty}Y
fooXYXY

The docs are correct, though I suppose being explicit that a missing
capture group results in an empty string substitution instead of an error
is probably warranted.

David J.

doc regexp_replace replacement string \n does not explained properly

2024-05-20 Thread jian he

hi.

https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-POSIX-REGEXP
<<

Re: Cleaning up perl code

2024-05-20 Thread Alexander Lakhin


Hello Dagfinn,

Thank you for paying attention to it and improving the possible fix!

20.05.2024 23:39, Dagfinn Ilmari Mannsåker wrote:

Nice cleanup!  Did you use some static analysis tool, or did look for
them manually?


I reviewed my collection of unica I gathered for several months, but had
found some of them too minor/requiring more analysis.
Then I added more with perlcritic's policy UnusedVariables, and also
checked for unused subs with a script from blogs.perl.org (and it confirmed
my only previous find of that kind).


  If I add [Variables::ProhibitUnusedVariables] to
src/tools/perlcheck/perlcriticrc, it finds a few more, see the attached
patch.


Yes, I saw unused $sqlstates, but decided that they are meaningful enough
to stay. Though maybe enabling ProhibitUnusedVariables justifies fixing
them too.


The scripts parsing errcodes.txt really should be refactored into using
a common module, but that's a patch for another day.


Agree, and I would leave 005_negotiate_encryption.pl (with $node_conf,
$server_config unused since d39a49c1e) aside for another day too.

Best regards,
Alexander

Path to unreverting "Allow planner to use Merge Append to efficiently implement UNION"

2024-05-20 Thread David Rowley

Earlier today in [1], a bug was reported regarding a problem with the
code added in 66c0185a3 where I'd failed to handle the case correctly
where the UNION's targetlist has columns which are not sortable. For
pg_class, that's relfrozenxid, relminmxid and relacl.

The most minimal reproducer prior to the revert is:

set enable_hashagg=0;
explain (costs off) select '123'::xid union select '123'::xid;

There is still some ongoing discussion about this on the release
mailing list as per mentioned by Tom in the commit message in
7204f3591.

At some point that discussion is going to need to circle back onto
-hackers again, and since I've already written a patch to fix the
issue and un-revert Tom's revert. I just wanted a place on -hackers to
allow that code to be viewed and discussed. I did also post a patch
on [2], but that no longer applies to master due to the revert.

I'll allow the RMT to choose where the outcome of the RMT decision
goes. Let this thread be for at least the coding portion of this or
be my thread for this patch for the v18 cycle if the RMT rules in
favour of keeping that code reverted for v17.

I've attached 2 patches.

0001 is a simple revert of Tom's revert (7204f3591).
0002 fixes the issue reported by Hubert.

If anyone wants to have a look, I'd be grateful for that. Tom did
call for further review after this being the 4th issue reported for
66c0185a3.

David

[1] https://postgr.es/message-id/Zktzf926vslR35Fv%40depesz.com
[2]
https://www.postgresql.org/message-id/CAApHDvpDQh1NcL7nAsd3YAKj4vgORwesB3GYuNPnEXXRfA2g4w%40mail.gmail.com

1 2 >

100 matches

Mail list logo