Re: Proposal for CREATE OR REPLACE EVENT TRIGGER in PostgreSQL

On Friday, May 3, 2024, Peter Burbery wrote: > Dear pgsql-hackers, > > One-line Summary: > Proposal to introduce the CREATE OR REPLACE syntax for EVENT TRIGGER in > PostgreSQL. > > Business Use-case: > Currently, to modify an EVENT TRIGGER, one must drop and recreate it. This > proposal aims to

Re: Use generation memory context for tuplestore.c

On Sat, 4 May 2024 at 03:51, Matthias van de Meent wrote: > Was a bump context considered? If so, why didn't it make the cut? > If tuplestore_trim is the only reason why the type of context in patch > 2 is a generation context, then couldn't we make the type of context > conditional on

Proposal for CREATE OR REPLACE EVENT TRIGGER in PostgreSQL

Dear pgsql-hackers, One-line Summary: Proposal to introduce the CREATE OR REPLACE syntax for EVENT TRIGGER in PostgreSQL. Business Use-case: Currently, to modify an EVENT TRIGGER, one must drop and recreate it. This proposal aims to introduce a CREATE OR REPLACE syntax for EVENT TRIGGER, similar

Re: Support tid range scan in parallel?

On Sat, 4 May 2024 at 06:55, Cary Huang wrote: > With syncscan enabled, the "table_block_parallelscan_nextpage()" would > return the next block since the end of the first tid rangescan instead of the > correct start block that should be scanned. I see that single tid rangescan > does not have

Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation

On 5/3/24 11:44, Peter Eisentraut wrote: On 03.05.24 16:13, Tom Lane wrote: Peter Eisentraut writes: On 30.04.24 19:29, Tom Lane wrote: Also, the bigger picture here is the seeming assumption that "if we change pg_trgm then it will be safe to replicate from x86 to arm".  I don't believe that

Re: wrong comment in libpq.h

On 2024-05-03 4:53 a.m., Daniel Gustafsson wrote: On 3 May 2024, at 13:48, Peter Eisentraut wrote: Maybe it's easier if we just replaced prototypes for functions in xxx.c with declarations for xxx.c throughout src/include/libpq/libpq.h. +1 +1 -- Daniel Gustafsson David

Re: pg_sequence_last_value() for unlogged sequences on standbys

Nathan Bossart writes: > On Wed, May 01, 2024 at 12:39:53PM +0900, Michael Paquier wrote: >> However, it seems to me that you should also drop the >> pg_is_other_temp_schema() in system_views.sql for the definition of >> pg_sequences. Doing that on HEAD now would be OK, but there's nothing >>

Re: pg_sequence_last_value() for unlogged sequences on standbys

On Wed, May 01, 2024 at 12:39:53PM +0900, Michael Paquier wrote: > However, it seems to me that you should also drop the > pg_is_other_temp_schema() in system_views.sql for the definition of > pg_sequences. Doing that on HEAD now would be OK, but there's nothing > urgent to it so it may be better

Re: On disable_cost

On Sat, Nov 2, 2019 at 10:57 AM Tom Lane wrote: > The idea that I've been thinking about is to not generate disabled > Paths in the first place, thus not only fixing the problem but saving > some cycles. While this seems easy enough for "optional" paths, > we have to reserve the ability to

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

Peter Eisentraut writes: > On 03.05.24 10:39, Daniel Gustafsson wrote: >> They are no-ops when linking against v18, but writing an extension which >> targets all supported versions of postgres along with their respective >> supported OpenSSL versions make them still required, or am I missing >>

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

On 03.05.24 10:39, Daniel Gustafsson wrote: I would recommend to update the documentation of PQinitSSL and PQinitOpenSSL to tell that these become useless and are deprecated. They are no-ops when linking against v18, but writing an extension which targets all supported versions of postgres

Re: Support LIKE with nondeterministic collations

On 03.05.24 17:47, Daniel Verite wrote: Peter Eisentraut wrote: However, off the top of my head, this definition has three flaws: (1) It would make the single-character wildcard effectively an any-number-of-characters wildcard, but only in some circumstances, which could be

Re: Support tid range scan in parallel?

Hello > -- parallel plan > postgres=# set max_parallel_workers_per_gather=2; > SET > postgres=# select count(*) from t where ctid >= '(0,0)' and ctid < '(10,0)'; > count > --- > 0 > (1 row) > > I've not really looked into why, but I see you're not calling > heap_setscanlimits() in

Re: Support LIKE with nondeterministic collations

