Re: SQL:2011 application time

On Fri, Mar 22, 2024 at 8:35 AM Paul Jungwirth wrote: > > Your patch had a lot of other noisy changes, e.g. > whitespace and reordering lines. If there are other things you intended to > add to the tests, can you > describe them? i think on update restrict, on delete restrict cannot be

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

On Thu, Mar 21, 2024 at 7:48 PM John Naylor wrote: > > On Thu, Mar 21, 2024 at 4:03 PM Masahiko Sawada wrote: > > > > I've looked into this idea further. Overall, it looks clean and I > > don't see any problem so far in terms of integration with lazy vacuum. > > I've attached three patches for

Re: Introduce XID age and inactive timeout based replication slot invalidation

On Thu, Mar 21, 2024 at 11:21 PM Bharath Rupireddy wrote: > > > Please find the v14-0001 patch for now. I'll post the other patches soon. > LGTM. Let's wait for Bertrand to see if he has more comments on 0001 and then I'll push it. -- With Regards, Amit Kapila.

Re: Table AM Interface Enhancements

On Fri, 22 Mar 2024 at 08:51, Pavel Borisov wrote: > Hi, Alexander! > > Thank you for working on this patchset and pushing some of these patches! > > I tried to write comments for tts_minimal_is_current_xact_tuple() > and tts_minimal_getsomeattrs() for them to be the same as for the same >

Re: Table AM Interface Enhancements

Hi, Alexander! Thank you for working on this patchset and pushing some of these patches! I tried to write comments for tts_minimal_is_current_xact_tuple() and tts_minimal_getsomeattrs() for them to be the same as for the same functions for heap and virtual tuple slots, as I proposed above in the

Re: remaining sql/json patches

At Fri, 22 Mar 2024 11:44:08 +0900, Amit Langote wrote in > Thanks for the heads up. > > My bad, will push a fix shortly. No problem. Thank you for the prompt correction. regards. -- Kyotaro Horiguchi NTT Open Source Software Center

Re: speed up a logical replica setup

