Re: Incorrect handling of IS [NOT] NULL quals on inheritance parents

On Wed, Apr 10, 2024 at 1:13 PM David Rowley wrote: > I looked at the patch and I don't think it's a good idea to skip > recording NOT NULL constraints to fix based on the fact that it > happens to result in this particular optimisation working correctly. > It seems that just makes this work in

Re: Can't find not null constraint, but \d+ shows that

On Wed, Apr 10, 2024 at 1:29 AM Alvaro Herrera wrote: > > On 2024-Mar-29, Tender Wang wrote: > > > I think aboved case can explain what's meaning about comments in > > dropconstraint_internal. > > But here, in RemoveConstraintById() , we only care about primary key case, > > so NOT NULL is better

Re: Can't find not null constraint, but \d+ shows that

jian he 于2024年4月10日周三 14:10写道： > On Wed, Apr 10, 2024 at 1:29 AM Alvaro Herrera > wrote: > > > > On 2024-Mar-29, Tender Wang wrote: > > > > > I think aboved case can explain what's meaning about comments in > > > dropconstraint_internal. > > > But here, in RemoveConstraintById() , we only care

Re: Make COPY format extendable: Extract COPY TO format implementations

Hi Andres, Could you take a look at this? I think that you don't want to touch the current text/csv/binary implementations. The v17 patch approach doesn't touch the current text/csv/binary implementations. What do you think about this approach? Thanks, -- kou In

Re: Speed up clean meson builds by ~25%

On Wed, Apr 10, 2024 at 5:03 PM Tom Lane wrote: > I don't doubt that there are other clang versions where the problem > bites a lot harder. What result do you get from the test I tried > (turning mm_strdup into a no-op macro)? #define mm_strdup(x) (x) does this: Apple clang 15: master: 14s ->

Re: Is this a problem in GenericXLogFinish()?

On Wed, Apr 10, 2024 at 1:27 PM Michael Paquier wrote: > > On Tue, Apr 09, 2024 at 10:25:36AM +, Hayato Kuroda (Fujitsu) wrote: > >> On Fri, Apr 05, 2024 at 06:22:58AM +, Hayato Kuroda (Fujitsu) wrote: > >> I'm slightly annoyed by the fact that there is no check on > >>

Revise some error messages in split partition code

I noticed some error messages in the split partition code that are not up to par. Such as: "new partitions not have value %s but split partition has" how about we revise it to: "new partitions do not have value %s but split partition does" Another one is: "any partition in the list should be

Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

On 06.04.24 19:47, Daniel Gustafsson wrote: In bumping we want to move to 1.1.1 since that's the first version with the rewritten RNG which is fork-safe by design, something PostgreSQL clearly benefits from. I think it might be better to separate this into two steps: 1. Move to 1.1.0. This

Re: sql/json remaining issue

