Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Mon, 2024-07-22 at 13:55 -0400, Robert Haas wrote: > On Mon, Jul 22, 2024 at 1:18 PM Laurenz Albe wrote: > > I understand the difficulty (madness) of discussing every Unicode > > change.  If that's unworkable, my preference would be to stick with some > > Unicode version and never modify it, ev

Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids)

On Wed, Jun 5, 2024 at 3:48 PM Ashutosh Bapat wrote: > This is different. But it needs a rebase. PFA rebased patch. The revised > commit message explains the change better. I looked through this patch and I think it is in a good shape. Some minor comments: * I think it's better to declare 'chi

Re: Document use of ldapurl with LDAP simple bind

On 08.07.24 23:27, Jacob Champion wrote: On Fri, Jun 28, 2024 at 12:11 AM Peter Eisentraut wrote: This appears to imply that specifying ldapurl is only applicable for search+bind. Maybe that whole message should be simplified to something like "configuration mixes arguments for simple bind an

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On Fri, Jul 12, 2024 at 12:44:54PM +0300, Aleksander Alekseev wrote: > Fair enough. Here is the updated patchset. Hearing nothing but cicadas as now is their season, I have taken the initiative here to address this open item. 0001 felt a bit too complicated in slru.h, so I have simplified it and

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

Hi, > Hearing nothing but cicadas as now is their season, I have taken the > initiative here to address this open item. > > 0001 felt a bit too complicated in slru.h, so I have simplified it and > kept all the details in slru.c with SlruFileName(). > > I have reviewed all the code that uses SLRUs,

Re: PG_TEST_EXTRA and meson

Hi Nazir, On Fri, Jul 19, 2024 at 1:37 PM Nazir Bilal Yavuz wrote: > > > > If you are willing to work on this further, please add it to the commitfest. > > Since general consensus is more towards having an environment variable > to override Meson configure option, I converted solution-3 to > som

Re: Logical Replication of sequences

On Tue, 16 Jul 2024 at 06:00, Peter Smith wrote: > > Hi, > > I was reading back through this thread to find out how the proposed new > command for refreshing sequences, came about. The patch 0705 introduces a > new command syntax for ALTER SUBSCRIPTION ... REFRESH SEQUENCES > > So now there are

Re: Docs: Order of json aggregate functions

Am Mo., 22. Juli 2024 um 15:19 Uhr schrieb Wolfgang Walther : > > The order of json related aggregate functions in the docs is currently > like this: > > [...] > json_agg > json_objectagg > json_object_agg > json_object_agg_strict > json_object_agg_unique > json_arrayagg > json_object_agg_unique_st

Add new fielids only at last

Currently, the new fields are only supported at the end, Cancannot move the location of the field when editing the table, This does not seem to be an elegant approach

Restrictive combination of GRANT and POLICY

Hi! The permissions given by GRANT and POLICY statements seem to always be combined "permissively". In other words, if role `foo` inherits from roles `can_access_all_columns_but_no_rows` and `can_access_all_rows_but_no_columns`, then `foo` would be able to access all rows and all columns of the ta

Re: Parent/child context relation in pg_get_backend_memory_contexts()

Hi David, David Rowley , 15 Tem 2024 Pzt, 14:38 tarihinde şunu yazdı: > On Sat, 13 Jul 2024 at 10:12, Melih Mutlu wrote: > > I updated documentation for path and level columns and also fixed the > tests as level starts from 1. > > Thanks for updating. > > + The path column can be useful to bui

Re: CI, macports, darwin version problems

On Tue, Jul 23, 2024 at 7:37 AM Andres Freund wrote: > [2] https://cirrus-ci.com/task/5190473306865664 "Error: “disk.img” couldn’t be copied to “3FA983DD-3078-4B28-A969-BCF86F8C9585” because there isn’t enough space." Could it be copying the whole image every time, in some way that would get cop

Re: PG_TEST_EXTRA and meson

Hi, On Tue, 23 Jul 2024 at 12:26, Ashutosh Bapat wrote: > > Upthread Tom asked whether we should do a symmetric change to "make". > This set of patches does not do that. Here are my thoughts: > 1. Those who use make, are not using configure time PG_TEST_EXTRA > anyway, so they don't need it. > 2.

Re: PG_TEST_EXTRA and meson