On Fri, Mar 22, 2024 at 9:44 AM Fabrízio de Royes Mello wrote: > > On Fri, Mar 22, 2024 at 12:54 AM Amit Kapila wrote: > > > > > > The user choosing to convert a physical standby to a subscriber would > > in some cases be interested in converting it for all the databases > > (say for the case of

Re: speed up a logical replica setup

On Fri, Mar 22, 2024 at 12:54 AM Amit Kapila wrote: > > > The user choosing to convert a physical standby to a subscriber would > in some cases be interested in converting it for all the databases > (say for the case of upgrade [1]) and giving options for each database > would be cumbersome for

Re: doc issues in event-trigger-matrix.html

On Fri, Mar 22, 2024 at 5:47 AM Peter Eisentraut wrote: > > On 19.03.24 10:34, Daniel Gustafsson wrote: > >>> "Only for local objects" > >>> is there any reference explaining "local objects"? > >>> I think local object means objects that only affect one single database? > > That's a bigger

Re: speed up a logical replica setup

On Thu, Mar 21, 2024 at 8:00 PM Euler Taveira wrote: > > On Thu, Mar 21, 2024, at 10:33 AM, vignesh C wrote: > > If we commit this we might not be able to change the way the option > behaves once the customers starts using it. How about removing these > options in the first version and adding it

Re: speed up a logical replica setup

On Thu, Mar 21, 2024, at 6:49 AM, Shlok Kyal wrote: > There is a compilation error while building postgres with the patch > due to a recent commit. I have attached a top-up patch v32-0003 to > resolve this compilation error. > I have not updated the version of the patch as I have not made any >

Re: remaining sql/json patches

Hi Horiguchi-san, On Fri, Mar 22, 2024 at 9:51 AM Kyotaro Horiguchi wrote: > At Wed, 20 Mar 2024 21:53:52 +0900, Amit Langote > wrote in > > I'll push 0001 tomorrow. > > This patch (v44-0001-Add-SQL-JSON-query-functions.patch) introduced the > following new erro message: > > +

Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs

Nathan Bossart writes: > The Bloom filter appears to help a bit, although it regresses the > create-roles.sql portion of the test. I'm assuming that's thanks to all > the extra pallocs and pfrees, which are probably avoidable if we store the > filter in a long-lived context and just clear it at

Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs

First of all thank you for looking into this. At the moment we workaround the problem by altering `acc` ROLE into a SUPERUSER in PostgreSQL 16 instances. It sidestep the problem and having the lowest cost to implement for us. While at first we think this feels like opening a security hole, it

Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs

On Thu, Mar 21, 2024 at 08:03:32PM -0500, Nathan Bossart wrote: > On Thu, Mar 21, 2024 at 08:59:54PM -0400, Tom Lane wrote: >> However ... I just remembered that we have a Bloom filter implementation >> in core now (src/backend/lib/bloomfilter.c). How about using that >> to quickly reject

Re: Catalog domain not-null constraints

On 3/22/24 01:46, Tom Lane wrote: Vik Fearing writes: Anyway, I will bring this up with the committee and report back. My proposed solution will be for CAST to check domain constraints even if the input is NULL. Please do not claim that that is the position of the Postgres project.

Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs

On Thu, Mar 21, 2024 at 08:59:54PM -0400, Tom Lane wrote: > However ... I just remembered that we have a Bloom filter implementation > in core now (src/backend/lib/bloomfilter.c). How about using that > to quickly reject (hopefully) most role OIDs, and only do the > list_member_oid check if the

Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs

Nathan Bossart writes: > On Thu, Mar 21, 2024 at 03:40:12PM -0500, Nathan Bossart wrote: >> On Thu, Mar 21, 2024 at 04:31:45PM -0400, Tom Lane wrote: >>> I don't think we have any really cheap way to de-duplicate the role >>> OIDs, especially seeing that it has to be done on-the-fly within the

Re: remaining sql/json patches

At Wed, 20 Mar 2024 21:53:52 +0900, Amit Langote wrote in > I'll push 0001 tomorrow. This patch (v44-0001-Add-SQL-JSON-query-functions.patch) introduced the following new erro message: +errmsg("can only specify constant, non-aggregate" +

Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs

On Thu, Mar 21, 2024 at 03:40:12PM -0500, Nathan Bossart wrote: > On Thu, Mar 21, 2024 at 04:31:45PM -0400, Tom Lane wrote: >> I don't think we have any really cheap way to de-duplicate the role >> OIDs, especially seeing that it has to be done on-the-fly within the >> collection loop, and the

Re: Catalog domain not-null constraints

Vik Fearing writes: > On 3/22/24 00:17, Tom Lane wrote: >> Vik Fearing writes: >>> As also said somewhere in that thread, I think that >>> short-cutting a NULL input value without considering the constraints of >>> a domain is a bug that needs to be fixed in the standard. >> I think it's

Re: DRAFT: Pass sk_attno to consistent function

> On 21 Mar 2024, at 23:42, Matthias van de Meent > wrote: > > On Tue, 19 Mar 2024 at 17:00, Michał Kłeczek wrote: > >> With this operator we can write our queries like: >> >> account_number ||= [list of account numbers] AND >> account_number = ANY ([list of account numbers]) — redundant

Re: documentation structure

On Fri, Mar 22, 2024 at 01:12:30AM +0100, Daniel Gustafsson wrote: > > On 22 Mar 2024, at 00:33, Peter Eisentraut wrote: > > > > On 19.03.24 14:50, Tom Lane wrote: > >> Daniel Gustafsson writes: > >>> It's actually not very odd, the reference section is using > >>> elements > >>> and we had

Re: documentation structure

> On 22 Mar 2024, at 00:33, Peter Eisentraut wrote: > > On 19.03.24 14:50, Tom Lane wrote: >> Daniel Gustafsson writes: >>> It's actually not very odd, the reference section is using >>> elements >>> and we had missed the arabic numerals setting on those. The attached fixes >>> that for me.

Re: Flushing large data immediately in pqcomm

Hi, PSA v3. Jelte Fennema-Nio , 21 Mar 2024 Per, 12:58 tarihinde şunu yazdı: > On Thu, 21 Mar 2024 at 01:24, Melih Mutlu wrote: > > What if I do a simple comparison like PqSendStart == PqSendPointer > instead of calling pq_is_send_pending() > > Yeah, that sounds worth trying out. So the new

Re: documentation structure

On 21.03.24 15:31, Robert Haas wrote: On Thu, Mar 21, 2024 at 9:38 AM Tom Lane wrote: I'd follow the extend.sgml precedent: have a file corresponding to the chapter and containing any top-level text we need, then that includes a file per sect1. OK, here's a new patch set. I've revised 0003

Re: Catalog domain not-null constraints

On 3/22/24 00:17, Tom Lane wrote: Vik Fearing writes: On 3/21/24 15:30, Tom Lane wrote: The SQL spec's answer to that conundrum appears to be "NULL is a valid value of every domain, and if you don't like it, tough". I don't see how you can infer this from the standard at all. I believe

Re: documentation structure

On 20.03.24 17:43, Robert Haas wrote: 0001 removes the "Installation from Binaries" chapter. The whole thing is four sentences. I moved the most important information into the "Installation from Source Code" chapter and retitled it "Installation". But this separation was explicitly added a few

Re: documentation structure

On 19.03.24 14:50, Tom Lane wrote: Daniel Gustafsson writes: It's actually not very odd, the reference section is using elements and we had missed the arabic numerals setting on those. The attached fixes that for me. That being said, we've had roman numerals for the reference section since

Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan

On Mon, Mar 18, 2024 at 9:25 AM Matthias van de Meent wrote: > I was thinking about a more unified processing model, where > _bt_preprocess_keys would iterate over all keys, including processing > of array keys (by merging and reduction to normal keys) if and when > found. This would also reduce

Re: Catalog domain not-null constraints

Vik Fearing writes: > On 3/21/24 15:30, Tom Lane wrote: >> The SQL spec's answer to that conundrum appears to be "NULL is >> a valid value of every domain, and if you don't like it, tough". > I don't see how you can infer this from the standard at all. I believe where we got that from is 6.13 ,

Re: Flushing large data immediately in pqcomm

Heikki Linnakangas , 14 Mar 2024 Per, 15:46 tarihinde şunu yazdı: > On 14/03/2024 13:22, Melih Mutlu wrote: > > @@ -1282,14 +1283,32 @@ internal_putbytes(const char *s, size_t len) > > if (internal_flush()) > > return EOF; > > } >

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

