Re: Document NULL

Hi David I reviewed the documentation and it's very detailed. Thanks Kashif Zeeshan Bitnine Global On Thu, May 2, 2024 at 8:24 PM David G. Johnston wrote: > On Wed, May 1, 2024 at 9:47 PM Tom Lane wrote: > >> David Rowley writes: >> > Let's bash it into shape a bit more before going any

Incorrect Assert in BufFileSize()?

I'm trying to figure out why BufFileSize() Asserts that file->fileset isn't NULL, per 1a990b207. The discussion for that commit is in [1], but I don't see any explanation of the Assert in the discussion or commit message and there's no comment explaining why it's there. The code that comes after

Re: cataloguing NOT NULL constraints

02.05.2024 19:21, Alvaro Herrera wrote: Now, you could claim that the standard doesn't mention INCLUDING/EXCLUDING CONSTRAINTS, therefore since we have come up with its definition then we should make it affect not-null constraints. However, there's also this note: NOTE 520 — s, except for

Re: Removing unneeded self joins

On 5/3/24 06:19, Tom Lane wrote: Alexander Korotkov writes: I would appreciate your review of this patchset, and review from Andrei as well. I hate to say this ... but if we're still finding bugs this basic in SJE, isn't it time to give up on it for v17? I might feel better about it if

improve performance of pg_dump with many sequences

Similar to 'pg_dump --binary-upgrade' [0], we can speed up pg_dump with many sequences by gathering the required information in a single query instead of two queries per sequence. The attached patches are works-in-progress, but here are the results I see on my machine for 'pg_dump --schema-only

Re: allow changing autovacuum_max_workers without restarting

On Mon, Apr 15, 2024 at 05:41:04PM +, Imseih (AWS), Sami wrote: >> Another option could be to just remove the restart-only GUC and hard-code >> the upper limit of autovacuum_max_workers to 64 or 128 or something. While >> that would simplify matters, I suspect it would be hard to choose an >>

Re: Weird "null" errors during DROP TYPE (pg_upgrade)

Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes: > pg_ugprade from v15 to v16 failed in an environment. Often we get a > reasonable message, but this time it was a bit weird. First, error > message: It seems like the source database must have been in quite a corrupt state already --- here we have the

Re: Support LIKE with nondeterministic collations

On Thu, May 2, 2024 at 9:38 AM Peter Eisentraut wrote: > On 30.04.24 14:39, Daniel Verite wrote: > >postgres=# SELECT '.foo.' like '_oo' COLLATE ign_punct; > > ?column? > >-- > > f > >(1 row) > > > > The first two results look fine, but the next one is inconsistent. >

Re: Proposal: Early providing of PGDG repositories for the major Linux distributions like Fedora or Debian

Hi, On Wed, 2024-04-24 at 11:02 +, Hans Buschmann wrote: > Today (24.4.2024) I upgraded my laptop to Fedora 40, but there where > no repository available, so I ended with a mix of Fedora 40 and Fedora > 39 installation. This was caused by an unexpected and very long network outage that

Re: HEAD build error on Fedora 39

Hi Andrew, On Mon, 2024-04-15 at 06:35 -0400, Andrew Dunstan wrote: > It's working on my Fedora 39. This error suggests to me that you don't > have docbook-dtds installed. If you do, then I don't know :-) Sorry for the noise. I got a new laptop, and apparently some of the packages (like this)

Weird "null" errors during DROP TYPE (pg_upgrade)

Hi, pg_ugprade from v15 to v16 failed in an environment. Often we get a reasonable message, but this time it was a bit weird. First, error message: = pg_restore: creating TYPE "foobar._packagestoptemp"

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

On Wed, May 1, 2024 at 8:40 PM Michael Paquier wrote: > > 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

Re: Removing unneeded self joins

Alexander Korotkov writes: > I would appreciate your review of this patchset, and review from Andrei as > well. I hate to say this ... but if we're still finding bugs this basic in SJE, isn't it time to give up on it for v17? I might feel better about it if there were any reason to think these

Re: Removing unneeded self joins

Hi, Richard! On Thu, May 2, 2024 at 4:14 PM Richard Guo wrote: > On Thu, May 2, 2024 at 6:08 PM Alexander Korotkov > wrote: >> On Thu, May 2, 2024 at 12:45 PM Andrei Lepikhov >> wrote: >> > One question for me is: Do we anticipate other lateral self-references >> > except the TABLESAMPLE

Re: enhance the efficiency of migrating particularly large tables

On Fri, 3 May 2024 at 09:33, David Zhang wrote: > Is there a simple way to get the min of ctid faster than using min(), but > similar to get the max of ctid using pg_relation_size? The equivalent approximation is always '(0,1)'. David