On Tue, Apr 9, 2024 at 8:37 PM Amit Langote wrote: > On Tue, Apr 9, 2024 at 4:47 PM jian he wrote: > > the last query error message is: > > ` > > ERROR: no SQL/JSON item > > ` > > > > we are in ExecEvalJsonExprPath, can we output it to be: > > ` > > ERROR: after applying json_path "5s", no

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Hello Alexander and Dmitry, 10.04.2024 02:03, Alexander Korotkov wrote: On Mon, Apr 8, 2024 at 11:43 PM Dmitry Koval wrote: Attached fix for the problems found by Alexander Lakhin. About grammar errors. Unfortunately, I don't know English well. Therefore, I plan (in the coming days) to show

Re: Support a wildcard in backtrace_functions

On Fri, 22 Mar 2024 at 11:09, Jelte Fennema-Nio wrote: > On Thu, 21 Mar 2024 at 15:41, Jelte Fennema-Nio wrote: > > Attached is a patch that implements this. Since the more I think about > > it, the more I like this approach. > > I now added a 3rd patch to this patchset which changes the >

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On 05.04.24 14:55, Robert Haas wrote: I also wonder how the protocol negotiation for column encryption is actually going to work. What are the actual wire protocol changes that are needed? What does the server need to know from the client, or the client from the server, about what is supported?

Re: Can't find not null constraint, but \d+ shows that

jian he 于2024年4月10日周三 17:34写道： > > another related bug, in master. > > drop table if exists notnull_tbl1; > CREATE TABLE notnull_tbl1 (c0 int not null, c1 int); > ALTER TABLE notnull_tbl1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1); > \d+ notnull_tbl1 > ALTER TABLE notnull_tbl1 ALTER c0 DROP NOT NULL;

Comment about handling of asynchronous requests in postgres_fdw.c

Hi, We updated $SUBJECT in back branches to make it clear (see commit f6f61a4bd), so I would like to propose to do so in HEAD as well for consistency. Attached is a patch for that. Best regards, Etsuro Fujita postgres-fdw-comment.patch Description: Binary data

Re: Detoasting optionally to make Explain-Analyze less misleading

On Wed, 3 Apr 2024 at 23:50, Tom Lane wrote: > I've pushed this after a good deal of cosmetic polishing -- for > example, I spent some effort on making serializeAnalyzeReceive > look as much like printtup as possible, in hopes of making it > easier to keep the two functions in sync in future.

Re: Can't find not null constraint, but \d+ shows that

On 2024-Apr-10, jian he wrote: > another related bug, in master. > > drop table if exists notnull_tbl1; > CREATE TABLE notnull_tbl1 (c0 int not null, c1 int); > ALTER TABLE notnull_tbl1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1); > \d+ notnull_tbl1 > ALTER TABLE notnull_tbl1 ALTER c0 DROP NOT NULL; >

Re: Table AM Interface Enhancements

On Mon, Apr 8, 2024 at 9:54 PM Robert Haas wrote: > On Mon, Apr 8, 2024 at 12:33 PM Alexander Korotkov > wrote: > > Yes, it was my mistake. I got rushing trying to fit this to FF, even doing > > significant changes just before commit. > > I'll revert this later today. The patch to revert is

some confusion about parallel insert select in postgres parallel dml develop

Dears, this is a developer of postgresql and currently engaged in research of parallel dml. I read lot of mail list about postgres parallel insert select or other related developing jobs, but i could not understand why should we determine parallel-safety of partition relations in parallel

Re: Is this a problem in GenericXLogFinish()?

On Tue, Apr 09, 2024 at 10:25:36AM +, Hayato Kuroda (Fujitsu) wrote: >> On Fri, Apr 05, 2024 at 06:22:58AM +, Hayato Kuroda (Fujitsu) wrote: >> I'm slightly annoyed by the fact that there is no check on >> is_prim_bucket_same_wrt for buffer 1 in the BLK_NEEDS_REDO case to >> show the

Re: Potential stack overflow in incremental base backup

On Fri, Mar 8, 2024 at 6:53 AM Robert Haas wrote: > ... We could > avoid transposing relative block numbers to absolute block numbers > whenever start_blkno is 0, ... Could we just write the blocks directly into the output array, and then transpose them directly in place if start_blkno > 0?

Re: postgres_fdw fails because GMT != UTC

On Thu, Apr 4, 2024 at 3:49 PM Laurenz Albe wrote: > On Thu, 2024-04-04 at 02:19 -0400, Tom Lane wrote: > > > ERROR: invalid value for parameter "TimeZone": "UTC" > > > > I am not quite clear on how broken an installation needs to be to > > reject "UTC" as a time zone setting, except that the

Re: Can't find not null constraint, but \d+ shows that

On 2024-Apr-10, Tender Wang wrote: > Yeah, it should fail as before, because c0 is primary key. > In master, although c0's pg_attribute.attnotnull is still true, but its > not-null constraint has been deleted > in dropconstraint_internal(). Yeah, the problem here is that we need to do the checks

Re: Slow catchup of 2PC (twophase) transactions on replica in LR

On Fri, Apr 5, 2024 at 4:59 PM Ajin Cherian wrote: > > On Thu, Apr 4, 2024 at 4:38 PM Amit Kapila wrote: >> >> >> I think this would probably be better than the current situation but >> can we think of a solution to allow toggling the value of two_phase >> even when prepared transactions are

Re: WIP Incremental JSON Parser

On 2024-04-09 Tu 15:42, Andrew Dunstan wrote: On 2024-04-09 Tu 07:54, Andrew Dunstan wrote: On 2024-04-09 Tu 01:23, Michael Paquier wrote: On Tue, Apr 09, 2024 at 09:48:18AM +0900, Michael Paquier wrote: There is no direct check on test_json_parser_perf.c, either, only a custom rule in

RE: Synchronizing slots from primary to standby

On Thursday, April 4, 2024 5:37 PM Amit Kapila wrote: > > BTW, while thinking on this one, I > noticed that in the function LogicalConfirmReceivedLocation(), we first update > the disk copy, see comment [1] and then in-memory whereas the same is not > true in > update_local_synced_slot() for

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

10.04.2024 12:00, Alexander Lakhin wrote: Hello Alexander and Dmitry, 10.04.2024 02:03, Alexander Korotkov wrote: Thank you.  I've pushed this fix with minor corrections from me. Please look at another anomaly with MERGE. CREATE TEMP TABLE t (i int) PARTITION BY RANGE (i); CREATE TABLE

Re: Can't find not null constraint, but \d+ shows that

another related bug, in master. drop table if exists notnull_tbl1; CREATE TABLE notnull_tbl1 (c0 int not null, c1 int); ALTER TABLE notnull_tbl1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1); \d+ notnull_tbl1 ALTER TABLE notnull_tbl1 ALTER c0 DROP NOT NULL; ALTER TABLE notnull_tbl1 ALTER c1 DROP NOT NULL;

Re: Potential stack overflow in incremental base backup

On Wed, Apr 10, 2024 at 6:21 AM Thomas Munro wrote: > Could we just write the blocks directly into the output array, and > then transpose them directly in place if start_blkno > 0? See > attached. I may be missing something, but the only downside I can > think of is that the output array is

Re: Slow catchup of 2PC (twophase) transactions on replica in LR

Hi Amit, Ajin, All Thank you for the patch and the responses. I apologize for my delayed answer due to some curcumstances. On Wednesday, April 10, 2024 14:18 MSK, Amit Kapila wrote: Vitaly, does the minimal solution provided by the proposed patch (Allow to alter two_phase option of a

Re: ❓ JSON Path Dot Precedence

On 07.04.24 18:13, David E. Wheeler wrote: Hello Hackers, A question about the behavior of the JSON Path parser. The docs[1] have this to say about numbers: Numeric literals in SQL/JSON path expressions follow JavaScript rules, which are different from both SQL and JSON in some minor

Re: Issue with the PRNG used by Postgres

Thank you Robert. I am in the process of patching this. -Parag On Wed, Apr 10, 2024 at 7:43 AM Robert Haas wrote: > On Tue, Apr 9, 2024 at 5:05 PM Andres Freund wrote: > > ISTM that the fix here is to not use a spinlock for whatever the > contention is > > on, rather than improve the RNG. > >

Re: Issue with the PRNG used by Postgres

Robert Haas writes: > Oh, yeah ... right. But then why does the comment say that it's > increasing the delay between a random fraction between 1X and 2X? I think the comment is meant to say that the new delay value will be 1X to 2X the old value. If you want to suggest different phrasing, feel

Re: Can't find not null constraint, but \d+ shows that

It turns out that trying to close all holes that lead to columns marked not-null without a pg_constraint row is not possible within the ALTER TABLE framework, because it can happen outside it also. Consider this CREATE DOMAIN dom1 AS integer; CREATE TABLE notnull_tbl (a dom1, b int, PRIMARY KEY

Re: Issue with the PRNG used by Postgres

Hi Andres, This is a little bit more complex than that. The spinlocks are taken in the LWLock(Mutex) code, when the lock is not available right away. The spinlock is taken to attach the current backend to the wait list of the LWLock. This means, that this cannot be controlled. The repro when it

Re: Issue with the PRNG used by Postgres

hi Tom, First of all thanks for you response. I did not misread it. The 0.5 is added to the result of the multiplication which then uses C integer casting, which does not round off, but just drops the decimal portion. status->cur_delay += (int) (status->cur_delay *

psql: Greatly speed up "\d tablename" when not using regexes

Running "\d tablename" from psql could take multiple seconds when running on a system with 100k+ tables. The reason for this was that a sequence scan on pg_class takes place, due to regex matching being used. Regex matching is obviously unnecessary when we're looking for an exact match. This

Re: Issue with the PRNG used by Postgres

Hi, On 2024-04-10 07:55:16 -0700, Parag Paul wrote: > This is a little bit more complex than that. The spinlocks are taken in the > LWLock(Mutex) code, when the lock is not available right away. > The spinlock is taken to attach the current backend to the wait list of the > LWLock. This means,

Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?

On Wed, Apr 10, 2024 at 12:31 AM Peter Eisentraut wrote: > * src/backend/libpq/be-secure-openssl.c > > +#include > > This patch doesn't appear to add anything, so why does it need a new > include? This one was mine -- it was an indirect header dependency that was effectively removed in 1.1.0

Re: PostgreSQL 17 Release Management Team & Feature Freeze

On Tue, Apr 9, 2024 at 5:16 PM Bruce Momjian wrote: > Committing code is a hard job, no question. However, committers have to > give up the idea that they should wait for brilliant ideas before > finalizing patches. If you come up with a better idea later, great, but > don't wait to finalize

Re: post-freeze damage control

On Tue, Apr 9, 2024 at 1:59 AM Peter Eisentraut wrote: > On 09.04.24 00:58, Michael Paquier wrote: > > That's more linked to the fact that I was going silent without a > > laptop for a few weeks before the end of the release cycle, and a way > > to say to not count on me, while I was trying to

Re: [HACKERS] make async slave to wait for lsn to be replayed

I did some experiments over synchronous replications and got that cascade replication can`t be synchronous. And  pg_wal_replay_wait() allows us to read your writes consistency on cascade replication. Beyond that, I added more tests on multi-standby replication and cascade replications. -- Ivan