On 03.05.24 16:58, Daniel Verite wrote: * Generating bounds for a sort key (prefix matching) Having sort keys for strings allows for easy creation of bounds - sort keys that are guaranteed to be smaller or larger than any sort key from a give range. For example, if bounds are

Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation

On 03.05.24 16:13, Tom Lane wrote: Peter Eisentraut writes: On 30.04.24 19:29, Tom Lane wrote: Also, the bigger picture here is the seeming assumption that "if we change pg_trgm then it will be safe to replicate from x86 to arm". I don't believe that that's a good idea and I'm unwilling to

First-draft release notes for back branches are done

See https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7155cc4a60e7bfc837233b2dea2563a2edc673fd As usual, please send any corrections by Sunday. regards, tom lane

Re: Add minimal C example and SQL registration example for custom table access methods.

Thanks Robert for mentioning this! I indeed did not notice the switch. > Nitpicking a little: your patch appears to change more lines than it does, > because it added line breaks earlier in the lines. I would generally avoid > that unless there's good reason to do so. Thanks! I'm not sure why

add --no-sync to pg_upgrade's calls to pg_dump and pg_dumpall

This is likely small potatoes compared to some of the other pg_upgrade-related improvements I've proposed [0] [1] or plan to propose, but this is easy enough, and I already wrote the patch, so here it is. AFAICT there's no reason to bother syncing these dump files to disk. If someone pulls the

Re: Document NULL

On Fri, May 3, 2024 at 8:44 AM Tom Lane wrote: > "David G. Johnston" writes: > > On Fri, May 3, 2024 at 7:10 AM Peter Eisentraut > > wrote: > >> On 02.05.24 17:23, David G. Johnston wrote: > >>> I chose to add a new sect1 in the user guide (The SQL Language) > chapter, > >>> "Data". > > >>

Re: Use generation memory context for tuplestore.c

On Fri, 3 May 2024 at 15:55, David Rowley wrote: > > (40af10b57 did this for tuplesort.c, this is the same, but for tuplestore.c) > > I was looking at the tuplestore.c code a few days ago and noticed that > it allocates tuples in the memory context that tuplestore_begin_heap() > is called in,

Re: Support LIKE with nondeterministic collations

Peter Eisentraut wrote: > However, off the top of my head, this definition has three flaws: (1) > It would make the single-character wildcard effectively an > any-number-of-characters wildcard, but only in some circumstances, which > could be confusing, (2) it would be difficult to

Re: Document NULL

"David G. Johnston" writes: > On Fri, May 3, 2024 at 7:10 AM Peter Eisentraut > wrote: >> On 02.05.24 17:23, David G. Johnston wrote: >>> I chose to add a new sect1 in the user guide (The SQL Language) chapter, >>> "Data". >> Please, let's not. > If a committer wants to state the single place

Re: Document NULL

On Fri, May 3, 2024 at 7:10 AM Peter Eisentraut wrote: > On 02.05.24 17:23, David G. Johnston wrote: > > Version 2 attached. Still a draft, focused on topic picking and overall > > structure. Examples and links planned plus the usual semantic markup > stuff. > > > > I chose to add a new sect1

Re: Tarball builds in the new world order

Peter Eisentraut writes: > On 29.04.24 18:14, Tom Lane wrote: >> OK. After poking at that for awhile, it seemed like "default to >> HEAD" fits into meson a lot better than "throw an error if the >> variable isn't set", so I switched to doing it like that. > This patch looks good to me. Pushed,

Re: Support LIKE with nondeterministic collations

Peter Eisentraut wrote: > Yes, certainly, and there is also no indexing support (other than for > exact matches). The ICU docs have this note about prefix matching: https://unicode-org.github.io/icu/userguide/collation/architecture.html#generating-bounds-for-a-sort-key-prefix-matching

Re: Typos in the code and README