wrong comment in libpq.h

Hi Hackers, There is a comment like below in src/include/libpq/libpq.h,  /*   * prototypes for functions in be-secure.c   */ extern PGDLLIMPORT char *ssl_library; extern PGDLLIMPORT char *ssl_cert_file; ... However, 'ssl_library', 'ssl_cert_file' and the rest are global parameter settings,

Re: BitmapHeapScan streaming read user and prelim refactoring

On 4/24/24 22:46, Melanie Plageman wrote: > On Tue, Apr 23, 2024 at 6:43 PM Tomas Vondra > wrote: >> >> On 4/23/24 18:05, Melanie Plageman wrote: >>> The patch with a fix is attached. I put the test in >>> src/test/regress/sql/join.sql. It isn't the perfect location because >>> it is testing

Re: enhance the efficiency of migrating particularly large tables

Thanks a lot David Rowley for your suggestion in details. On 2024-04-08 3:23 p.m., David Rowley wrote: On Tue, 9 Apr 2024 at 09:52, David Zhang wrote: Finding the exact ctid seems overkill for what you need. Why you could just find the maximum block with: N =

Re: BitmapHeapScan streaming read user and prelim refactoring

On 4/30/24 14:07, Daniel Gustafsson wrote: >> On 26 Apr 2024, at 15:04, Melanie Plageman wrote: > >> If this seems correct to you, are you okay with the rest of the fix >> and test? We could close this open item once the patch is acceptable. > > From reading the discussion and the patch this

Re: Why is FOR ORDER BY function getting called when the index is handling ordering?

> > ... there's no reason the system needs to know the actual float value > > returned by rank_match(), the ordering operator distance function. In any > > case, that value can only be calculated based on information in the index > > itself, and can't be calculated by rank_match(). > > This seems

Re: Weird test mixup

On Thu, May 02, 2024 at 04:27:12PM +0900, Michael Paquier wrote: > On Wed, May 01, 2024 at 04:12:14PM -0700, Noah Misch wrote: > > 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: >

Re: Idea Feedback: psql \h misses -> Offers Links?

čt 2. 5. 2024 v 19:50 odesílatel Andrey M. Borodin napsal: > > > > On 17 Apr 2024, at 22:47, Kirk Wolak wrote: > > > > Thoughts? > > Today we had a hacking session with Nik and Kirk. We produced a patch to > assess how these links might look like. > > Also we needed a url_encode() and found

Re: Parallel CREATE INDEX for GIN indexes

On 5/2/24 19:12, Matthias van de Meent wrote: > On Thu, 2 May 2024 at 17:19, Tomas Vondra > wrote: >> >> Hi, >> >> In PG17 we shall have parallel CREATE INDEX for BRIN indexes, and back >> when working on that I was thinking how difficult would it be to do >> something similar to do that for

Re: Idea Feedback: psql \h misses -> Offers Links?

> On 17 Apr 2024, at 22:47, Kirk Wolak wrote: > > Thoughts? Today we had a hacking session with Nik and Kirk. We produced a patch to assess how these links might look like. Also we needed a url_encode() and found none in a codebase. It would be nice to have this as an SQL-callable

Re: Why is FOR ORDER BY function getting called when the index is handling ordering?

Chris Cleveland writes: > I'm building an index access method which supports an ordering operator: > CREATE OPERATOR pg_catalog.<<=>> ( > FUNCTION = rdb.rank_match, > LEFTARG = record, > RIGHTARG = rdb.RankSpec > ); Okay ... > ... there's no reason the system

Re: Why is FOR ORDER BY function getting called when the index is handling ordering?

On Thu, 2 May 2024 at 18:50, Chris Cleveland wrote: > > Sorry to have to ask for help here, but no amount of stepping through code is > giving me the answer. > > I'm building an index access method which supports an ordering operator: [...] > so there's no reason the system needs to know the

Re: Parallel CREATE INDEX for GIN indexes

On Thu, 2 May 2024 at 17:19, Tomas Vondra wrote: > > Hi, > > In PG17 we shall have parallel CREATE INDEX for BRIN indexes, and back > when working on that I was thinking how difficult would it be to do > something similar to do that for other index types, like GIN. I even had > that on my list of

Why is FOR ORDER BY function getting called when the index is handling ordering?

Sorry to have to ask for help here, but no amount of stepping through code is giving me the answer. I'm building an index access method which supports an ordering operator: CREATE OPERATOR pg_catalog.<<=>> ( FUNCTION = rdb.rank_match, LEFTARG = record, RIGHTARG =

Specify tranch name in error when not registered

