Re: New GUC autovacuum_max_threshold ?

Le 01/05/2024 à 20:50, Robert Haas a écrit : Possibly what we need here is something other than a cap, where, say, we vacuum a 10GB table twice as often as now, a 100GB table four times as often, and a 1TB table eight times as often. Or whatever the right answer is. IMO, it would make more s

Re: small documentation fixes related to collations/ICU

On 29.04.24 09:18, Kashif Zeeshan wrote: Looks good. On Mon, Apr 29, 2024 at 12:05 PM Peter Eisentraut > wrote: I found two mistakes related to collation and/or ICU support in the documentation that should probably be fixed and backpatched.  See attache

Limit index pages visited in planner's get_actual_variable_range

Hi hackers, It seems the get_actual_variable_range function has a long history of fixes attempting to improve its worst-case behaviour, most recently in 9c6ad5eaa95, which limited the number of heap page fetches to 100. There's currently no limit on the number of index pages fetched. We managed t

Re: Partitioned tables and [un]loggedness

On Thu, Apr 25, 2024 at 08:55:27AM +0900, Michael Paquier wrote: > On Wed, Apr 24, 2024 at 04:43:58PM -0700, David G. Johnston wrote: >> My point is that if you feel that treating logged as a copy-able property >> is OK then doing the following should also just work: >> >> postgres=# create temp t

Re: Document NULL

David Rowley writes: > Let's bash it into shape a bit more before going any further on actual > wording. FWIW, I want to push back on the idea of making it a tutorial section. I too considered that, but in the end I think it's a better idea to put it into the "main" docs, for two reasons: 1. I

Re: Document NULL

On Thu, 2 May 2024 at 03:12, David G. Johnston wrote: > Attached is a very rough draft attempting this, based on my own thoughts and > those expressed by Tom in [1], which largely align with mine. Thanks for picking this up. I agree that we should have something to improve this. It would be goo

Re: Document NULL

On Wed, May 1, 2024 at 8:12 PM David G. Johnston wrote: > Hi, > > Over in [1] it was rediscovered that our documentation assumes the reader > is familiar with NULL. It seems worthwhile to provide both an introduction > to the topic and an overview of how this special value gets handled > through

Re: [PATCH] json_lex_string: don't overread on bad UTF8

On Thu, May 02, 2024 at 11:23:13AM +0900, Michael Paquier wrote: > About the fact that we may finish by printing unfinished UTF-8 > sequences, I'd be curious to hear your thoughts. Now, the information > provided about the partial byte sequences can be also useful for > debugging on top of having

Re: [PATCH] json_lex_string: don't overread on bad UTF8

On Wed, May 01, 2024 at 04:22:24PM -0700, Jacob Champion wrote: > On Tue, Apr 30, 2024 at 11:09 PM Michael Paquier wrote: >> Not sure to like much the fact that this advances token_terminator >> first. Wouldn't it be better to calculate pg_encoding_mblen() first, >> then save token_terminator? I

Re: New GUC autovacuum_max_threshold ?

On Sat, 27 Apr 2024 at 02:13, Robert Haas wrote: > Let's compare the current situation to the situation post-patch with a > cap of 500k. Consider a table 1024 times larger than the one I > mentioned above, so pgbench scale factor 25600, size on disk 320GB. > Currently, that table will be vacuumed

Re: [PATCH] json_lex_string: don't overread on bad UTF8

On Tue, Apr 30, 2024 at 11:09 PM Michael Paquier wrote: > Not sure to like much the fact that this advances token_terminator > first. Wouldn't it be better to calculate pg_encoding_mblen() first, > then save token_terminator? I feel a bit uneasy about saving a value > in token_terminator past th

Re: Weird test mixup