Re: Speed up clean meson builds by ~25%

Thomas Munro writes: > On Wed, Apr 10, 2024 at 5:03 PM Tom Lane wrote: >> I don't doubt that there are other clang versions where the problem >> bites a lot harder. What result do you get from the test I tried >> (turning mm_strdup into a no-op macro)? > #define mm_strdup(x) (x) does this: >

Re: Issue with the PRNG used by Postgres

On Wed, Apr 10, 2024 at 11:09 AM Tom Lane wrote: > No, I think you are misreading it, because the assignment is += not =. > The present coding is > > /* increase delay by a random fraction between 1X and 2X */ > status->cur_delay += (int) (status->cur_delay * >

Re: Issue with the PRNG used by Postgres

Parag Paul writes: > So, if RNG generated 0.001 and cur_delay =1000. > Result will be > 1000 + int(1000*0.01 + 5) = (int)(1000 + (0.1+.5)) = (int)1000.6 = 1000 > <-- back to the same value Yes, with a sufficiently small RNG result, the sleep delay will not increase that time through the

Re: [PoC/RFC] Multiple passwords, interval expirations

Hi! I'm interested in this feature presence in the PostgreSQL core. Will try to provide valuable review/comments/suggestions and other help. On Tue, 10 Oct 2023 at 16:17, Gurjeet Singh wrote: > > > On Mon, Oct 9, 2023 at 2:31 AM Gurjeet Singh wrote: > > > > > > Next steps: > > > - Break the

Re: Allow non-superuser to cancel superuser tasks.

On Wed, Apr 10, 2024 at 07:58:39AM +0900, Michael Paquier wrote: > On Wed, Apr 10, 2024 at 12:52:19AM +0300, Kirill Reshke wrote: >> On Tue, 9 Apr 2024 at 08:53, Michael Paquier wrote: >>> The thing is that you cannot rely on a lookup of the backend type for >>> the error information, or you open

Re: Table AM Interface Enhancements

On Wed, Apr 10, 2024 at 8:20 AM Alexander Korotkov wrote: > I agree with the facts. But I have a different interpretation on > this. The patch was committed as 11470f544e on March 23, 2023, then > reverted on April 3. I've proposed the revised version, but Andres > complained that this is the

Re: Table AM Interface Enhancements

Hi, Alexander! On Wed, 10 Apr 2024 at 16:20, Alexander Korotkov wrote: > On Mon, Apr 8, 2024 at 9:54 PM Robert Haas wrote: > > On Mon, Apr 8, 2024 at 12:33 PM Alexander Korotkov > wrote: > > > Yes, it was my mistake. I got rushing trying to fit this to FF, even > doing significant changes

Re: Transparent column encryption

On Wed, 10 Apr 2024 at 12:13, Peter Eisentraut wrote: > > To kick some things off for PG18, here is an updated version of the > patch for automatic client-side column-level encryption. I only read the docs and none of the code, but here is my feedback on the current design: > (The CEK can't be

Re: Issue with the PRNG used by Postgres

On Tue, Apr 9, 2024 at 5:05 PM Andres Freund wrote: > ISTM that the fix here is to not use a spinlock for whatever the contention is > on, rather than improve the RNG. I'm not convinced that we should try to improve the RNG, but surely we need to put parentheses around

Re: Can't find not null constraint, but \d+ shows that

On Wed, Apr 10, 2024 at 7:01 PM Alvaro Herrera wrote: > > On 2024-Apr-10, jian he wrote: > > > another related bug, in master. > > > > drop table if exists notnull_tbl1; > > CREATE TABLE notnull_tbl1 (c0 int not null, c1 int); > > ALTER TABLE notnull_tbl1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1); > >

Re: Revise some error messages in split partition code

Richard Guo 于2024年4月10日周三 19:32写道： > I noticed some error messages in the split partition code that are not > up to par. Such as: > > "new partitions not have value %s but split partition has" > > how about we revise it to: > > "new partitions do not have value %s but split partition does" > >

Re: Table AM Interface Enhancements

On 4/10/24 09:19, Robert Haas wrote: When you commit a patch and another committer writes a post-commit review saying that your patch has so many serious problems that he gave up on reviewing before enumerating all of them, that's a really bad sign. That should be a strong signal to you to step

Re: Detoasting optionally to make Explain-Analyze less misleading

Matthias van de Meent writes: > Upthread at [0], Stepan mentioned that we should default to SERIALIZE > when ANALYZE is enabled. I suspect a patch in that direction would > primarily contain updates in the test plan outputs, but I've not yet > worked on that. > Does anyone else have a strong

Re: post-freeze damage control

On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote: > I have another one that I'm not terribly happy about: > > Author: Alexander Korotkov > Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300 > > Transform OR clauses to ANY expression I realize that this has been reverted now, but

Re: PostgreSQL 17 Release Management Team & Feature Freeze

On Mon, 8 Apr 2024 at 16:26, Robert Haas wrote: > And maybe we need to think of a way to further mitigate this crush of > last minute commits. e.g. In the last week, you can't have more > feature commits, or more lines of insertions in your commits, than you > did in the prior 3 weeks combined.

Re: Issue with the PRNG used by Postgres

Robert Haas writes: > I'm not convinced that we should try to improve the RNG, but surely we > need to put parentheses around pg_prng_double(_global_prng_state) + > 0.5. IIUC, the current logic is making us multiply the spin delay by a > value between 0 and 1 when what was intended was that it

Re: Issue with the PRNG used by Postgres

Actually ... Parag mentioned that this was specifically about lwlock.c's usage of spinlocks. It doesn't really use a spinlock, but it does use s_lock.c's delay logic, and I think it's got the usage pattern wrong: while (true) { /* always try once to acquire lock directly */

Re: Issue with the PRNG used by Postgres

Yes, the probability of this happening is astronomical, but in production with 128 core servers with 7000 max_connections, with petabyte scale data, this did repro 2 times in the last month. We had to move to a local approach to manager our ratelimiting counters. This is not reproducible very

Re: psql: Greatly speed up "\d tablename" when not using regexes

On Wed, 10 Apr 2024 at 20:21, Kirill Reshke wrote: > Do we need to force Collaction here like in other branches? > if (PQserverVersion(conn) >= 12) >appendPQExpBufferStr(buf, " COLLATE pg_catalog.default"); According to the commit and codecomment that introduced the COLLATE, it was

Re: Table AM Interface Enhancements

On Wed, Apr 10, 2024 at 12:36 PM Alexander Korotkov wrote: > But I have to mention that even that I've committed table AM stuff > close to the FF, there has been quite amount of depended work > committed. So, revert of these patches is promising to be not > something immediate and easy, which

Re: Fix resource leak (src/backend/libpq/be-secure-common.c)

Em ter., 2 de abr. de 2024 às 15:31, Daniel Gustafsson escreveu: > > On 2 Apr 2024, at 20:13, Ranier Vilela wrote: > > > Fix by freeing the pointer, like pclose_check (src/common/exec.c) > similar case. > > Off the cuff, seems reasonable when loglevel is LOG. > Per Coverity. Another case of

Re: psql: Greatly speed up "\d tablename" when not using regexes

On Wed, 10 Apr 2024 at 20:06, Tom Lane wrote: > Really? ISTM this argument is ignoring an optimization the backend > has understood for a long time. Interesting. I didn't know about that optimization. I can't check right now, but probably the COLLATE breaks that optimization.

Re: Table AM Interface Enhancements

On Wed, Apr 10, 2024 at 05:42:51PM +0400, Pavel Borisov wrote: > Hi, Alexander! > In my view, the actual list of what has raised discussion is: > dd1f6b0c17 Provide a way block-level table AMs could re-use > acquire_sample_rows > () > 27bc1772fc Generalize relation analyze in table AM interface >

Re: broken JIT support on Fedora 40

> On Wed, Apr 10, 2024 at 12:43:23PM +1200, Thomas Munro wrote: > On Tue, Apr 9, 2024 at 10:05 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > + /* In assertion builds, run the LLVM verify pass. */ > > +#ifdef USE_ASSERT_CHECKING > > +

Re: ❓ JSON Path Dot Precedence

On Apr 10, 2024, at 10:29, Peter Eisentraut wrote: > So the whole thing is > > > > The syntax of and is then punted to > ECMAScript 5.1. > > 0x2 is a HexIntegerLiteral. (There can be no dots in that.) > > p10 is an Identifier. > > So I think this is all correct. That makes sense,

Re: Issue with the PRNG used by Postgres

hi Robert, We are using xoroshiro128 and not moved to the next state of art. We did see a lot of low values as put in my last message. -Parag On Wed, Apr 10, 2024 at 9:37 AM Robert Haas wrote: > On Wed, Apr 10, 2024 at 12:02 PM Tom Lane wrote: > > As I said to Parag, I see exactly no reason to

Re: Issue with the PRNG used by Postgres

Andres Freund writes: > Hi, > On 2024-04-10 12:28:10 -0400, Tom Lane wrote: >> I don't think it's correct to re-initialize the SpinDelayStatus each >> time around the outer loop. That state should persist through the >> entire acquire operation, as it does in a regular spinlock acquire. >> As

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Hi! Alexander Korotkov, thanks for the commit of previous fix. Alexander Lakhin, thanks for the problem you found. There are two corrections attached to the letter: 1) v1-0001-Fix-for-SPLIT-MERGE-partitions-of-temporary-table.patch - fix for the problem [1]. 2)

