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

On Wed, Jul 24, 2024 at 05:33:07PM +0200, Peter Eisentraut wrote: > This commit message confused me, because I don't think this is what the > \bindx command actually does. AFAICT, it only binds, it does not execute. > At least that is what the documentation in the content of the patch appears > to

Re: Logical Replication of sequences

On Thu, Jul 25, 2024 at 9:06 AM vignesh C wrote: > > The attached v20240725 version patch has the changes for the same. Thank You for addressing the comments. Please review below issues: 1) Sub ahead of pub due to wrong initial sync of last_value for non-incremented sequences. Steps at [1] 2) Se

Re: SQL:2011 application time

On Wed, Jul 24, 2024 at 12:08 AM Paul Jungwirth wrote: > > 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

Re: long-standing data loss bug in initial sync of logical replication

On Wed, Jul 17, 2024 at 5:25 PM vignesh C wrote: > > On Wed, 17 Jul 2024 at 11:54, Amit Kapila wrote: > > > > On Tue, Jul 16, 2024 at 6:54 PM vignesh C wrote: > > > > BTW, I noticed that we don't take any table-level locks for Create > > Publication .. For ALL TABLES (and Drop Publication). Can

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

Hi, THREAD SUMMARY: Proposal: How about making COPY format extendable? Background: Currently, COPY TO/FROM supports only "text", "csv" and "binary" formats. There are some requests to support more COPY formats. For example: * 2023-11: JSON and JSON lines [1] * 2022-04: Apache Arrow [2] * 20

Re: Recent 027_streaming_regress.pl hangs

Hello Andrew, 04.06.2024 13:00, Alexander Lakhin wrote: Also, 027_stream_regress still fails due to the same reason: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2024-05-22%2021%3A55%3A03 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2024-05-22%202

Re: query_id, pg_stat_activity, extended query protocol

On Tue, Jul 23, 2024 at 04:00:25PM -0500, Sami Imseih wrote: > Correct, I also don´t think ExecutorRun is enough. Another reason is we > should also > be setting the queryId during bind, right before planning starts. > Planning could have significant impact on the server and I think we better >

Re: Make tuple deformation faster

On Mon, Jul 1, 2024 at 5:07 PM David Rowley wrote: > cycles idle >8505168 stalled-cycles-backend:u #0.02% backend cycles > idle > 165442142326 instructions:u#3.35 insn per cycle > #0.00 stall

Re: pg_upgrade and logical replication

On Thu, Jul 25, 2024 at 08:43:03AM +0530, Amit Kapila wrote: >> Shall we close the open items? > > Sorry for the typo. There is only one open item corresponding to this: > "Subscription and slot information retrieval inefficiency in > pg_upgrade" which according to me should be closed after your c

Adding clarification to description of IPC wait events XactGroupUpdate and ProcArrayGroupUpdate

Hi, While preparing for my presentation on PostgreSQL Wait Events at PgConf India, I was trying to understand *IPC:XactGroupUpdate* in more detail. PostgreSQL documentation [1] mentions: > A process is waiting for the group leader to update the transaction status at > the end of a _parallel oper

Re: pg_upgrade and logical replication

On Thu, Jul 25, 2024 at 8:41 AM Amit Kapila wrote: > > On Wed, Jul 24, 2024 at 10:03 PM Nathan Bossart > wrote: > > > > On Wed, Jul 24, 2024 at 11:32:47AM +0530, Amit Kapila wrote: > > > LGTM. > > > > Thanks for reviewing. Committed and back-patched to v17. > > > > Shall we close the open items?

Re: pg_upgrade and logical replication

On Wed, Jul 24, 2024 at 10:03 PM Nathan Bossart wrote: > > On Wed, Jul 24, 2024 at 11:32:47AM +0530, Amit Kapila wrote: > > LGTM. > > Thanks for reviewing. Committed and back-patched to v17. > Shall we close the open items? I think even if we want to improve the slot fetching/creation mechanism,

Re: Parent/child context relation in pg_get_backend_memory_contexts()