On 17.03.24 15:09, Alexander Korotkov wrote: My current attempt was to commit minimal implementation as less invasive as possible. A new clause for BEGIN doesn't require additional keywords and doesn't introduce additional statements. But yes, this is still a new qual. And, yes, Amit you're

Re: documentation structure

On Thu, Mar 21, 2024 at 11:30 AM Robert Haas wrote: > > My second thought is that the stuff from "VII. Internals" that I > categorized as reference material should move into section "VI. > Reference". I think we should also consider moving appendix F, > "Additional Supplied Modules and

Re: Catalog domain not-null constraints

On 3/21/24 15:30, Tom Lane wrote: Peter Eisentraut writes: A quick reading of the SQL standard suggests to me that the way we are doing null handling in domain constraints is all wrong. The standard says that domain constraints are only checked on values that are not null. So both the

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

On 19.03.24 18:38, Kartyshov Ivan wrote: CALL pg_wait_lsn('0/3002AE8', 1); BEGIN; SELECT * FROM tbl; // read fresh insertions COMMIT; I'm not endorsing this or any other approach, but I think the timeout parameter should be of type

Re: DRAFT: Pass sk_attno to consistent function

On Tue, 19 Mar 2024 at 17:00, Michał Kłeczek wrote: > > Hi All, > > Since it looks like there is not much interest in the patch I will try to > provide some background to explain why I think it is needed. > [...] > What we really need is for Gist to support “= ANY (…)”. > As Gist index is

Re: documentation structure