Re: Issue with the PRNG used by Postgres

Andres Freund writes: > On 2024-04-10 13:03:05 -0400, Tom Lane wrote: >> So I think we need something like the attached. > LGTM. On third thought ... while I still think this is a misuse of perform_spin_delay and we should change it, I'm not sure it'll do anything to address Parag's problem,

Re: Fix resource leak (src/backend/libpq/be-secure-common.c)

> On 10 Apr 2024, at 20:31, Ranier Vilela wrote: > > Em ter., 2 de abr. de 2024 às 15:31, Daniel Gustafsson > escreveu: >> > On 2 Apr 2024, at 20:13, Ranier Vilela > > > wrote: >> >> > Fix by freeing the pointer, like pclose_check

Re: Issue with the PRNG used by Postgres

Hi, On 2024-04-10 14:02:20 -0400, Tom Lane wrote: > On third thought ... while I still think this is a misuse of > perform_spin_delay and we should change it, I'm not sure it'll do > anything to address Parag's problem, because IIUC he's seeing actual > "stuck spinlock" reports. That implies

Re: Table AM Interface Enhancements

On Wed, Apr 10, 2024 at 4:03 PM Andres Freund wrote: > > Hi, > > On 2024-04-10 15:19:47 +0300, Alexander Korotkov wrote: > > On Mon, Apr 8, 2024 at 9:54 PM Robert Haas wrote: > > > On Mon, Apr 8, 2024 at 12:33 PM Alexander Korotkov > > > wrote: > > > > Yes, it was my mistake. I got rushing