On Tue, 23 Jul 2024 at 22:14, Melih Mutlu wrote: > Fixed the name. Also I needed to cast parameters when calling that function > as below to get rid of some warnings. > > + get_memory_context_name_and_ident(context, > +

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

On Wed, Jul 24, 2024 at 9:13 PM Tom Lane wrote: > > Amit Kapila writes: > > I merged these changes, made a few other cosmetic changes, and pushed the > > patch. > > There is a CF entry pointing at this thread [1]. Should it be closed? > Yes, closed now. Thanks for the reminder. -- With Regar

Re: Parent/child context relation in pg_get_backend_memory_contexts()

On Wed, 24 Jul 2024 at 21:47, David Rowley wrote: > I've only had a quick look so far, but I think the patch is now in the > right shape. Unless there's some objections to how things are being > done in v10, I plan to commit this in the next few days... modulo any > minor adjustments. I reviewed

Re: Sporadic connection-setup-related test failures on Cygwin in v15-

24.07.2024 23:58, Thomas Munro wrote: +1. I'm not planning to back-patch that work. Perhaps lorikeet could stop testing releases < 16? They don't work and it's not our bug[1]. We decided not to drop Cygwin support[2], but I don't think we're learning anything from investigating that noise in

Re: optimizing pg_upgrade's once-in-each-database steps

On Mon, Jul 22, 2024 at 03:07:10PM -0500, Nathan Bossart wrote: > Here is a new patch set. I've included the latest revision of the patch to > fix get_db_subscription_count() from the other thread [0] as 0001 since I > expect that to be committed soon. I've also moved the patch that moves the > "

Re: CI, macports, darwin version problems

On Thu, Jul 25, 2024 at 11:35 AM Thomas Munro wrote: > Looking good! Thanks. I have now pushed the patch to switch CI to > Sonoma, back-patched as far as 15. Let's see how that goes. I have > also paused the pgx machine for now, until Christophe is available to > help us fix it. Cfbot builds

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

On Wed, Jul 24, 2024 at 05:33:07PM +0200, Peter Eisentraut wrote: > This commit message confused me, because I don't think this is what the > \bindx command actually does. AFAICT, it only binds, it does not execute. > At least that is what the documentation in the content of the patch appears > to

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

On Wed, Jul 24, 2024 at 06:00:59AM -0700, Noah Misch wrote: > I'm still seeing need for s/int/int64/ at: Nice catches! I've missed these. > - "pagesegno" variable > - return value of MultiXactIdToOffsetSegment() Only used in four places for two elog(DEBUG1) entries with %x. > - return value of

Re: CI, macports, darwin version problems

On Thu, Jul 25, 2024 at 7:25 AM Joe Conway wrote: > I *think* I finally have it in a good place. I replaced the nvme > enclosure that I bought the other day (which had a 10G interface speed) > with a new one (which has 40G rated speed). The entire ~/.tart directory > is a symlink to /Volumes/extnv

Re: Remove dependence on integer wrapping

On Mon, Jul 22, 2024 at 5:52 PM Alexander Lakhin wrote: > Also there are several trap-producing cases with date types: > SELECT make_date(-2147483648, 1, 1); Hi, I’ve attached a patch that fixes the make_date overflow. I’ve upgraded the patches accordingly to reflect Joseph’s committed fix. Tha

Re: Convert sepgsql tests to TAP

On 7/24/24 10:35 PM, Tom Lane wrote: Andreas Karlsson writes: 1) As I said earlier I think we should remove the old code. I agree that carrying two versions of the test doesn't seem great. However, a large part of the purpose of test_sepgsql is to help people debug their sepgsql setup, which

Re: Sporadic connection-setup-related test failures on Cygwin in v15-

On Thu, Jul 25, 2024 at 1:00 AM Alexander Lakhin wrote: > The important fact here is that this failure is not reproduced after > 7389aad63 (in v16), so it seems that it's somehow related to signal > processing. Given that, I'm inclined to stop here, without digging deeper, > at least until there a