On Fri, 3 May 2024 at 00:00, Alexander Lakhin wrote: > (some of them are located in doc/, so it's not a code-only change) > I've attached the patch for your convenience, though maybe some > of the suggestions are to be discarded. Thanks. I was hoping you'd do that. I pushed the patch after only

Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation

Peter Eisentraut writes: > On 30.04.24 19:29, Tom Lane wrote: >> Also, the bigger picture here is the seeming assumption that "if >> we change pg_trgm then it will be safe to replicate from x86 to >> arm". I don't believe that that's a good idea and I'm unwilling >> to promise that it will work,

Re: Support LIKE with nondeterministic collations

On 03.05.24 15:20, Robert Haas wrote: On Fri, May 3, 2024 at 4:52 AM Peter Eisentraut wrote: What the implementation does is, it walks through the pattern. It sees '_', so it steps over one character in the input string, which is '.' here. Then we have 'foo.' left to match in the input

Re: Document NULL

On 02.05.24 17:23, David G. Johnston wrote: Version 2 attached.  Still a draft, focused on topic picking and overall structure.  Examples and links planned plus the usual semantic markup stuff. I chose to add a new sect1 in the user guide (The SQL Language) chapter, "Data". Please, let's

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

On Fri, May 3, 2024 at 4:54 AM Peter Eisentraut wrote: > > On 30.04.24 19:39, Jacob Champion wrote: > > Tangentially: Should we maybe rethink pieces of the json_lex_string > > error handling? For example, do we really want to echo an incomplete > > multibyte sequence once we know it's bad? > > I

Re: pg17 issues with not-null contraints

On another thread [0], Alexander Lakhin pointed out, indirectly, that partitions created using LIKE+ATTACH now have different not-null constraints from partitions created using PARTITION OF. postgres=# CREATE TABLE t (i int PRIMARY KEY) PARTITION BY RANGE (i); postgres=# CREATE TABLE t1 PARTITION

Re: Document NULL

On Fri, May 3, 2024 at 1:14 AM jian he wrote: > On Fri, May 3, 2024 at 2:47 PM Laurenz Albe > wrote: > > > > On Thu, 2024-05-02 at 08:23 -0700, David G. Johnston wrote: > > > Version 2 attached. Still a draft, focused on topic picking and > overall structure. > > > > I'm fine with most of the

Re: Tarball builds in the new world order

On 29.04.24 18:14, Tom Lane wrote: Peter Eisentraut writes: On 26.04.24 21:24, Tom Lane wrote: Concretely, I'm proposing the attached. Peter didn't like PG_COMMIT_HASH, so I have PG_COMMIT_REFSPEC below, but I'm not wedded to that if a better name is proposed. This seems ok to me, but

Use generation memory context for tuplestore.c

(40af10b57 did this for tuplesort.c, this is the same, but for tuplestore.c) I was looking at the tuplestore.c code a few days ago and noticed that it allocates tuples in the memory context that tuplestore_begin_heap() is called in, which for nodeMaterial.c, is ExecutorState. I didn't think this

Re: Removing unneeded self joins

On Fri, May 3, 2024 at 4:57 AM Alexander Korotkov wrote: > I agree to revert it for v17, but I'm not exactly sure the issue is > design (nevertheless design review is very welcome as any other type > of review). The experience of the bugs arising with the SJE doesn't > show me a particular weak

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Fri, May 3, 2024 at 4:23 PM Justin Pryzby wrote: > On Wed, May 01, 2024 at 10:51:24PM +0300, Dmitry Koval wrote: > > 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

Re: A problem about partitionwise join

On Fri, May 3, 2024 at 7:47 AM Richard Guo wrote: >> Does the additional logic added by this patch have a noticeable >> performance cost? > > I think one concern regarding performance cost is that the function > exprs_known_equal() would be called O(N^2) times, where N is the number > of

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Wed, May 01, 2024 at 10:51:24PM +0300, Dmitry Koval wrote: > 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]

Re: Support LIKE with nondeterministic collations

On Fri, May 3, 2024 at 4:52 AM Peter Eisentraut wrote: > What the implementation does is, it walks through the pattern. It sees > '_', so it steps over one character in the input string, which is '.' > here. Then we have 'foo.' left to match in the input string. Then it > takes from the

Re: allow changing autovacuum_max_workers without restarting

> That's true, but using a hard-coded limit means we no longer need to add a > new GUC. Always allocating, say, 256 slots might require a few additional > kilobytes of shared memory, most of which will go unused, but that seems > unlikely to be a problem for the systems that will run Postgres v18.

Re: Reducing the log spam

On Thu, 2024-05-02 at 13:11 +0200, Jelte Fennema-Nio wrote: > 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

Re: A failure in prepared_xacts test

On 29.04.24 07:11, Tom Lane wrote: Up to now, we've only worried about whether tests running in parallel within a single test suite can interact. It's quite scary to think that the meson setup has expanded the possibility of interactions to our entire source tree. Maybe that was a bad idea and

Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation

On 30.04.24 19:29, Tom Lane wrote: 1) Assume that char signedness is somehow a property of bits-on-disk even though it's weird. Then pg_trgm indexes are correct, but we need to store char signedness in pg_control. 2) Assume that char signedness is not a property of bits-on-disk. Then pg_trgm

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