Re: Issue with the PRNG used by Postgres

On Wed, Apr 10, 2024 at 12:02 PM Tom Lane wrote: > As I said to Parag, I see exactly no reason to believe that that's a > problem, unless it happens *a lot*, like hundreds of times in a row. > If it does, that's an RNG problem not s_lock's fault. Now, I'm not > going to say that xoroshiro can't

Re: Issue with the PRNG used by Postgres

On Wed, Apr 10, 2024 at 12:40 PM Parag Paul wrote: > The reason why this could be a problem is a flaw in the RNG with the enlarged > Hamming belt. > I attached an image here, with the RNG outputs from 2 backends. I ran our > code for weeks, and collected ther > values generated by the RNG over

Re: Table AM Interface Enhancements

Hi, On 2024-04-08 14:54:46 -0400, Robert Haas wrote: > Exactly how much is getting reverted here? I see these, all since March 23rd: IMO: > dd1f6b0c17 Provide a way block-level table AMs could re-use > acquire_sample_rows() Should be reverted. > 9bd99f4c26 Custom reloptions for table AM

Re: Issue with the PRNG used by Postgres

I wrote: > I don't think it's correct to re-initialize the SpinDelayStatus each > time around the outer loop. That state should persist through the > entire acquire operation, as it does in a regular spinlock acquire. > As this stands, it resets the delay to minimum each time around the > outer