Re: Convert sepgsql tests to TAP

Andreas Karlsson writes: > 1) As I said earlier I think we should remove the old code. I agree that carrying two versions of the test doesn't seem great. However, a large part of the purpose of test_sepgsql is to help people debug their sepgsql setup, which is why it goes to great lengths to prin

Re: DRAFT: Pass sk_attno to consistent function

=?utf-8?Q?Micha=C5=82_K=C5=82eczek?= writes: > I understand extensibility of GIST makes many operators opaque to the planner > and it is the “consistent” function that can perform optimisations (or we can > come up with some additional mechanism during planning phase). > Providing more informati

Re: [BUG?] check_exclusion_or_unique_constraint false negative

Hello, everyone! Updates so far: * issue happens with both LOGGED and UNLOGGED relations * issue happens with DirtySnapshot * not happens with SnapshotSelf * not happens with SnapshotAny * not related to speculative inserted tuples - I have commented the code of its insertion - and the issue conti

Re: Convert sepgsql tests to TAP

On 7/24/24 6:33 PM, Peter Eisentraut wrote: On 24.07.24 16:31, Andreas Karlsson wrote: I took a quick look at the patch and I like that we standardize things a bit. But one thing I am not a fan of are all the use of sed and awk in the Perl script. I would prefer if that logic happened all in Pe

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

On Wed, Jul 24, 2024 at 3:43 PM Jeremy Schneider wrote: > But non-unique indexes for case insensitive searches will be more common. > Historically this is the most common way people did case insensitive on > oracle. > > Changing ctype would mean these queries can return wrong results Yeah. I me

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

On Wed, Jul 24, 2024 at 12:47 PM Robert Haas wrote: On Wed, Jul 24, 2024 at 1:45 PM Jeff Davis wrote: > There's a qualitative difference between a collation update which can > break your PKs and FKs, and a ctype update which definitely will not. I don't think that's true. All you need is a uniq

Re: Regarding t_cid in Neon heap WAL records

On 24/07/2024 21:44, Muhammad Malik wrote: Neon added a t_cid field to heap WAL records https://github.com/yibit/neon-postgresql/blob/main/docs/core_changes.md#add-t_cid-to-heap-wal-records .

Re: Incremental backup from a streaming replication standby fails

On Wed, Jul 24, 2024 at 6:46 AM Laurenz Albe wrote: > An incremental backup is only possible if replay would begin from a later > checkpoint than the checkpoint that started the previous backup upon which > it depends. My concern here is that the previous backup might have been taken on a s

Re: CI, macports, darwin version problems

On 7/23/24 10:44, Joe Conway wrote: I guess if all else fails I will have to get the mac mini with more built in storage in order to accommodate sonoma. I *think* I finally have it in a good place. I replaced the nvme enclosure that I bought the other day (which had a 10G interface speed) wit

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

On Wed, Jul 24, 2024 at 3:12 PM Jeff Davis wrote: > In any case, you are correct that Unicode updates could put some > constraints at risk, including unique indexes, CHECK, and partition > constraints. But someone has to actually use one of the affected > functions somewhere, and that's the main d

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

On Wed, 2024-07-24 at 14:47 -0400, Robert Haas wrote: > On Wed, Jul 24, 2024 at 1:45 PM Jeff Davis wrote: > > There's a qualitative difference between a collation update which > > can > > break your PKs and FKs, and a ctype update which definitely will > > not. > > I don't think that's true. All

Re: proposal: schema variables

út 23. 7. 2024 v 23:41 odesílatel Laurenz Albe napsal: > 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

Re: add function argument names to regex* functions.

jian he writes: > On Fri, Jul 19, 2024 at 5:48 AM Tom Lane wrote: >> The larger issue is that contrib/citext offers versions of some of >> these functions that are meant to be drop-in replacements using >> citext input. Hence, we need to add the same parameter names to >> those functions, or the

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