I thought that this might be a small quality of life improvement for people scrolling through logs wondering which tranche name wasn't registered. -- Tristan Partin Neon (https://neon.tech) From 63c8d92a8a82acc5f8859ab47da5105cef46b88e Mon Sep 17 00:00:00 2001 From: Tristan Partin Date: Thu,

Re: cataloguing NOT NULL constraints

Hello Alexander On 2024-May-02, Alexander Lakhin wrote: > Could you also clarify, please, how CREATE TABLE ... LIKE is expected to > work with NOT NULL constraints? It should behave identically to 16. If in 16 you end up with a not-nullable column, then in 17 you should get a not-null

Re: New GUC autovacuum_max_threshold ?

> And as far as that goes, I'd like you - and others - to spell out more > precisely why you think 100 or 200 million tuples is too much. It > might be, or maybe it is in some cases but not in others. To me, > that's not a terribly large amount of data. Unless your tuples are > very wide, it's a

Re: Document NULL

On Wed, May 1, 2024 at 9:47 PM Tom Lane wrote: > 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

Re: Limit index pages visited in planner's get_actual_variable_range

On Thu, May 2, 2024 at 2:12 AM Rian McGuire wrote: > The planner was burning a huge amount of CPU time looking through > index pages for the first visible tuple. The problem eventually > resolved when the affected index was vacuumed, but that took several > hours to complete. This is exactly the

Re: cataloguing NOT NULL constraints

Hello Alvaro, 01.05.2024 20:49, Alvaro Herrera wrote: Here are two patches that I intend to push soon (hopefully tomorrow). Thank you for fixing those issues! Could you also clarify, please, how CREATE TABLE ... LIKE is expected to work with NOT NULL constraints? I wonder whether EXCLUDING

Re: Build with meson + clang + sanitizer resulted in undefined reference

On Wed, 1 May 2024 at 00:11, Dmitry Dolgov <9erthali...@gmail.com> wrote: > Seems to be a meson quirk [1]. I could reproduce this, and adding > -Db_lundef=false on top of your configuration solved the issue. > > [1]: https://github.com/mesonbuild/meson/issues/3853 > Thank you for a reply! Yes,

Re: [PoC] Reducing planning time when tables have many partitions

On Thu, May 2, 2024 at 3:57 PM Yuya Watari wrote: > hi. sorry to bother you, maybe a dumb question. trying to understand something under the hood. currently I only applied v24-0001-Speed-up-searches-for-child-EquivalenceMembers.patch. on v24-0001: +/* + * add_eq_member - build a new

Re: Rename libpq trace internal functions

On 24.04.24 12:34, Yugo NAGATA wrote: On Wed, 24 Apr 2024 09:39:02 +0200 Peter Eisentraut wrote: libpq's pqTraceOutputMessage() used to look like this: case 'Z': /* Ready For Query */ pqTraceOutputZ(conn->Pfdebug, message, ); break; Commit f4b54e1ed98

Re: EXPLAN redundant options

"David G. Johnston" writes: > On Thu, May 2, 2024 at 6:17 AM jian he wrote: >> explain (verbose, verbose off, analyze on, analyze off, analyze on) > I have no desire to introduce breakage here. The implemented concept is > actually quite common. The inconsistency with COPY seems like a minor

Re: EXPLAN redundant options

On Thu, May 2, 2024, at 10:36 AM, David G. Johnston wrote: > On Thu, May 2, 2024 at 6:17 AM jian he wrote: >> explain (verbose, verbose off, analyze on, analyze off, analyze on) > > I would just update this paragraph to note the last one wins behavior. > > "When the option list is surrounded by

Re: Support LIKE with nondeterministic collations

On 30.04.24 14:39, Daniel Verite wrote: postgres=# SELECT '.foo.' like '_oo' COLLATE ign_punct; ?column? -- f (1 row) The first two results look fine, but the next one is inconsistent. This is correct, because '_' means "any single character". This is independent of

Re: EXPLAN redundant options

On Thu, May 2, 2024 at 6:17 AM jian he wrote: > explain (verbose, verbose off, analyze on, analyze off, analyze on) > > I would just update this paragraph to note the last one wins behavior. "When the option list is surrounded by parentheses, the options can be written in any order. However,

EXPLAN redundant options

hi. just found out we can: explain (verbose, verbose off, analyze on, analyze off, analyze on) select count(*) from tenk1; similar to COPY, do we want to error out these redundant options?

Re: Removing unneeded self joins

On Thu, May 2, 2024 at 6:08 PM Alexander Korotkov wrote: > On Thu, May 2, 2024 at 12:45 PM Andrei Lepikhov > wrote: > > One question for me is: Do we anticipate other lateral self-references > > except the TABLESAMPLE case? Looking into the extract_lateral_references > > implementation, I see