While writing an injection point test, I encountered a variant of the race condition that f4083c4 fixed. It had three sessions and this sequence of events: s1: local-attach to POINT s2: enter InjectionPointRun(POINT), yield CPU just before injection_callback() s3: detach POINT, deleting the Injec

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Hi! 30.04.2024 23:15, Justin Pryzby пишет: Is this issue already fixed ? I wasn't able to reproduce it. Maybe it only happened with earlier patch versions applied ? I think this was fixed in commit [1]. [1] https://github.com/postgres/postgres/commit/fcf80c5d5f0f3787e70fca8fd029d2e08a923f91

Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing

On Wed, May 1, 2024 at 11:57 AM Thomas Spear wrote: > It does fail to validate for case 4 after all. I must have had a copy/paste > error during past tests. Okay, good. Glad it's behaving as expected! > So then it sounds like putting the MS root in root.crt (as we have done to > fix this) is t

Re: Query Discrepancy in Postgres HLL Test

On Wed, May 1, 2024 at 1:10 PM Ayush Vatsa wrote: > I'm currently delving into Postgres HLL (HyperLogLog) functionality and have > encountered an unexpected behavior while executing queries from the > "cumulative_add_sparse_edge.sql" regress test. This particular test data file > involves three

Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing

On Wed, May 1, 2024 at 12:31 PM Jacob Champion < jacob.champ...@enterprisedb.com> wrote: > On Wed, May 1, 2024 at 8:17 AM Thomas Spear wrote: > > Circling back to my original question, why is there a difference in > behavior? > > > > What I believe should be happening isn't what's happening: > >

Re: New GUC autovacuum_max_threshold ?

On Wed, May 1, 2024 at 2:19 PM Imseih (AWS), Sami wrote: > > Unless I'm missing something major, that's completely bonkers. It > > might be true that it would be a good idea to vacuum such a table more > > often than we do at present, but there's no shot that we want to do it > > that much more of

Re: New GUC autovacuum_max_threshold ?

I've been following this discussion and would like to add my 2 cents. > Unless I'm missing something major, that's completely bonkers. It > might be true that it would be a good idea to vacuum such a table more > often than we do at present, but there's no shot that we want to do it > that much mo

Re: cataloguing NOT NULL constraints

On 2024-Apr-25, Alvaro Herrera wrote: > > Also, I've found a weird behaviour with a non-inherited NOT NULL > > constraint for a partitioned table: > > CREATE TABLE pt(a int NOT NULL NO INHERIT) PARTITION BY LIST (a); > Ugh. Maybe a way to handle this is to disallow NO INHERIT in > constraints on

Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing

On Wed, May 1, 2024 at 8:17 AM Thomas Spear wrote: > Circling back to my original question, why is there a difference in behavior? > > What I believe should be happening isn't what's happening: > 1. If ~/.postgresql/root.crt contains the MS root, and I don't specify > sslrootcert= -- successful v

Query Discrepancy in Postgres HLL Test

Hi PostgreSQL Community, I'm currently delving into Postgres HLL (HyperLogLog) functionality and have encountered an unexpected behavior while executing queries from the " cumulative_add_sparse_edge.sql

Re: Logging which interface was connected to in log_line_prefix

Thank you for taking the time to review this. I've attached a new rebased version, which has no significant changes. > There is a comment in the patch that states: > > /* We do not need clean_ipv6_addr here: just report verbatim */ > > I am not quite sure what it means, but I am guessing it means

Re: Support tid range scan in parallel?

> This isn't a complete review. It's just that this seems enough to keep > you busy for a while. I can look a bit harder when the patch is > working correctly. I think you should have enough feedback to allow > that now. Thanks for the test, review and feedback. They are greatly appreciated!

Proposal for Updating CRC32C with AVX-512 Algorithm.

Hi, Comparing the current SSE4.2 implementation of the CRC32C algorithm in Postgres, to an optimized AVX-512 algorithm [0] we observed significant gains. The result was a ~6.6X average multiplier of increased performance measured on 3 different Intel products. Details below. The AVX-512 algorit

Re: Document NULL

On Wed, May 1, 2024, 16:13 David G. Johnston wrote: > Hi, > > Over in [1] it was rediscovered that our documentation assumes the reader > is familiar with NULL. It seems worthwhile to provide both an introduction > to the topic and an overview of how this special value gets handled > throughout

Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing

On Wed, May 1, 2024 at 9:23 AM Jacob Champion < jacob.champ...@enterprisedb.com> wrote: > On Wed, May 1, 2024 at 6:48 AM Thomas Spear wrote: > > I dumped out the certificates presented by the server using openssl, and > the chain that gets output includes "Microsoft Azure RSA TLS Issuing CA 08".

Document NULL

Hi, Over in [1] it was rediscovered that our documentation assumes the reader is familiar with NULL. It seems worthwhile to provide both an introduction to the topic and an overview of how this special value gets handled throughout the system. Attached is a very rough draft attempting this, base

Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing

On Wed, May 1, 2024 at 6:48 AM Thomas Spear wrote: > I dumped out the certificates presented by the server using openssl, and the > chain that gets output includes "Microsoft Azure RSA TLS Issuing CA 08". > On https://www.microsoft.com/pkiops/docs/repository.htm the page says that > that cert wa

Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing

On Tue, Apr 30, 2024 at 5:19 PM Jacob Champion < jacob.champ...@enterprisedb.com> wrote: On Tue, Apr 30, 2024 at 2:41 PM Thomas Spear wrote: > The full details can be found at github.com/pgjdbc/pgjdbc/discussions/3236 - in summary, both jdbc-postgres and the psql cli seem to be affected by an iss

Re: Refactoring backend fork+exec code

On 28.04.2024 22:36, Heikki Linnakangas wrote: Peter E noticed and Michael fixed them in commit 768ceeeaa1 already. Didn't check that is already fixed in the current master. Sorry! Thanks for pointing this out! With the best wishes, -- Anton A. Melnikov Postgres Professional: http://www.pos

Re: Removing unneeded self joins

On Wed, May 1, 2024 at 2:00 PM Alexander Lakhin wrote: > 30.04.2024 13:20, Alexander Korotkov wrote: > > On Tue, Apr 30, 2024 at 9:00 AM Alexander Lakhin > > wrote: > >> I've discovered another failure, introduced by d3d55ce57. > >> Please try the following: > >> CREATE TABLE t (a int unique, b

Re: SQL:2011 application time

On Wed, May 1, 2024 at 12:39 AM Paul Jungwirth wrote: > > On 4/30/24 09:24, Robert Haas wrote: > > Peter, could you have a look at > > http://postgr.es/m/47550967-260b-4180-9791-b224859fe...@illuminatedcomputing.com > > and express an opinion about whether each of those proposals are (a) > > good

Re: Removing unneeded self joins

30.04.2024 13:20, Alexander Korotkov wrote: On Tue, Apr 30, 2024 at 9:00 AM Alexander Lakhin wrote: I've discovered another failure, introduced by d3d55ce57. Please try the following: CREATE TABLE t (a int unique, b float); SELECT * FROM t NATURAL JOIN LATERAL (SELECT * FROM t t2 TABLESAMPLE

Re: Control flow in logical replication walsender

On Tue, Apr 30, 2024 at 11:28 PM Christophe Pettus wrote: > > Hi, > > I wanted to check my understanding of how control flows in a walsender > doing logical replication. My understanding is that the (single) thread in > each walsender process, in the simplest case, loops on: > > 1. Pull a record

Re: Support tid range scan in parallel?

On Wed, 1 May 2024 at 07:10, Cary Huang wrote: > Yes of course. These numbers were obtained earlier this year on master with > the patch applied most likely without the read stream code you mentioned. The > patch attached here is rebased to commit > dd0183469bb779247c96e86c2272dca7ff4ec9e7 on m

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Thu, Apr 25, 2024 at 8:36 AM Masahiko Sawada wrote: > > On Mon, Apr 15, 2024 at 6:12 PM John Naylor wrote: > > - RT_KEY_GET_SHIFT is not covered for key=0: > > > > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/include/lib/radixtree.h.gcov.html#L803 > > > > That should be fairly s