On Wed, Jul 24, 2024 at 1:45 PM Jeff Davis wrote: > There's a qualitative difference between a collation update which can > break your PKs and FKs, and a ctype update which definitely will not. I don't think that's true. All you need is a unique index on UPPER(somecol). -- Robert Haas EDB: http

Regarding t_cid in Neon heap WAL records

Neon added a t_cid field to heap WAL records https://github.com/yibit/neon-postgresql/blob/main/docs/core_changes.md#add-t_cid-to-heap-wal-records. However, when replaying the delete log record, it is discarding the combo flag and storing the raw cmax on the old tuple https://github.com/neondat

Re: improve performance of pg_dump with many sequences

I ran Euler's tests again on the v6 patch set. for i in `seq 1 1`; do psql postgres -c "CREATE SEQUENCE s$i;"; done time pg_dump -f - -s -d postgres > /dev/null HEAD:0.607s 0001 + 0002: 0.094s all patches: 0.094s Barring additional feedback, I

Re: warning: dereferencing type-punned pointer

Peter Eisentraut writes: > If you change the member to a pointer > - ErrorSaveContext escontext; > + ErrorSaveContext *escontext; > } JsonExprState; > and make the required adjustments elsewhere in the code, the warning > goes away. > This arrangement would also appear to be more consist

Re: warning: dereferencing type-punned pointer

BTW, I tried the same experiment of building without -fno-strict-aliasing using gcc 11.4.1 (from RHEL9). I see one more warning than Tatsuo-san did: In file included from verify_heapam.c:18: verify_heapam.c: In function ‘check_tuple_attribute’: ../../src/include/access/toast_internals.h:37:11: war

Re: warning: dereferencing type-punned pointer

On 24.07.24 20:09, Tom Lane wrote: Peter Eisentraut writes: On 24.07.24 16:05, Tom Lane wrote: I'm not very thrilled with these changes. It's not apparent why your compiler is warning about these usages of IsA and not any other ones, I think one difference is that normally IsA is called on a

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

On 24.07.24 14:20, Robert Haas wrote: On Wed, Jul 24, 2024 at 12:42 AM Peter Eisentraut wrote: Fair enough. My argument was, that topic is distinct from the topic of this thread. OK, that's fair. But I think the solutions are the same: we complain all the time about glibc and ICU shipping co

Re: warning: dereferencing type-punned pointer

Peter Eisentraut writes: > On 24.07.24 16:05, Tom Lane wrote: >> I'm not very thrilled with these changes. It's not apparent why >> your compiler is warning about these usages of IsA and not any other >> ones, > I think one difference is that normally IsA is called on a Node * (since > you call

Re: warning: dereferencing type-punned pointer

On 24.07.24 16:05, Tom Lane wrote: I'm not very thrilled with these changes. It's not apparent why your compiler is warning about these usages of IsA and not any other ones, I think one difference is that normally IsA is called on a Node * (since you call IsA to decide what to cast it to), bu

Re: warning: dereferencing type-punned pointer

Peter Eisentraut writes: > This is basically the textbook example of aliasing violation, isn't it? > Wouldn't it be just as simple to do > memcpy(&file_crc, &disk_state, sizeof(file_crc)); +1. Also, it seems thoroughly bizarre to me that this case is handled before checking for read failure.

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

On Wed, 2024-07-24 at 08:20 -0400, Robert Haas wrote: > I note in passing that the last time I saw a customer query with > UPPER() in the join clause was... yesterday. Can you expand on that? This thread is mostly about durable state so I don't immediately see the connection. > So I don't want to

Re: warning: dereferencing type-punned pointer

On 24.07.24 08:55, Tatsuo Ishii wrote: origin.c: In function ‘StartupReplicationOrigin’: origin.c:773:16: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] 773 |file_crc = *(pg_crc32c *) &disk_state; |^~~

Re: Fixing backslash dot for COPY FROM...CSV

Sutou Kouhei writes: > I read through this thread. It seems that this thread > discuss 2 things: > 1. \. in CSV mode > 2. \. in non-CSV mode > Recent messages discussed mainly 2. but how about create a > separated thread for 2.? Because the original mail focused > on 1. and it seems that we can ha

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