On Tue, Jul 23, 2024 at 4:02 PM Nazir Bilal Yavuz wrote: > > > I wonder whether we really require pg_test_extra argument to testwrap. > > Why can't we use the logic in testwrap, to set run time PG_TEST_EXTRA, > > in meson.build directly? I.e. set test_env['PG_TEST_EXTRA'] to > > os.environ[;PG_TES

Re: xid_wraparound tests intermittent failure.

On 2024-07-22 Mo 9:29 PM, Masahiko Sawada wrote: On Mon, Jul 22, 2024 at 12:53 PM Andrew Dunstan wrote: On 2024-07-22 Mo 12:46 PM, Tom Lane wrote: Masahiko Sawada writes: Looking at dodo's failures, it seems that while it passes module-xid_wraparound-check, all failures happened only durin

Re: thread-safety: gmtime_r(), localtime_r()

On 04.07.24 18:36, Heikki Linnakangas wrote: The Linux man page for localtime_r() says: According to POSIX.1-2001, localtime() is required to behave as though tzset(3) was called, while localtime_r() does not have  this requirement.   For  portable  code,  tzset(3) should be called before local

Re: Add new fielids only at last

Hi, > Currently, the new fields are only supported at the end, Cancannot move the > location of the field when editing the table, This does not seem to be an > elegant approach Pretty confident it was discussed many times before. Please use the search. -- Best regards, Aleksander Alekseev

Re: PG_TEST_EXTRA and meson

Hi, On Tue, 23 Jul 2024 at 13:40, Ashutosh Bapat wrote: > > On Tue, Jul 23, 2024 at 4:02 PM Nazir Bilal Yavuz wrote: > > > > > I wonder whether we really require pg_test_extra argument to testwrap. > > > Why can't we use the logic in testwrap, to set run time PG_TEST_EXTRA, > > > in meson.build

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

On Mon, Jul 22, 2024 at 2:48 PM Peter Smith wrote: > > Hi, Patch v22-0001 LGTM apart from the following nitpicks > I have included these in the attached. The patch looks good to me. I am planning to push this tomorrow unless there are more comments. -- With Regards, Amit Kapila. v23-0001-Allo

Re: DSO Terms Galore

On 19.07.24 21:27, David E. Wheeler wrote: I’m trying to understand the standard terms for extension libraries. There seem too a bewildering number of terms used to refer to a shared object library, for example: * LOAD[1]: * “shared library” * “shared library file” * dynamic_library_path

Re: pgsql: Add more SQL/JSON constructor functions

While reviewing the patch, I found some inconsistency on json_table EXISTS. --tested based on your patch and master. src4=# SELECT * FROM JSON_TABLE(jsonb '"a"', '$' COLUMNS (a jsonb EXISTS PATH '$')); ERROR: cannot cast behavior expression of type boolean to jsonb src4=# SELECT * FROM JSON_TABLE

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, Jul 23, 2024 at 3:11 AM Laurenz Albe wrote: > I hear you. It would be interesting to know what other RDBMS do here. Yeah, I agree. -- Robert Haas EDB: http://www.enterprisedb.com

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, Jul 23, 2024 at 1:11 AM Laurenz Albe wrote: > On Mon, 2024-07-22 at 13:55 -0400, Robert Haas wrote: > > On Mon, Jul 22, 2024 at 1:18 PM Laurenz Albe > wrote: > > > I understand the difficulty (madness) of discussing every Unicode > > > change. If that's unworkable, my preference would b

Re: Use read streams in CREATE DATABASE command when the strategy is wal_log

On Mon, Jul 22, 2024 at 12:00:45PM +0300, Nazir Bilal Yavuz wrote: > On Sat, 20 Jul 2024 at 21:14, Noah Misch wrote: > > On a different naming topic, my review missed that field name > > copy_storage_using_buffer_read_stream_private.last_block doesn't fit how the > > field is used. Code uses it l

Re: replace strtok()

On 08.07.24 07:45, David Steele wrote: On 6/24/24 19:57, Peter Eisentraut wrote: On 24.06.24 02:34, Michael Paquier wrote: On Sat, Jun 22, 2024 at 11:48:21AM -0400, Tom Lane wrote: Peter Eisentraut writes: On 18.06.24 13:43, Ranier Vilela wrote: I found another implementation of strsep, it

Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin

On Mon, Jul 22, 2024 at 10:54 PM Masahiko Sawada wrote: > > On Mon, Jul 22, 2024 at 6:26 PM Melanie Plageman > wrote: > > > > On Mon, Jul 22, 2024 at 6:36 PM Tom Lane wrote: > > > > > > Melanie Plageman writes: > > > > We've only run tests with this commit on some of the back branches for > > >

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, Jul 23, 2024 at 8:32 AM Jeremy Schneider wrote: > Other RDBMS are very careful not to corrupt databases, afaik including > function based indexes, by changing Unicode. I’m not aware of any other RDBMS > that updates Unicode versions in place; instead they support multiple Unicode > vers

Re: pgsql: Add more SQL/JSON constructor functions

On Tue, Jul 23, 2024 at 11:45 AM jian he wrote: > On Mon, Jul 22, 2024 at 4:46 PM Amit Langote wrote: > > > > On Thu, Jul 18, 2024 at 3:04 PM jian he wrote: > > > we still have problem in transformJsonBehavior > > > > > > currently transformJsonBehavior: > > > SELECT JSON_VALUE(jsonb '1234', '$'

Re: Things I don't like about \du's "Attributes" column

On Mon, Jul 22, 2024 at 5:19 PM Pavel Luzanov wrote: > Visible but inaccessible objects in system catalogs increase the volume > of command output unnecessarily. Why do I need to know the list of all > schemas in the database if I only have access to the public schema? > The same applies to inacce

Re: xid_wraparound tests intermittent failure.

On 2024-07-22 Mo 10:11 PM, Tom Lane wrote: Andrew Dunstan writes: On 2024-07-22 Mo 12:46 PM, Tom Lane wrote: Masahiko Sawada writes: Looking at dodo's failures, it seems that while it passes module-xid_wraparound-check, all failures happened only during testmodules-install-check-C. Can we

Re: Comments on Custom RMGRs

On 27/05/2024 21:20, Michael Paquier wrote: On Fri, May 17, 2024 at 04:25:15PM -0400, Robert Haas wrote: On Fri, May 17, 2024 at 4:20 PM Jeff Davis wrote: Regarding this particular change: the checkpointing hook seems more like a table AM feature, so I agree with you that we should have a good

Re: [PATCH] GROUP BY ALL

On 23 Jul 2024, at 00:40, Isaac Morland wrote:odyssey=> select (uw_term).*, count(*) from uw_term group by uw_term;ERROR:  column "uw_term.term_id" must appear in the GROUP BY clause or be used in an aggregate functionLINE 1: select (uw_term).*, count(*) from uw_term group

Re: [PATCH] GROUP BY ALL

On Mon, Jul 22, 2024 at 4:34 PM David G. Johnston wrote: > > On Mon, Jul 22, 2024 at 1:55 PM David Christensen wrote: >> >> I see that there'd been some chatter but not a lot of discussion about >> a GROUP BY ALL feature/functionality. There certainly is utility in >> such a construct IMHO. >> >

Re: Document use of ldapurl with LDAP simple bind

On Tue, Jul 23, 2024 at 1:37 AM Peter Eisentraut wrote: > Committed. Thanks! > (I suppose this could be considered a bug fix, but I don't feel an > urgency to go backpatching this. Let me know if there are different > opinions.) Certainly no urgency. The docs part of the patch also could be ba

Re: [PATCH] GROUP BY ALL

On Mon, Jul 22, 2024 at 5:29 PM Tom Lane wrote: > > "David G. Johnston" writes: > > On Mon, Jul 22, 2024 at 1:55 PM David Christensen wrote: > >> I see that there'd been some chatter but not a lot of discussion about > >> a GROUP BY ALL feature/functionality. There certainly is utility in > >>

Re: [PATCH] GROUP BY ALL

On Tue, Jul 23, 2024 at 8:21 AM Andrei Borodin wrote: > > On 23 Jul 2024, at 00:40, Isaac Morland wrote: > > odyssey=> select (uw_term).*, count(*) from uw_term group by uw_term; > ERROR: column "uw_term.term_id" must appear in the GROUP BY clause or be > used in an aggregate function > LINE 1:

Re: [PATCH] GROUP BY ALL

On Mon, Jul 22, 2024 at 4:41 PM Isaac Morland wrote: > And for when this might be useful, the syntax for it already exists, although > a spurious error message is generated: > > odyssey=> select (uw_term).*, count(*) from uw_term group by uw_term; > ERROR: column "uw_term.term_id" must appear i

Re: Add new COPY option REJECT_LIMIT

On Tue, Jul 23, 2024 at 1:35 PM Fujii Masao wrote: Thanks for your review. On 2024/07/22 21:37, torikoshia wrote: On Fri, Jul 19, 2024 at 11:48 PM Junwang Zhao wrote: Thanks for the comment. In patch 0002, the ratio is calculated by the already skipped/processed rows, but what if a user

Re: Add new COPY option REJECT_LIMIT

On 2024-07-23 02:06, Kirill Reshke wrote: Thanks for your review. Few comments: + When a positive integer value is specified, COPY limits + the maximum tolerable number of errors while converting a column's input + value into its data type. If nothing is specified, then the

Re: PG_TEST_EXTRA and meson

On Tue, Jul 23, 2024 at 3:32 AM Nazir Bilal Yavuz wrote: > Upthread Jacob said he could work on a patch about introducing the > PG_TEST_EXTRA configure option to make builds. Would you still be > interested in working on this? If not, I would gladly work on it. Sure! Attached is a minimalist appr

Re: DSO Terms Galore

On Jul 23, 2024, at 07:26, Peter Eisentraut wrote: > Things like "object" or "object file" or probably wrong-ish. I understand an > object file to be a .o file, which you can't dlopen directly. Agreed. Another option, however, is “dynamically shared object” (DSO), which corresponds to the us

Re: proposal: schema variables

Thanks for the fixes and the new patch set! I think that this would be a very valuable feature! This is a very incomplete review after playing with the patch set for a while. Some bugs and oddities I have found: "psql" support: \? gives \dV [PATTERN] list variables I think th

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Mon, Jul 22, 2024 at 09:34:42AM -0700, Jeff Davis wrote: > On Mon, 2024-07-22 at 11:14 -0400, Robert Haas wrote: > > On Mon, Jul 22, 2024 at 10:26 AM Peter Eisentraut > > wrote: > > > I disagree with that.  We should put ourselves into the position to > > > adopt new Unicode versions without f

Re: Enhance pg_dump multi-threaded streaming (WAS: Re: filesystem full during vacuum - space recovery issues)

Hi Andrew, This is very interesting. I had started looking at pg_dumpall trying to work out an approach.  I noticed parallel.c essentially already does all the thread creation and coordination that I knew would be needed. Given that is a solved problem, I started to look further (continued be

Re: CI, macports, darwin version problems

On 7/23/24 06:31, Thomas Munro wrote: On Tue, Jul 23, 2024 at 7:37 AM Andres Freund wrote: [2] https://cirrus-ci.com/task/5190473306865664 "Error: “disk.img” couldn’t be copied to “3FA983DD-3078-4B28-A969-BCF86F8C9585” because there isn’t enough space." Could it be copying the whole image ev

Re: [PATCH] GROUP BY ALL

On Tue, 2024-07-23 at 08:37 -0500, David Christensen wrote: > My intention here was to basically be a shorthand for "group by > specified non-aggregate fields in the select list".  Perhaps I'm not > being creative enough, but what is the interpretation/use case for > anything else? :-) I am somewh

Re: SQL:2011 application time

On 7/18/24 11:39, Paul Jungwirth wrote: So I swapped in the &&& patch, cleaned it up, and added tests. But something is wrong. After I get one failure from an empty, I keep getting failures, even though the table is empty: regression=# truncate temporal_rng cascade; NOTICE:  truncate cascades t

Re: [PATCH] GROUP BY ALL

On Tue, Jul 23, 2024 at 10:57 AM Laurenz Albe wrote: > > On Tue, 2024-07-23 at 08:37 -0500, David Christensen wrote: > > My intention here was to basically be a shorthand for "group by > > specified non-aggregate fields in the select list". Perhaps I'm not > > being creative enough, but what is t

Re: [PATCH] GROUP BY ALL

On Tue, Jul 23, 2024 at 9:48 AM David Christensen wrote: > > Sure, not everything that makes things easier is strictly necessary; > we could require `CAST(field AS text)` instead of `::text`, Probably should have...being standard and all. Though syntactic sugar is quite different from new beha

Re: [PATCH] GROUP BY ALL

On 7/22/24 15:43, Tom Lane wrote: Isaac Morland writes: And for when this might be useful, the syntax for it already exists, although a spurious error message is generated: odyssey=> select (uw_term).*, count(*) from uw_term group by uw_term; ERROR: column "uw_term.term_id" must appear in t

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, 2024-07-23 at 08:49 -0400, Robert Haas wrote: > Hmm. I think we might have some unique problems due to the fact that > we rely partly on the operating system behavior, partly on libicu, > and > partly on our own internal tables. The reliance on the OS is especially problematic for reasons

Re: Direct SSL connection and ALPN loose ends

On 16/07/2024 09:54, Michael Paquier wrote: On Mon, Jun 24, 2024 at 11:30:53PM +0300, Heikki Linnakangas wrote: 0002: This is the main patch that fixes the SSL fallback issue + conn->failed_enc_methods |= conn->allowed_enc_methods & (~conn->current_enc_method); Sounds reasonable to me. I

Re: Add mention of execution time memory for enable_partitionwise_* GUCs

Thank you for the patch improving the docs, I think it's a clear improvement from before. On Thu, 18 Jul 2024, David Rowley wrote: I considered writing about work_mem, but felt I wanted to keep it as brief as possible and just have some words that might make someone think twice. The details in

Re: Add privileges test for pg_stat_statements to improve coverage

On 2024/07/23 15:02, kuroda.keis...@nttcom.co.jp wrote: Hi Fujii-san, Thank you for your comment! attach v5 fixed patch. Using "postgres" as the default superuser name can cause instability. This is why the Patch Tester reports now test failures again. You should create and use a different s

Useless toast

Using version 16, seems strange when toast needs to be created. Tested with domain being numeric or varchar(10) with the same results. And If that domain is integer then no toast is created. I think none of these tables should have a toast, right ? postgres=# create domain mynum as numeric(15,2)

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, Jul 23, 2024 at 1:03 PM Jeff Davis wrote: > One of my strongest motivations for PG_C_UTF8 was that there was still > a use case for libc in PG16: the "C.UTF-8" locale, which is not > supported at all in ICU. Daniel Vérité made me aware of the importance > of this locale, which offers code

Re: [18] Policy on IMMUTABLE functions and Unicode updates

Robert Haas writes: > Also, Noah has pointed out that C.UTF-8 introduces some > forward-compatibility hazards of its own, at least with respect to > ctype semantics. I don't have a clear view of what ought to be done > about that, but if we just replace a dependency on an unstable set of > libc de

Re: Useless toast

On 23.07.24 20:35, Marcos Pegoraro wrote: Using version 16, seems strange when toast needs to be created. Tested with domain being numeric or varchar(10) with the same results. And If that domain is integer then no toast is created. I think none of these tables should have a toast, right ? T

Re: Useless toast

Marcos Pegoraro writes: > Using version 16, seems strange when toast needs to be created. Tested with > domain being numeric or varchar(10) with the same results. Domains are fairly opaque when it comes to maximum length. I cannot get excited about adding code to make them less so.

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On 7/23/24 15:26, Tom Lane wrote: Robert Haas writes: Also, Noah has pointed out that C.UTF-8 introduces some forward-compatibility hazards of its own, at least with respect to ctype semantics. I don't have a clear view of what ought to be done about that, but if we just replace a dependency on

Re: Useless toast

Peter Eisentraut writes: > On 23.07.24 20:35, Marcos Pegoraro wrote: >> I think none of these tables should have a toast, right ? > The mechanism that determines whether a toast table is needed only > considers the data type, not the "typmod" (arguments of the data type). > So this is perhaps s

Re: pg_upgrade and logical replication

On Tue, Jul 23, 2024 at 09:05:05AM +0530, Amit Kapila wrote: > Right, the other option would be to move it to the place where we call > check_old_cluster_for_valid_slots(), etc. Initially, it was kept in > the specific function (get_db_rel_and_slot_infos) as we were > mainlining the count at the pe

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, 2024-07-23 at 15:26 -0400, Tom Lane wrote: > No, I think we *are* winning, because the updates are not "equally > unstable": with pg_c_utf8, we control when changes happen.  We can > align them with major releases and release-note the differences. > With libc-based collations, we have zero

Re: [PATCH] GROUP BY ALL

On 23.07.24 00:29, Tom Lane wrote: (Personally, I'd wonder exactly what ALL is quantified over: the whole output of the FROM clause, or only columns mentioned in the SELECT tlist, or what? And why that choice rather than another?) Looks like the main existing implementations take it to mean all

Re: [18] Policy on IMMUTABLE functions and Unicode updates

Jeff Davis writes: > On Tue, 2024-07-23 at 15:26 -0400, Tom Lane wrote: >> No, I think we *are* winning, because the updates are not "equally >> unstable": with pg_c_utf8, we control when changes happen.  We can >> align them with major releases and release-note the differences. >> With libc-based

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, 2024-07-23 at 07:39 -0700, Noah Misch wrote: > we should remedy the step backward that pg_c_utf8 has taken: Obviously I disagree that we've taken a step backwards. Can you articulate the principle by which all of the other problems with IMMUTABLE are just fine, but updates to Unicode are

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, Jul 23, 2024 at 3:26 PM Tom Lane wrote: > No, I think we *are* winning, because the updates are not "equally > unstable": with pg_c_utf8, we control when changes happen. We can > align them with major releases and release-note the differences. > With libc-based collations, we have zero co

Re: [18] Policy on IMMUTABLE functions and Unicode updates

Robert Haas writes: > On Tue, Jul 23, 2024 at 3:26 PM Tom Lane wrote: >>> Do we need to version the new ctype provider? >> It would be a version for the underlying Unicode definitions, >> not the provider as such, but perhaps yes. I don't know to what >> extent doing so would satisfy Noah's con

Re: [18] Policy on IMMUTABLE functions and Unicode updates

Tom Lane wrote: > > I don't see how we can get by without some kind of versioning here. > > It's probably too late to do that for v17, > > Why? If we agree that that's the way forward, we could certainly > stick some collversion other than "1" into pg_c_utf8's pg_collation > entry. Ther

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On 22.07.24 19:55, Robert Haas wrote: Every other piece of software in the world has to deal with changes as a result of the addition of new code points, and probably less commonly, revisions to existing code points. Presumably, their stuff breaks too, from time to time. I mean, I find it a bit d

Re: [18] Policy on IMMUTABLE functions and Unicode updates

"Daniel Verite" writes: > Tom Lane wrote: >> Why? If we agree that that's the way forward, we could certainly >> stick some collversion other than "1" into pg_c_utf8's pg_collation >> entry. There's already been one v17 catversion bump since beta2 >> (716bd12d2), so another one is basicall

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, 2024-07-23 at 16:07 -0400, Tom Lane wrote: > Well, it depends on which libc collation you have in mind.  I was > thinking of a libc-supplied C.UTF-8 collation, which I would expect > to behave the same as pg_c_utf8, modulo which Unicode version it's > based on. Daniel Vérité documented[1]

Re: query_id, pg_stat_activity, extended query protocol

> On Wed, Jul 17, 2024 at 11:32:49AM +0200, Anthonin Bonnefoy wrote: >> Wouldn't it be enough to call pgstat_report_query_id in ExecutorRun >> and ProcessUtility? With those changes [1], both normal statements and >> utility statements called through extended protocol will correctly >> report the

Re: [18] Policy on IMMUTABLE functions and Unicode updates

Jeff Davis writes: > On Tue, 2024-07-23 at 16:07 -0400, Tom Lane wrote: >> Well, it depends on which libc collation you have in mind.  I was >> thinking of a libc-supplied C.UTF-8 collation, which I would expect >> to behave the same as pg_c_utf8, modulo which Unicode version it's >> based on. >

Re: Remove dependence on integer wrapping

On Mon, Jul 22, 2024 at 6:07 PM Matthew Kim wrote: > > On Mon, Jul 22, 2024 at 5:52 PM Alexander Lakhin wrote: > >> Also there are several trap-producing cases with date types: >> SELECT to_date('1', 'CC'); > > Hi, I’ve attached a patch that fixes the to_date() overflow. Patches 1 through

Re: proposal: schema variables

On Tue, 2024-07-23 at 16:34 +0200, Laurenz Albe wrote: > CREATE VARIABLE command: > > This is buggy: > > CREATE VARIABLE str AS text NOT NULL DEFAULT NULL; > > Ugh. > > SELECT str; > ERROR: null value is not allowed for NOT NULL session variable > "laurenz.str" > DETAIL:

Re: Statistics Import and Export

Giving the parameter lists more thought, the desire for a return code more granular than true/false/null, and the likelihood that each function will inevitably get more parameters both stats and non-stats, I'm proposing the following: Two functions: pg_set_relation_stats( out schemaname name,

Re: Statistics Import and Export

> > > and pg_set_attribute_stats. > pg_set_relation_stats(out schemaname name, out relname name,, out > row_written boolean, out params_entered int, out params_accepted int, > kwargs any[]) > > Oops, didn't hit undo fast enough. Disregard this last bit.

Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin

On Tue, Jul 23, 2024 at 5:43 AM Melanie Plageman wrote: > > On Mon, Jul 22, 2024 at 10:54 PM Masahiko Sawada > wrote: > > > > On Mon, Jul 22, 2024 at 6:26 PM Melanie Plageman > > wrote: > > > > > > On Mon, Jul 22, 2024 at 6:36 PM Tom Lane wrote: > > > > > > > > Melanie Plageman writes: > > >

Re: xid_wraparound tests intermittent failure.

On Tue, Jul 23, 2024 at 3:49 AM Andrew Dunstan wrote: > > > On 2024-07-22 Mo 9:29 PM, Masahiko Sawada wrote: > > On Mon, Jul 22, 2024 at 12:53 PM Andrew Dunstan wrote: > > On 2024-07-22 Mo 12:46 PM, Tom Lane wrote: > > Masahiko Sawada writes: > > Looking at dodo's failures, it seems that while i

Re: UUID v7

Dear Colleagues, Althoughthe uuidv7(timestamp) function clearly contradicts RFC 9562, but theuuidv7(timestamp_offset) function is fully compliant with RFC 9562 and isabsolutely necessary. Here is a quote from the RFC 9562to support thisstatement (RFC 9562: Universally Unique IDentifiers (UUIDs

Re: Direct SSL connection and ALPN loose ends

On Tue, Jul 23, 2024 at 08:32:29PM +0300, Heikki Linnakangas wrote: > All these new tests are a great asset when refactoring this again. Thanks for doing that. The coverage, especially with v2, is going to be really useful. > Yeah, I'm also not too excited about the additional code in the backen

Re: Can't find bugs to work on

On Sat, Jul 13, 2024 at 12:09 AM David G. Johnston wrote: > > On Fri, Jul 12, 2024 at 8:44 AM Tom Lane wrote: >> >> >> As this example shows, it's now standard for PG commit log messages >> to include a link to the relevant email thread, so all you need >> is the message-ID of the first message i

Re: Add privileges test for pg_stat_statements to improve coverage

I've slightly modified the comments in the regression tests for clarity. Attached is the v6 patch. If there are no objections, I will push this version. Thank you for updating patch! I have no objection. Best Regards, Keisuke Kuroda NTT Comware

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, Jul 23, 2024 at 4:36 PM Peter Eisentraut wrote: > The sorting isn't the problem. We have a versioning mechanism for > collations. What we do with the version information is clearly not > perfect yet, but the mechanism exists and you can hack together queries > that answer the question, d

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, 2024-07-23 at 21:37 -0400, Robert Haas wrote: > In my experience, sorting is, overwhelmingly, the problem. I strongly agree. > That we have versioning information that someone could hypothetically > know how to do something useful with is not really useful, because > nobody actually knows

The 031_recovery_conflict.pl test might fail due to late pgstat entries flushing

Hello hackers, A recent buildfarm failure [1] shows that the test 031_recovery_conflict.pl can fail yet another way:  23/296 postgresql:recovery / recovery/031_recovery_conflict ERROR    11.55s   exit status 1 [07:58:53.979](0.255s) ok 11 - tablespace conflict: logfile contains terminat

Re: Remove dependence on integer wrapping

On Tue, Jul 23, 2024 at 05:41:18PM -0400, Joseph Koshakow wrote: > On Tue, Jul 23, 2024 at 2:14 AM jian he wrote: >> On Tue, Jul 23, 2024 at 6:56 AM Joseph Koshakow wrote: >>> The specific bug that this patch fixes is preventing the following >>> statement: >>> >>> # INSERT INTO arroverflowte

Re: Logical Replication of sequences

Hi, here are some review comments for patch v20240720-0003. This review is a WIP. This post is only about the docs (*.sgml) of patch 0003. == doc/src/sgml/ref/alter_subscription.sgml 1. REFRESH PUBLICATION and copy_data nitpicks: - IMO the "synchronize the sequence data" info was misleading

Re: apply_scanjoin_target_to_paths and partitionwise join

On Wed, May 22, 2024 at 3:57 PM Ashutosh Bapat wrote: > I will create patches for the back-branches once the patch for master is in a > committable state. AFAIU, this patch prevents apply_scanjoin_target_to_paths() from discarding old paths of partitioned joinrels. Therefore, we can retain non-

Re: [18] Policy on IMMUTABLE functions and Unicode updates

On 24.07.24 03:37, Robert Haas wrote: On Tue, Jul 23, 2024 at 4:36 PM Peter Eisentraut wrote: The sorting isn't the problem. We have a versioning mechanism for collations. What we do with the version information is clearly not perfect yet, but the mechanism exists and you can hack together qu

Re: Conflict detection and logging in logical replication

On Thu, Jul 18, 2024 at 7:52 AM Zhijie Hou (Fujitsu) wrote: > > Attach the V5 patch set which changed the following: > Tested v5-0001 patch, and it fails to detect the update_exists conflict for a setup where Pub has a non-partitioned table and Sub has the same table partitioned. Below is a testc

Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bindx

On Fri, Jul 19, 2024 at 03:28:44PM +0200, Tomas Vondra wrote: > OK, if you're already half-way through the review, I'll leave it up to > you. I don't think we need to rush, and I'd have to learn about all the > psql stuff first anyway. It took me a couple of days to get back to it, but attached is

Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bindx

On Fri, Jul 19, 2024 at 03:28:44PM +0200, Tomas Vondra wrote: > OK, if you're already half-way through the review, I'll leave it up to > you. I don't think we need to rush, and I'd have to learn about all the > psql stuff first anyway. It took me a couple of days to get back to it, but attached is

Re: Confine vacuum skip logic to lazy_scan_skip

On Tue, Jul 16, 2024 at 1:52 PM Noah Misch wrote: > On Mon, Jul 15, 2024 at 03:26:32PM +1200, Thomas Munro wrote: > That's reasonable. radixtree already forbids mutations concurrent with > iteration, so there's no new concurrency hazard. One alternative is > per_buffer_data big enough for MaxOff

Re: tls 1.3: sending multiple tickets

On 18/06/2024 16:11, Daniel Gustafsson wrote: On 17 Jun 2024, at 19:38, Andres Freund wrote: Seems we ought to use SSL_CTX_set_num_tickets() to prevent issuing the useless tickets? Agreed, in 1.1.1 and above as the API was only introduced then. LibreSSL added the API in 3.5.4 but only for com

Re: pg_upgrade and logical replication

On Wed, Jul 24, 2024 at 1:25 AM Nathan Bossart wrote: > > On Tue, Jul 23, 2024 at 09:05:05AM +0530, Amit Kapila wrote: > > Right, the other option would be to move it to the place where we call > > check_old_cluster_for_valid_slots(), etc. Initially, it was kept in > > the specific function (get_d

Re: Logical Replication of sequences

On Wed, Jul 24, 2024 at 9:17 AM Peter Smith wrote: > I had a look at patches v20240720* (considering these as the latest one) and tried to do some basic testing (WIP). Few comments: 1) I see 'last_value' is updated wrongly after create-sub. Steps: --- pub: CREATE SEQUENCE myseq0 INCREM

Re: pgsql: Add more SQL/JSON constructor functions

On Tue, Jul 23, 2024 at 8:52 PM Amit Langote wrote: > > In the attached patch, I've also taken care of the problem mentioned > in your latest email -- the solution I've chosen is not to produce the > error when ERROR ON ERROR is specified but to use runtime coercion > also for the jsonb type or an

Re: Logical Replication of sequences

On Tue, 23 Jul 2024 at 11:03, Peter Smith wrote: > > Here are some review comments for patch v20240720-0002. > > == > 1. Commit message: > > 1a. > The commit message is stale. It is still referring to functions and > views that have been moved to patch 0003. Modified > 1b. > "ALL SEQUENCES"

  1   2   >