On Wed, Mar 20, 2024 at 9:43 AM Robert Haas wrote: > On Tue, Mar 19, 2024 at 5:39 PM Andrew Dunstan > wrote: > > +many for improving the index. > > Here's a series of four patches. I reviewed the most recent set of 5 patches. > Taken together, they cut down the > number of numbered chapters

Re: [PATCH] ltree hash functions

jian he writes: > I also made the following changes: > from > uint64 levelHash = hash_any_extended((unsigned char *) al->name, al->len, > seed); > uint32 levelHash = hash_any((unsigned char *) al->name, al->len); > to > uint64 levelHash = DatumGetUInt64(hash_any_extended((unsigned char *) >

Re: Adding comments to help understand psql hidden queries

On 21.03.24 18:31, David Christensen wrote: Thanks for the feedback. Enclosed is a v2 of this series(?) rebased and with that warning fixed; @Greg Sabino Mullane I just created a commit on your behalf with the message to hackers. I'm also creating a commit-fest entry for this thread. I don't

Re: doc issues in event-trigger-matrix.html

> On 21 Mar 2024, at 22:47, Peter Eisentraut wrote: > > On 19.03.24 10:34, Daniel Gustafsson wrote: "Only for local objects" is there any reference explaining "local objects"? I think local object means objects that only affect one single database? >> That's a bigger problem than

Re: Refactoring of pg_resetwal/t/001_basic.pl

On 21.03.24 17:58, Maxim Orlov wrote: In commit 7b5275eec more tests and test coverage were added into pg_resetwal/t/001_basic.pl . All the added stuff are pretty useful in my view.  Unfortunately, there were some magic constants been used.  In overall, this is not a

Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan

On Thu, Mar 7, 2024 at 10:42 AM Benoit Tigeot wrote: > I am not up to date with the last version of patch but I did a regular > benchmark with version 11 and typical issue we have at the moment and the > result are still very very good. [1] Thanks for providing the test case. It was definitely

Re: Partial aggregates pushdown

On Thu, Mar 21, 2024 at 11:37:50AM +, fujii.y...@df.mitsubishielectric.co.jp wrote: > Hi. Mr.Momjian, Mr.Lane, Mr.Haas, hackers. > > I apologize for any misunderstanding regarding the context of the attached > patch and > the points on which I requested a review. Could you please allow me

Re: doc issues in event-trigger-matrix.html

On 19.03.24 10:34, Daniel Gustafsson wrote: "Only for local objects" is there any reference explaining "local objects"? I think local object means objects that only affect one single database? That's a bigger problem than the table representation, we never define what "local object" mean

Re: Bytea PL/Perl transform

Alexander Korotkov writes: > On Tue, Jan 30, 2024 at 8:46 PM Pavel Stehule wrote: >> I marked this patch as ready for committer. > The last version of the patch still provides transform for builtin > type in a separate extension. As discussed upthread such transforms > don't need separate

Re: Avoiding inadvertent debugging mode for pgbench

On Wed, Mar 20, 2024 at 11:57:25AM -0400, Greg Sabino Mullane wrote: > My mistake. Attached please find version 3, which should hopefully make > cfbot happy again. Here is what I have staged for commit. I plan to commit this within the next few days. -- Nathan Bossart Amazon Web Services:

Re: Building with meson on NixOS/nixpkgs

Nazir Bilal Yavuz: 0001 & 0002: Adding code comments to explain why they have fallback could be nice. 0003: Looks good to me. Added some comments in the attached. Best, WolfgangFrom 2d271aafd96a0ea21710a06ac5236e47217c36d1 Mon Sep 17 00:00:00 2001 From: Wolfgang Walther Date: Sat, 2 Mar

Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs

On Thu, Mar 21, 2024 at 04:31:45PM -0400, Tom Lane wrote: > I wrote: >> ... I still see the problematic GRANT taking ~250ms, compared >> to 5ms in v15. roles_is_member_of is clearly on the hook for that. > > Ah: looks like that is mainly the fault of the list_append_unique_oid > calls in

Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs

I wrote: > ... I still see the problematic GRANT taking ~250ms, compared > to 5ms in v15. roles_is_member_of is clearly on the hook for that. Ah: looks like that is mainly the fault of the list_append_unique_oid calls in roles_is_member_of. That's also an O(N^2) cost of course, though with a

Re: Avoiding inadvertent debugging mode for pgbench

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed Did a quick review of this one; CFbot is now happy, local

Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs

I wrote: > It looks like part of the blame might be ascribable to catcache.c, > as if you look at the problem microscopically you find that > roles_is_member_of is causing catcache to make a ton of AUTHMEMMEMROLE > catcache lists, and SearchSysCacheList is just iterating linearly > through the

Re: Statistics Import and Export

> > > > But ideally we'd just make it safe to dump and reload stats on your own > tables, and then not worry about it. > That is my strong preference, yes. > > > Not off hand, no. > > To me it seems like inconsistent data to have most_common_freqs in > anything but descending order, and we

Re: Statistics Import and Export

On Thu, 2024-03-21 at 15:10 -0400, Corey Huinker wrote: > > In which case wouldn't the checkCanModify on pg_statistic would be a > proxy for is_superuser/has_special_role_we_havent_created_yet. So if someone pg_dumps their table and gets the statistics in the SQL, then they will get errors

RE: Popcount optimization using AVX512

> -Original Message- > From: David Rowley > Sent: Wednesday, March 20, 2024 5:28 PM > To: Amonson, Paul D > Cc: Nathan Bossart ; Andres Freund > > I'm not sure about this "extern negates inline" comment. It seems to me the > compiler is perfectly free to inline a static function into an

Re: Statistics Import and Export

> > How about just some defaults then? Many of them have a reasonable > default, like NULL or an empty array. Some are parallel arrays and > either both should be specified or neither (e.g. > most_common_vals+most_common_freqs), but you can check for that. > +1 Default NULL has been implemented

Re: Comments on Custom RMGRs

On Thu, 2024-03-21 at 19:47 +0700, Danil Anisimow wrote: > The proposed patch is not a complete solution for pgss and may not > work correctly with replication. Also, what is the desired behavior during replication? Should queries on the primary be represented in pgss on the replica? If the

Re: Comments on Custom RMGRs

On Thu, 2024-03-21 at 19:47 +0700, Danil Anisimow wrote: > [pgss_001.v1.patch] adds a custom resource manager to the > pg_stat_statements extension. Did you consider moving the logic for loading the initial contents from disk from pgss_shmem_startup to .rmgr_startup? > The rm_checkpoint hook

Re: Refactor SASL exchange in preparation for OAuth Bearer

> On 20 Mar 2024, at 15:28, Daniel Gustafsson wrote: > >> On 29 Feb 2024, at 20:58, Jacob Champion >> wrote: >> >> On Wed, Feb 28, 2024 at 2:54 PM Daniel Gustafsson wrote: >>> I rank that as one of my better typos actually. Fixed though. >> >> LGTM! > > Thanks for review, and since Heikki

Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs

Tom Lane: Actually, roles_is_member_of sucks before v16 too; the new thing is only that it's being invoked during GRANT ROLE. Using the roles created by the given test case, I see in v15: [...] So it takes ~3.5s to populate the roles_is_member_of cache for "acc" given this membership set.

Re: An improved README experience for PostgreSQL

On Thu, Mar 21, 2024 at 10:24:12AM -0700, Andres Freund wrote: > I was out while this was proposed and committed. Just wanted to say: Thanks! > It was high time that we added this... Definitely. I hope we are able to build on this in the near future. -- Nathan Bossart Amazon Web Services:

Re: add AVX2 support to simd.h

On Thu, Mar 21, 2024 at 12:09:44PM -0500, Nathan Bossart wrote: > On Thu, Mar 21, 2024 at 11:30:30AM +0700, John Naylor wrote: >> Further, now that the algorithm is more SIMD-appropriate, I wonder >> what doing 4 registers at a time is actually buying us for either SSE2 >> or AVX2. It might just

Re: documentation structure

On Thu, Mar 21, 2024 at 12:43 PM Alvaro Herrera wrote: > which is a bit odd: why are the two WAL chapters in the middle of the > chapters 62 and 63 talking about AMs? Maybe put 66 right after 63 > instead.Also, is it really better to have 62/63 first and 66 > later? It sounds to me like 66

Re: broken JIT support on Fedora 40

> On Sun, Mar 17, 2024 at 09:02:08PM +0100, Dmitry Dolgov wrote: > > On Fri, Mar 15, 2024 at 01:54:38PM +1300, Thomas Munro wrote: > > For me it seems that the LLVMRunPasses() call, new in > > > > commit 76200e5ee469e4a9db5f9514b9d0c6a31b496bff > > Author: Thomas Munro > > Date: Wed Oct 18

Re: Adding comments to help understand psql hidden queries

Created the CF entry in commitfest 48 but didn't see it was already in 47; closing the CFEntry in 48. (Doesn't appear to be a different status than "Withdrawn"...)

Re: Improve WALRead() to suck data directly from WAL buffers when possible

On Tue, Feb 20, 2024 at 11:40 AM Bharath Rupireddy wrote: > > Ran pgperltidy on the new TAP test file added. Please see the attached > v25 patch set. Please find the v26 patches after rebasing. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services:

Re: Introduce XID age and inactive timeout based replication slot invalidation

On Thu, Mar 21, 2024 at 4:25 PM Amit Kapila wrote: > > This makes sense to me. Apart from this, few more comments on 0001. Thanks for looking into it. > 1. > - "%s as caught_up, conflict_reason IS NOT NULL as invalid " > + "%s as caught_up, invalidation_reason IS NOT NULL as invalid " >

Re: Catalog domain not-null constraints

On Thu, 21 Mar 2024 at 10:30, Tom Lane wrote: > The SQL spec's answer to that conundrum appears to be "NULL is > a valid value of every domain, and if you don't like it, tough". > To be fair, NULL is a valid value of every type. Even VOID has NULL. In this context, it’s a bit weird to be able

Re: Statistics Import and Export

On Thu, 2024-03-21 at 03:27 -0400, Corey Huinker wrote: > > They can, but part of what I wanted to show was that the values that > aren't directly passed in as parameters (staopN, stacollN) get set to > the correct values, and those values aren't guaranteed to match > across databases, hence

Re: Adding comments to help understand psql hidden queries

Hi Jim, Thanks for the feedback. Enclosed is a v2 of this series(?) rebased and with that warning fixed; @Greg Sabino Mullane I just created a commit on your behalf with the message to hackers. I'm also creating a commit-fest entry for this thread. Best, David

Re: An improved README experience for PostgreSQL

On 2024-02-28 14:59:16 -0600, Nathan Bossart wrote: > On Wed, Feb 28, 2024 at 02:21:49PM -0600, Nathan Bossart wrote: > > On Wed, Feb 28, 2024 at 02:07:34PM -0600, Andrew Atkinson wrote: > >> I agree that starting with the direct conversion is reasonable. Markdown > >> "modernizes" the file using

Re: Trying to build x86 version on windows using meson

Andres, On Thu, 21 Mar 2024 at 12:51, Andres Freund wrote: > Hi, > > On 2024-03-21 07:11:23 -0400, Dave Cramer wrote: > > It seems that attempting to cross-compile on an ARM machine might be > asking > > too much as the use cases are pretty limited. > > It for sure is if you don't even provide

Re: add AVX2 support to simd.h

On Thu, Mar 21, 2024 at 12:09:44PM -0500, Nathan Bossart wrote: > It does still eventually win, although not nearly to the same extent as > before. I extended the benchmark a bit to show this. I wouldn't be > devastated if we only got 0001 committed for v17, given these results. (In case it

Re: add AVX2 support to simd.h

On Thu, Mar 21, 2024 at 11:30:30AM +0700, John Naylor wrote: > I'm much happier about v5-0001. With a small tweak it would match what > I had in mind: > > + if (nelem < nelem_per_iteration) > + goto one_by_one; > > If this were "<=" then the for long arrays we could assume there is > always more

Re: [DOCS] HOT - correct claim about indexes not referencing old line pointers

On Thu, Mar 14, 2024 at 9:07 PM James Coleman wrote: > If the goal here is the most minimal patch possible, then please > commit what you proposed. I am interested in improving the document > further, but I don't know how to do that easily if the requirement is > effectively "must only change one

Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs

I wrote: > I poked into this a bit. It seems the problem is that as of v16, we > try to search for the "best" role membership path from the current > user to the target role, and that's done in a very brute-force way, > as a side effect of computing the set of *all* role memberships the > current

Refactoring of pg_resetwal/t/001_basic.pl

Hi! In commit 7b5275eec more tests and test coverage were added into pg_resetwal/t/001_basic.pl. All the added stuff are pretty useful in my view. Unfortunately, there were some magic constants been used. In overall, this is not a problem. But while working on 64 bit XIDs I've noticed these

Re: Trying to build x86 version on windows using meson

Hi, On 2024-03-21 07:11:23 -0400, Dave Cramer wrote: > It seems that attempting to cross-compile on an ARM machine might be asking > too much as the use cases are pretty limited. It for sure is if you don't even provide the precise commands and logs of a failed run... > So the impetus for this

Re: documentation structure

On 2024-Mar-21, Robert Haas wrote: > On Thu, Mar 21, 2024 at 9:38 AM Tom Lane wrote: > > I'd follow the extend.sgml precedent: have a file corresponding to the > > chapter and containing any top-level text we need, then that includes > > a file per sect1. > > OK, here's a new patch set. I've

Re: AIX support

Thanks, Tom and Alvaro, for the info. We shall look into to details and get back. From: Tom Lane Date: Thursday, 21 March 2024 at 7:27 PM To: Sriram RK Cc: pgsql-hack...@postgresql.org Subject: Re: AIX support Sriram RK writes: > We are working on AIX systems and noticed that the thread on

Re: documentation structure

On Thu, Mar 21, 2024 at 10:31 AM Robert Haas wrote: > 0001 and 0002 are changed. Should 0002 use the include-an-entity > approach as well? Woops. I meant to say that 0001 and 0002 are *unchanged*. -- Robert Haas EDB: http://www.enterprisedb.com

Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

On Mar 21, 2024, at 13:07, Alvaro Herrera wrote: > Given that Michaël is temporarily gone, I propose to push the attached > tomorrow. Thanks for doing so. I’m wondering whether I should be an author of this patch at this stage, tbh. I wrote all the tests and rewrote most of the internals to

Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal

> On 21 Mar 2024, at 18:54, Peter Geoghegan wrote: > Do the posting lists that are corrupt > (reported on elsewhere) also have duplicate TIDs? I do not have access now, but AFAIR yes. Thanks for pointers! BTW there were also some errors in logs like ERROR: index "tablename" contains

Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs

[ redirecting to -hackers ] alex work writes: > We encounter slow `GRANT ROLES` only on PostgreSQL 16 instances up to 42 > seconds > in production, the client process at PostgresSQL would use 100% of the CPU. > Which is a surprise compared to other instances running older PostgreSQL > releases.

Re: Possibility to disable `ALTER SYSTEM`

On Wed, Mar 20, 2024 at 10:31 PM Magnus Hagander wrote: > > On Wed, Mar 20, 2024 at 8:52 PM Robert Haas wrote: >> >> On Wed, Mar 20, 2024 at 3:17 PM Magnus Hagander wrote: >> > Right, what I meant is that making it a packaging decision is the better >> > place. Wherever it goes, allowing the

Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal

On Thu, 21 Mar 2024 at 07:17, Andrey M. Borodin wrote: > > > On 29 Jun 2022, at 17:43, Robins Tharakan wrote: > > Sorry to bump ancient thread, I have some observations that might or might > not be relevant. > Recently we noticed a corruption on one of clusters. The corruption at hand > is not

Re: UUID v7

On Wed, 20 Mar 2024 at 19:08, Andrey M. Borodin wrote: > Timer-based bits contribute to global sortability. But the real timers we > have are not even millisecond adjusted. We can hope for ~few ms variation in > one datacenter or in presence of atomic clocks. I think the main benefit of using

Re: An improved README experience for PostgreSQL

On Thu, Mar 21, 2024 at 03:24:17PM +0100, Daniel Gustafsson wrote: >> On 21 Mar 2024, at 15:11, Nathan Bossart wrote: >> I added that to maintain the line break that was in the non-Markdown >> version. I'd rather match the style of the following paragraph (patch >> attached) than mess with

Re: SQL:2011 application time

On 20.03.24 17:21, Paul Jungwirth wrote: On 3/20/24 03:55, jian he wrote: hi. minor cosmetic issues, other than that, looks good. *pk_period = (indexStruct->indisexclusion); to *pk_period = indexStruct->indisexclusion; ... > if (with_period && !fkconstraint->fk_with_period) ereport(ERROR,

Re: Support a wildcard in backtrace_functions

On Wed, 13 Mar 2024 at 16:32, Jelte Fennema-Nio wrote: > How > about the following aproach. It still uses 3 GUCs, but they now all > work together. There's one entry point and two additional filters > (level and function name) > > # Says what log entries to log backtraces for > log_backtrace =

Re: documentation structure

On Thu, Mar 21, 2024 at 9:38 AM Tom Lane wrote: > I'd follow the extend.sgml precedent: have a file corresponding to the > chapter and containing any top-level text we need, then that includes > a file per sect1. OK, here's a new patch set. I've revised 0003 and 0004 to use this approach, and

Re: speed up a logical replica setup

On Thu, Mar 21, 2024, at 10:33 AM, vignesh C wrote: > If we commit this we might not be able to change the way the option > behaves once the customers starts using it. How about removing these > options in the first version and adding it in the next version after > more discussion. We don't need

Re: Catalog domain not-null constraints

Peter Eisentraut writes: > > A quick reading of the SQL standard suggests to me that the way we are > doing null handling in domain constraints is all wrong. The standard > says that domain constraints are only checked on values that are not > null. So both the handling of constraints using

Re: An improved README experience for PostgreSQL

> On 21 Mar 2024, at 15:11, Nathan Bossart wrote: > > On Thu, Mar 21, 2024 at 02:42:27PM +0100, Peter Eisentraut wrote: >> The committed README.md contains trailing whitespace on one line: >> >> General documentation about this version of PostgreSQL can be found at:$ >>

Re: An improved README experience for PostgreSQL

On Thu, Mar 21, 2024 at 02:42:27PM +0100, Peter Eisentraut wrote: > The committed README.md contains trailing whitespace on one line: > > General documentation about this version of PostgreSQL can be found at:$ > -https://www.postgresql.org/docs/devel/$ >

Re: AIX support

Sriram RK writes: > We are working on AIX systems and noticed that the thread on removing AIX > support in Postgres going forward. > https://github.com/postgres/postgres/commit/0b16bb8776bb834eb1ef8204ca95dd7667ab948b > We would be glad to understand any outstanding issues hindering the >

Re: AIX support

On 2024-Mar-21, Sriram RK wrote: > Hello Team, > > We are working on AIX systems and noticed that the thread on removing AIX > support in Postgres going forward. > > https://github.com/postgres/postgres/commit/0b16bb8776bb834eb1ef8204ca95dd7667ab948b” > > We would be glad to understand any

Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal

On Thu, Mar 21, 2024 at 2:16 AM Andrey M. Borodin wrote: > Most of these messages look similar, except last one: “cross page item order > invariant violated for index”. Indeed, index scans were hanging in a cycle. > I could not locate problem in WAL yet, because a lot of other stuff is going >

Re: An improved README experience for PostgreSQL

On Wed, Feb 28, 2024 at 11:55 AM David E. Wheeler wrote: > > IME the keys to decent-looking Markdown are: > > 1. Wrapping lines to a legible width (76-80 chars) > 2. Link references rather than inline links +1 on Markdown including David's suggestions above. Agree that without proper

Re: An improved README experience for PostgreSQL

On 28.02.24 20:30, Nathan Bossart wrote: On Wed, Feb 28, 2024 at 01:08:03PM -0600, Nathan Bossart wrote: -PostgreSQL Database Management System -= +# PostgreSQL Database Management System This change can be omitted, which makes the conversion even simpler.

  1   2   >