On Tue, 2024-07-23 at 06:31 -0600, 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 versi

Re: Detect buffer underflow in get_th()

24.07.2024 18:39, Peter Eisentraut wrote: If it can't happen in practice, maybe an assertion would be enough? In practice, the function should not receive non-numeric strings either; however, since there is an exception in place for such cases, I thought it would be good to add a check for

Re: proposal: schema variables

On Wed, 2024-07-24 at 17:19 +0200, Pavel Stehule wrote: > >   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:  The resul

Re: Convert sepgsql tests to TAP

On 7/24/24 12:36, Tom Lane wrote: Peter Eisentraut writes: In my experience, the tests (both the old and the proposed new) only work on Red Hat-like platforms. I had also tried on Debian but decided that it won't work. Yeah, Red Hat is pretty much the only vendor that has pushed SELinux far

Re: Convert sepgsql tests to TAP

Peter Eisentraut writes: > In my experience, the tests (both the old and the proposed new) only > work on Red Hat-like platforms. I had also tried on Debian but decided > that it won't work. Yeah, Red Hat is pretty much the only vendor that has pushed SELinux far enough to be usable by non-wiz

Re: Convert sepgsql tests to TAP

On 7/24/24 6:31 PM, Peter Eisentraut wrote: On 24.07.24 18:29, Andreas Karlsson wrote: Peter, what did you do to get the tests running? And should we fix these tests to make them more user friendly? In my experience, the tests (both the old and the proposed new) only work on Red Hat-like plat

Re: pg_upgrade and logical replication

On Wed, Jul 24, 2024 at 11:32:47AM +0530, Amit Kapila wrote: > LGTM. Thanks for reviewing. Committed and back-patched to v17. -- nathan

Re: Convert sepgsql tests to TAP

On 24.07.24 16:31, Andreas Karlsson wrote: I took a quick look at the patch and I like that we standardize things a bit. But one thing I am not a fan of are all the use of sed and awk in the Perl script. I would prefer if that logic happened all in Perl, especially since we have some of it in P

Re: Convert sepgsql tests to TAP

On 24.07.24 18:29, Andreas Karlsson wrote: On 7/24/24 4:31 PM, Andreas Karlsson wrote: I have not yet set up an VM with selinux to try the patch out for real but will do so later. I almost got the tests running but it required way too many manual steps to just get there and I gave up after ju

Re: Convert sepgsql tests to TAP

On 7/24/24 4:31 PM, Andreas Karlsson wrote: I have not yet set up an VM with selinux to try the patch out for real but will do so later. I almost got the tests running but it required way too many manual steps to just get there and I gave up after just getting segfaults. I had to edit sepgsql

Re: Make query cancellation keys longer

On 04/07/2024 15:20, Jelte Fennema-Nio wrote: On Thu, 4 Jul 2024 at 12:32, Heikki Linnakangas wrote: We currently don't do any locking on the ProcSignal array. For query cancellations, that's good because a query cancel packet is processed without having a PGPROC entry, so we cannot take LWLock

Re: Inconsistency between try_mergejoin_path and create_mergejoin_plan

Richard Guo writes: > Thank you for confirming. Here is an updated patch with some tweaks to > the comments and commit message. I've parked this patch in the July > commitfest. I took a brief look at this. I think the basic idea is sound, but I have a couple of nits: * It's not entirely obvio

Re: Wrong security context for deferred triggers?

po 8. 7. 2024 v 14:36 odesílatel Laurenz Albe napsal: > On 7/8/24 04:14, Joseph Koshakow wrote: > > Given the above and the fact that the patch is a breaking change, my > > vote would still be to keep the current behavior and update the > > documentation. Though I'd be happy to be overruled by so

Re: tests fail on windows with default git settings