Re: Issue with the PRNG used by Postgres

Hi, On 2024-04-10 09:48:42 -0700, Parag Paul wrote: > Yes, the probability of this happening is astronomical, but in production > with 128 core servers with 7000 max_connections, with petabyte scale data, > this did repro 2 times in the last month. We had to move to a local > approach to manager

Re: Issue with the PRNG used by Postgres

Parag Paul writes: > Yes, the probability of this happening is astronomical, but in production > with 128 core servers with 7000 max_connections, with petabyte scale data, > this did repro 2 times in the last month. We had to move to a local > approach to manager our ratelimiting counters. > This

Re: Can't find not null constraint, but \d+ shows that

On 2024-Apr-10, Alvaro Herrera wrote: > One thing missing here is pg_dump support. If you just dump this table, > it'll end up with no constraint at all. That's obviously bad, so I > propose we have pg_dump add a regular NOT NULL constraint for those, to > avoid perpetuating the weird situation

Re: Issue with the PRNG used by Postgres

Hi, On 2024-04-10 13:03:05 -0400, Tom Lane wrote: > After thinking about this some more, it is fairly clear that that *is* > a mistake that can cause a thundering-herd problem. > Assume we have two or more backends waiting in perform_spin_delay, and for > whatever reason the scheduler wakes them