On 30.04.24 19:39, Jacob Champion wrote: Tangentially: Should we maybe rethink pieces of the json_lex_string error handling? For example, do we really want to echo an incomplete multibyte sequence once we know it's bad? I can't quite find the place you might be looking at in

Re: wrong comment in libpq.h

> On 3 May 2024, at 13:48, Peter Eisentraut wrote: > Maybe it's easier if we just replaced > >prototypes for functions in xxx.c > > with > >declarations for xxx.c > > throughout src/include/libpq/libpq.h. +1 -- Daniel Gustafsson

Re: wrong comment in libpq.h

On 03.05.24 00:37, David Zhang wrote: 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

Re: A problem about partitionwise join

On Wed, May 1, 2024 at 1:31 AM Robert Haas wrote: > I think it's slightly questionable whether this patch is worthwhile. > The case memorialized in the regression tests, t1.a = t2.a AND t1.a = > t2.b, is a very weird thing to do. The case mentioned in the original > email, foo.k1 = bar.k1 and

Re: tablecmds.c/MergeAttributes() cleanup

On Fri, May 3, 2024 at 2:47 PM Peter Eisentraut wrote: > On 30.04.24 21:48, Robert Haas wrote: > > I took a look at this patch. Currently this case crashes: > > > > CREATE TABLE cmdata(f1 text COMPRESSION pglz); > > CREATE TABLE cmdata3(f1 text); > > CREATE TABLE cminh() INHERITS (cmdata,

Re: different engine for JIT

On 5/3/24 10:07 AM, Pavel Stehule wrote: Hi I found https://github.com/vnmakarov/mir?tab=readme-ov-file It should be significantly faster than llvm (compilation). Regards Pavel Hello, I can't tell about JIT, it is too complicated for

Re: tablecmds.c/MergeAttributes() cleanup

On 30.04.24 21:48, Robert Haas wrote: I took a look at this patch. Currently this case crashes: CREATE TABLE cmdata(f1 text COMPRESSION pglz); CREATE TABLE cmdata3(f1 text); CREATE TABLE cminh() INHERITS (cmdata, cmdata3); The patch makes this succeed, but I was initially unclear why it didn't

Re: Removing unneeded self joins

Hi, Tom! On Fri, May 3, 2024 at 2:19 AM 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?

Re: Support LIKE with nondeterministic collations

On 03.05.24 02:11, Robert Haas wrote: 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

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

> On 1 May 2024, at 06:21, Michael Paquier wrote: > My remark was originally about pq_init_crypto_lib that does the > locking initialization, and your new patch a bit more, as of: > > ... > > So +1 to remove all this code after a closer lookup. Thanks for review. > I would > recommend to

Re: Document NULL

On Fri, May 3, 2024 at 2:47 PM Laurenz Albe wrote: > > On Thu, 2024-05-02 at 08:23 -0700, David G. Johnston wrote: > > Version 2 attached. Still a draft, focused on topic picking and overall > > structure. > > I'm fine with most of the material (ignoring ellipses and typos), except this: > > +

different engine for JIT

Hi I found https://github.com/vnmakarov/mir?tab=readme-ov-file It should be significantly faster than llvm (compilation). Regards Pavel

Re: Document NULL

On Thu, 2024-05-02 at 08:23 -0700, David G. Johnston wrote: > Version 2 attached.  Still a draft, focused on topic picking and overall > structure. I'm fine with most of the material (ignoring ellipses and typos), except this: +The NOT NULL column constraint is largely syntax sugar for the

Re: Fix parallel vacuum buffer usage reporting

On Wed, May 1, 2024 at 5:37 AM Masahiko Sawada wrote: > Thank you for further testing! I've pushed the patch. Thanks! Here is the rebased version for the follow-up patch removing VacuumPage variables. Though I'm not sure if I should create a dedicated mail thread since the bug was fixed and

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

Hello Devrim, Sorry for the long network outage! >>This is what I do for the Fedora releases. I'm sure you've noticed that >>in the past. No, I didn't notice it and I missed it recently, so I made this proposal (see 1. below). Here are some points concerning $topic: 1. Availability in

Re: UUID v7

> On 13 Apr 2024, at 11:58, Andrey M. Borodin wrote: > > New UUID is assigned RFC number 9562, it was aproved by RFC editors and is > now in AUTH48 state. RFC 9562 is not in AUTH48-Done state, it was approved by authors and editor, and now should be published. Best regards, Andrey