Hi On Sat, 13 Jul 2024 at 23:01, Thomas Munro wrote: > On Fri, Jul 12, 2024 at 3:49 AM Dave Page wrote: > > So I received an off-list tip to checkout [1], a discussion around > GSSAPI causing test failures on windows that Alexander Lakhin was looking > at. Thomas Munro's v2 patch to try to addr

Re: Built-in CTYPE provider

On Wed, Jul 24, 2024 at 9:27 AM Peter Eisentraut wrote: > > The last vote arrived 6 days ago. So far, we have votes from Jeff, > Noah, Tom, > > Daniel, and Laurenz. I'll keep the voting open for another 24 hours > from now > > or 36 hours after the last vote, whichever comes last. If that sche

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

Amit Kapila writes: > I merged these changes, made a few other cosmetic changes, and pushed the > patch. There is a CF entry pointing at this thread [1]. Should it be closed? regards, tom lane [1] https://commitfest.postgresql.org/48/4867/

Re: Support prepared statement invalidation when result types change

Jelte Fennema writes: > The cached plan for a prepared statements can get invalidated when DDL > changes the tables used in the query, or when search_path changes. > ... > However, we would throw an error if the the result of the query is of a > different type than it was before: > ERROR: cached p

Re: Detect buffer underflow in get_th()