Re: psql: Greatly speed up "\d tablename" when not using regexes

Patch looks good to me. Great idea overall, that forced regex has always bugged me. + char *regexChars = "|*+?()[]{}.^$\\"; One super minor optimization is that we technically do not need to scan for ')' and ']'. If they appear without their partner, the query will fail anyway. :)

Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)

Hi, Per Coverity. The function ReorderBufferTXNByXid, can return NULL when the parameter *create* is false. In the functions ReorderBufferSetBaseSnapshot and ReorderBufferXidHasBaseSnapshot, the second call to ReorderBufferTXNByXid, pass false to *create* argument. In the function

Re: Issue with the PRNG used by Postgres

Robert Haas writes: > The blog post to which Parag linked includes this histogram as an > example of a low-Hamming-weight situation: That's an interesting post indeed, but I'm not sure how relevant it is to us, because it is about Xoshiro not Xoroshiro, and the latter is what we use. The last

Re: psql: Greatly speed up "\d tablename" when not using regexes

On Wed, 10 Apr 2024, 23:37 Jelte Fennema-Nio, wrote: > On Wed, 10 Apr 2024 at 20:21, Kirill Reshke > wrote: > > Do we need to force Collaction here like in other branches? > > if (PQserverVersion(conn) >= 12) > >appendPQExpBufferStr(buf, " COLLATE pg_catalog.default"); > > According to

Re: broken JIT support on Fedora 40

st 10. 4. 2024 v 2:44 odesílatel Thomas Munro napsal: > On Tue, Apr 9, 2024 at 10:05 PM Dmitry Dolgov <9erthali...@gmail.com> > wrote: > > + /* In assertion builds, run the LLVM verify pass. */ > > +#ifdef USE_ASSERT_CHECKING > > +

Re: Issue with the PRNG used by Postgres

Andres Freund writes: > On 2024-04-10 16:05:21 -0400, Tom Lane wrote: >> Yeah. So what's the conclusion? Leave it alone? Commit to >> HEAD only? > I think we should certainly fix it. I don't really have an opinion about > backpatching, it's just on the line between the two for me. > Hm. The

Re: Issue with the PRNG used by Postgres