AW: Type and CAST error on lowest negative integer values for smallint, int and bigint

Thank you for your quick response. This was very helpfull and resolved my problem. But for me it is a bit counterintuitive that -32768 is not treated as a negative constant but as a unary operator to a positive constant. It could be helpfull to remind the user of the nature of negative

Re: Typos in the code and README

Hello, 28.04.2024 11:05, David Rowley wrote: On Sat, 20 Apr 2024 at 16:09, David Rowley wrote: Here are a few more to see if it motivates anyone else to do a more thorough search for another batch. I've pushed these now. Please look also at the list of other typos and inconsistencies I've

Re: Type and CAST error on lowest negative integer values for smallint, int and bigint

On Thu, 2 May 2024 at 23:25, Hans Buschmann wrote: > postgres=# select -32768::smallint; > ERROR: smallint out of range The precedence order of operations applies the cast before the unary minus operator. Any of the following will work: postgres=# select cast(-32768 as smallint),

Type and CAST error on lowest negative integer values for smallint, int and bigint

I tried to initialize a table with values for smallint columns. The final goal is to get mask values for logical operations. The insert failed with ERROR: smallint out of range. the same occurs when using a simple select statement like: select -32768::smallint; select -2147483648::int;

Re: Reducing the log spam

On Thu, 2 May 2024 at 13:08, Jelte Fennema-Nio wrote: > 2. Change the newly added check in errcode() to only set > output_to_server to false when IsLogicalWorker() returns false. Actually a third, and probably even better solution would be to only apply this new GUC to non-backgroundworker

Re: Reducing the log spam

On Thu, 2 May 2024 at 12:47, Laurenz Albe wrote: > Yes. But I'd argue that that is a shortcoming of logical replication: > there should be a ways to get this information via SQL. Having to look into > the log file is not a very useful option. Definitely agreed that accessing the error details

Re: Reducing the log spam

On Mon, 2024-03-11 at 09:33 +0100, Jelte Fennema-Nio wrote: > -   the subscriber's server log. > +   the subscriber's server log if you remove 23505 from > +   . > > This seems like a pretty big regression. Being able to know why your > replication got closed seems pretty critical. Yes. But I'd

Re: Removing unneeded self joins

On Thu, May 2, 2024 at 12:45 PM Andrei Lepikhov wrote: > > On 5/1/24 18:59, Alexander Korotkov wrote: > > I think we probably could forbid SJE for the tables with TABLESAMPLE > > altogether. Please, check the attached patch. > Your patch looks good to me. I added some comments and test case into

Re: Removing unneeded self joins

On 5/1/24 18:59, Alexander Korotkov wrote: I think we probably could forbid SJE for the tables with TABLESAMPLE altogether. Please, check the attached patch. Your patch looks good to me. I added some comments and test case into the join.sql. One question for me is: Do we anticipate other

Re: Extend ALTER DEFAULT PRIVILEGES for large objects

On Fri, 26 Apr 2024 12:23:45 +0200 Matthias van de Meent wrote: > On Fri, 26 Apr 2024 at 10:54, Yugo NAGATA wrote: > > > > On Wed, 24 Apr 2024 16:08:39 -0500 > > Nathan Bossart wrote: > > > > > On Tue, Apr 23, 2024 at 11:47:38PM -0400, Tom Lane wrote: > > > > On the whole I find this proposed

Re: Weird test mixup

> On 2 May 2024, at 13:43, Michael Paquier wrote: > > A detach is not a wakeup. Oh, now I see. Sorry for the noise. Detaching local injection point of other backend seems to be useless and can be forbidden. As far as I understand, your patch is already doing this in + if

Re: Weird test mixup

On Thu, May 02, 2024 at 01:33:45PM +0500, Andrey M. Borodin wrote: > That seems to prevent meaningful use case. If we want exactly one > session to be waiting just before some specific point, the only way > to achieve this is to create local injection point. But the session > must be resumable

Re: Weird test mixup

> On 2 May 2024, at 12:27, Michael Paquier wrote: > > On Wed, May 01, 2024 at 04:12:14PM -0700, Noah Misch wrote: >> 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:

Re: [PoC] Reducing planning time when tables have many partitions

Hello Ashutosh, Thank you for your email and for reviewing the patch. I sincerely apologize for the delay in responding. On Wed, Mar 6, 2024 at 11:16 PM Ashutosh Bapat wrote: > here's summary of observations > 1. The patch improves planning time significantly (3X to 20X) and the > improvement

Re: Weird test mixup

On Wed, May 01, 2024 at 04:12:14PM -0700, Noah Misch wrote: > 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

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

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

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

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