On 24.07.24 11:43, Alexander Kuznetsov wrote: Hello everyone, In src/backend/utils/adt/formatting.c:1516, there is a get_th() function utilized to return ST/ND/RD/TH suffixes for simple numbers. Upon reviewing its behavior, it appears capable of receiving non-numeric inputs (this is verified b

Re: Built-in CTYPE provider

On 7/24/24 11:19, Noah Misch wrote: On Wed, Jul 17, 2024 at 03:03:26PM -0700, Noah Misch wrote: On Wed, Jul 17, 2024 at 08:48:46AM -0700, Jeff Davis wrote: > you have something in mind, please propose it. However, this feature > followed the right policies at the time of commit, so there would n

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

On 24.07.24 07:04, Michael Paquier wrote: This commit introduces three additional commands: \parse, \bindx and \close. \parse creates a prepared statement using extended protocol. \bindx binds and execute an existing prepared statement using extended protocol. \close closes an existing prepared s

Re: Built-in CTYPE provider

On 24.07.24 17:19, Noah Misch wrote: On Wed, Jul 17, 2024 at 03:03:26PM -0700, Noah Misch wrote: On Wed, Jul 17, 2024 at 08:48:46AM -0700, Jeff Davis wrote: On Thu, 2024-07-11 at 05:50 -0700, Noah Misch wrote: This is still marked as an open item for 17, but you've already acknowledged[1] that

Re: Built-in CTYPE provider

On Wed, Jul 17, 2024 at 03:03:26PM -0700, Noah Misch wrote: > On Wed, Jul 17, 2024 at 08:48:46AM -0700, Jeff Davis wrote: > > On Thu, 2024-07-11 at 05:50 -0700, Noah Misch wrote: > > > > This is still marked as an open item for 17, but you've already > > > > acknowledged[1] that no code changes are

Re: Meson far from ready on Windows

On Sat, 20 Jul 2024 at 21:56, Andres Freund wrote: > Hi, > > On 2024-07-17 09:49:47 -0700, Andres Freund wrote: > > On 2024-07-16 15:53:45 -0500, Tristan Partin wrote: > > > Other than that, it looks pretty solid. > > > > Thanks for looking! I'm thinking of pushing the first few patches > soon-i

Re: [PATCH] Add min/max aggregate functions to BYTEA

Added patch to commitfest https://commitfest.postgresql.org/49/5138/ -- With best regards, Marat Bukharov > > Hi, > > > What part of commitfest should I put the current patch to: "SQL > > Commands", "Miscellaneous" or something else? I can't figure it out. > > Personally I qualified a similar pa

Re: [PATCH] Add min/max aggregate functions to BYTEA

V5 patch. I've added more tests with different bytea sizes -- With best regards, Marat Bukharov чт, 4 июл. 2024 г. в 15:29, Aleksander Alekseev : > > Hi Marat, > > > V4 path with fixed usage PG_GETARG_BYTEA_PP instead of PG_GETARG_TEXT_PP > > Thanks for the patch. > > Please add it to the neares

Re: Convert sepgsql tests to TAP

I took a quick look at the patch and I like that we standardize things a bit. But one thing I am not a fan of are all the use of sed and awk in the Perl script. I would prefer if that logic happened all in Perl, especially since we have some of it in Perl (e.g. chomp). Also I wonder if we shoul

pg_upgrade adds unexpected pg_constraint entries to pg_depend

I've noticed that after running `pg_upgrade` that my `pg_depend` table contains unexpected dependencies for sequences. Before the upgrade from PostgreSQL 15.7: ``` % psql -d gitlabhq_production psql (16.3, server 15.7) Type "help" for help. gitlabhq_production=# SELECT seq_pg_class.relname AS seq

Re: pg_upgrade failing for 200+ million Large Objects

On Mon, Apr 01, 2024 at 03:28:26PM -0400, Tom Lane wrote: > Nathan Bossart writes: > > The one design point that worries me a little is the non-configurability of > > --transaction-size in pg_upgrade. I think it's fine to default it to 1,000 > > or something, but given how often I've had to fiddl

Re: [PATCH] GROUP BY ALL

On Tue, Jul 23, 2024 at 6:53 PM David Christensen wrote: > > 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/fu

Re: warning: dereferencing type-punned pointer

Tatsuo Ishii writes: > So I think the warnings in ExecEvalJsonExprPath are better fixed > because these are the only places where IsA (nodeTag) macro are used > and the warning is printed. Patch attached. I'm not very thrilled with these changes. It's not apparent why your compiler is warning ab

Re: Send duration output to separate log files

Hi st 10. 7. 2024 v 17:58 odesílatel Greg Sabino Mullane napsal: > Please find attached a patch to allow for durations to optionally be sent > to separate log files. In other words, rather than cluttering up our > postgres202007.log file with tons of output from > log_min_duration_statement, dur

Re: improve ssl error code, 2147483650

On 25.06.24 16:21, Tom Lane wrote: Peter Eisentraut writes: On 21.06.24 16:53, Tom Lane wrote: Most of libpq gets at strerror_r via SOCK_STRERROR for Windows portability. Is that relevant here? Looking inside the OpenSSL code, it makes no efforts to translate between winsock error codes an

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

On Wed, Jul 24, 2024 at 6:20 AM Robert Haas wrote: > > I note in passing that the last time I saw a customer query with > UPPER() in the join clause was... yesterday. The problems there had > nothing to do with CTYPE, but there's no reason to suppose that it > couldn't have had such a problem. I

Re: Reducing the log spam

Hello Laurenz, I liked the idea for this patch. I will also go for the default being an empty string. I went through this patch and have some comments on the code, 1. In general, I don't like the idea of goto, maybe we can have a free_something function to call here. 2. if (!SplitIdentifierStrin

Re: apply_scanjoin_target_to_paths and partitionwise join

On Wed, Jul 24, 2024 at 9:42 AM Richard Guo wrote: > > 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 > discardin

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

On Tue, Jul 23, 2024 at 06:01:44PM +0900, Michael Paquier wrote: > 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 Slru

Sporadic connection-setup-related test failures on Cygwin in v15-

Hello hackers, A recent lorikeet (a Cygwin animal) failure [1] revealed one more long-standing (see also [2], [3], [4]) issue related to Cygwin:  SELECT dblink_connect('dtest1', connection_parameters()); - dblink_connect - - OK -(1 row) - +ERROR:  could not establish connection +D

Re: Interrupts vs signals

On 10/07/2024 09:48, Thomas Munro wrote: On Mon, Jul 8, 2024 at 9:38 PM Heikki Linnakangas wrote: The patch actually does both: it still does kill(SIGUSR1) and also sets the latch. Yeah, I had some ideas about supporting old extension code that really wanted a SIGUSR1, but on reflection, the

Re: Add privileges test for pg_stat_statements to improve coverage

On 2024/07/24 10:23, kuroda.keis...@nttcom.co.jp wrote: 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. Pushed. Thanks! Regards, --

Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

Hi All, Here is the v4 patch with the following new changes: 1) Now allows users to explicitly set search_path to $extension_schema. 2) Includes updates to the documentation. 3) Adds comments where previously absent. Note: The new control file parameter is currently named as "protected" which

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