Hi, On 2024-04-10 12:28:10 -0400, Tom Lane wrote: > Actually ... Parag mentioned that this was specifically about > lwlock.c's usage of spinlocks. It doesn't really use a spinlock, > but it does use s_lock.c's delay logic, and I think it's got the > usage pattern wrong: > > while (true) >

Re: Detoasting optionally to make Explain-Analyze less misleading

First of all thanks for bringing this Feature to PostgreSQL. From a regular-user perspective (not everyone is a Pro) it is very misleading that ANALYZE doesn't do what it suggests it does. To run the query into some kind of /dev/null type of destination is feasible and that is what people end up

Re: Table AM Interface Enhancements

On Wed, Apr 10, 2024 at 1:25 PM Robert Haas wrote: > That is somewhat fair, but it is also a lot of work. There are > multiple people asking for you to revert things on multiple threads, > and figuring out all of the revert requests and trying to come to some > consensus about what should be done

Re: psql: Greatly speed up "\d tablename" when not using regexes

Hi > Regex matching is obviously unnecessary when we're looking for an exact > match. This checks for this (common) case and starts using plain > equality in that case. +1 > + appendPQExpBuffer(buf, "(%s OPERATOR(pg_catalog.=) ", namevar); > + appendStringLiteralConn(buf, [2], conn); > +

Re: Issue with the PRNG used by Postgres

Andres Freund writes: > I think it could exascerbate the issue. Parag reported ~7k connections on a > 128 core machine. The buffer replacement logic in < 16 tries to lock the old > and new lock partitions at once. That can lead to quite bad "chains" of > dependent lwlocks, occasionally putting

Re: broken JIT support on Fedora 40

Hi, On 2024-04-10 22:15:27 +0200, Dmitry Dolgov wrote: > > On Wed, Apr 10, 2024 at 12:43:23PM +1200, Thomas Munro wrote: > > On Tue, Apr 9, 2024 at 10:05 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > + /* In assertion builds, run the LLVM verify pass. */ > > >

Re: Issue with the PRNG used by Postgres

Hi, On 2024-04-10 16:05:21 -0400, Tom Lane wrote: > Andres Freund writes: > > I think it could exascerbate the issue. Parag reported ~7k connections on a > > 128 core machine. The buffer replacement logic in < 16 tries to lock the old > > and new lock partitions at once. That can lead to quite

Re: Table AM Interface Enhancements

Hi, On 2024-04-10 16:24:40 -0400, Melanie Plageman wrote: > This thread has been moving pretty fast, so could someone point out > which version of the patch has the modifications to > acquire_sample_rows() that would be relevant for Bilal (and others > involved in analyze streaming read) to

Re: Table AM Interface Enhancements

On Wed, Apr 10, 2024 at 4:19 PM Robert Haas wrote: > > On Wed, Apr 10, 2024 at 8:20 AM Alexander Korotkov > wrote: > > I agree with the facts. But I have a different interpretation on > > this. The patch was committed as 11470f544e on March 23, 2023, then > > reverted on April 3. I've

Re: Improve eviction algorithm in ReorderBuffer

On Wed, 2024-04-10 at 08:30 +0300, Heikki Linnakangas wrote: > My #1 choice would be to write a patch to switch the pairing heap, > performance test that, and revert the binary heap changes. Sounds good to me. I would expect it to perform better than the extra hash table, if anything. It also

Re: psql: Greatly speed up "\d tablename" when not using regexes

Jelte Fennema-Nio writes: > Running "\d tablename" from psql could take multiple seconds when > running on a system with 100k+ tables. The reason for this was that > a sequence scan on pg_class takes place, due to regex matching being > used. > Regex matching is obviously unnecessary when we're

Re: Table AM Interface Enhancements

Hi, On 2024-04-10 15:19:47 +0300, Alexander Korotkov wrote: > On Mon, Apr 8, 2024 at 9:54 PM Robert Haas wrote: > > On Mon, Apr 8, 2024 at 12:33 PM Alexander Korotkov > > wrote: > > > Yes, it was my mistake. I got rushing trying to fit this to FF, even > > > doing significant changes just

Re: psql: Greatly speed up "\d tablename" when not using regexes

Jelte Fennema-Nio writes: > On Wed, 10 Apr 2024 at 20:06, Tom Lane wrote: >> Really? ISTM this argument is ignoring an optimization the backend >> has understood for a long time. > Interesting. I didn't know about that optimization. I can't check > right now, but probably the COLLATE breaks

  1   2   >