On Wed, Jul 24, 2024 at 12:42 AM Peter Eisentraut wrote: > Fair enough. My argument was, that topic is distinct from the topic of > this thread. OK, that's fair. But I think the solutions are the same: we complain all the time about glibc and ICU shipping collations and not versioning them. We s

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

Hi, > It took me a couple of days to get back to it, but attached is what I > have finished with. This was mostly OK, except for a few things: > - \close was inconsistent with the other two commands, where no > argument was treated as the unnamed prepared statement. I think that > this should be

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

On Wed, Jul 24, 2024 at 2:42 PM John Naylor wrote: > As for lowering the limit, we've experimented with 256kB here: > > https://www.postgresql.org/message-id/canwcazzutvz3lsypauyqvzcezxz7qe+9ntnhgyzdtwxpul+...@mail.gmail.com > > As I mention there, going lower than that would need a small amount o

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

On Tue, Jul 23, 2024 at 01:07:49PM -0700, Jeff Davis wrote: > On Tue, 2024-07-23 at 07:39 -0700, Noah Misch wrote: > > Short-term, we should remedy the step backward that pg_c_utf8 has taken: > > https://postgr.es/m/20240718233908.52.nmi...@google.com > > https://postgr.es/m/486d71991a3f80ec1c47e1b

RE: [Proposal] Add foreign-server health checks infrastructure

Dear Fujii-san, > On 2024/07/18 19:49, Hayato Kuroda (Fujitsu) wrote: > >> Shouldn't this test also check if the returned user_name is valid? > > > > You meant to say that we should print the user_name, right? Done. > > Yes, I think it's better to test if the value in the user_name column is as

Re: PG buildfarm member cisticola

On 2024-Jul-24, Alvaro Herrera wrote: > be-secure-openssl.c:(.text+0x1f8c): undefined reference to `ERR_new' > be-secure-openssl.c:(.text+0x1fa4): undefined reference to `ERR_set_debug' > be-secure-openssl.c:(.text+0x1fb8): undefined reference to `ERR_set_error' > be-secure-openssl.c:(.text+0x2010

Re: [PATCH] GROUP BY ALL

> On 24 Jul 2024, at 13:58, Jelte Fennema-Nio wrote: > > On Tue, 23 Jul 2024 at 15:22, Andrei Borodin wrote: >> I'd like to have GROUP BY AUTO (I also proposed version GROUP BY SURPRISE >> ME). But I wouldn't like to open pandora box of syntax sugar extensions >> which may will be incompati

Re: Removing unneeded self joins

On Sat, 20 Jul 2024 at 12:39, Alexander Korotkov wrote: > > > The new function replace_relid() looks to be the same as adjust_relid_set(). > > They are similar, not the same. replace_relid() has handling for > negative newId, while adjust_relid_set() hasn't. One thing I'd like > to borrow from a

PG buildfarm member cisticola

Hello A couple of days ago, PG buildfarm member cisticola started failing: https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=cisticola&br=HEAD The failures[1] are pretty mysterious: make[3]: \347\246\273\345\274\200\347\233\256\345\275\225\342\200\234/home/postgres/buildfarm/HEAD/pgsq

Re: Speed up JSON escape processing with SIMD plus other optimisations

On 02/07/2024 07:49, David Rowley wrote: I've attached a rebased set of patches. The previous set no longer applied. I looked briefly at the first patch. Seems reasonable. One little thing that caught my eye is that in populate_scalar(), you sometimes make a temporary copy of the string to a

  1   2   >