Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.

On Thu, Dec 12, 2024 at 8:14 AM Hayato Kuroda (Fujitsu) wrote: > > Dear Shubham, > > > Thank you for pointing this out and for suggesting the changes. I > > agree with your approach. > > Also, I found a mistake in getopt_long and fixed it in this version of > > the patch. > > The attached patch co

Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.

On Thu, Dec 12, 2024 at 6:04 AM Peter Smith wrote: > > Hi Shubham, > > Here are some review comments for the patch v4-0001. > > == > GENERAL. > > 1. > After reading Vignesh's last review and then the pg_createsubscriber > documentation I see there can be multiple databases simultaneously > spe

Re: attndims, typndims still not enforced, but make the value within a sane threshold

hi. remove pg_type typndims column patch attached. From 656fc3bec597f65368a7bd1cdee183865d4070e7 Mon Sep 17 00:00:00 2001 From: jian he Date: Thu, 12 Dec 2024 15:27:34 +0800 Subject: [PATCH v3 1/1] remove pg_type typndims discussion: https://postgr.es/m/CACJufxH0RxsxUQnAT2AVG08JFpA3C60L91_cEMM8JQ

Re: Logical replication timeout

On Wed, 11 Dec 2024 at 14:29, RECHTÉ Marc wrote: > > This how to reproduce the problem. > > Session 1: > > psql -c "CREATE TABLE test (i int)" -c "INSERT INTO test SELECT > generate_series(1, 2_000_000)" > > Session 2: > > pg_recvlogical -d postgres --slot=test --create-slot > pg_recvlogical -d

Re: confusing / inefficient "need_transcoding" handling in copy

Hi, In "Re: confusing / inefficient "need_transcoding" handling in copy" on Tue, 10 Dec 2024 13:59:25 +0900, Michael Paquier wrote: > client_encoding would be used by COPY when not specifying ENCODING > option. Perhaps more tests should be added with this value specified > by a SET client

Re: Difference in dump from original and restored database due to NOT NULL constraints on children

Hi Alvaro, On Thu, Nov 28, 2024 at 4:47 PM Ashutosh Bapat wrote: > > On Thu, Nov 28, 2024 at 4:44 PM Ashutosh Bapat > wrote: > > > > On Wed, Nov 27, 2024 at 7:04 PM Alvaro Herrera > > wrote: > > > > > > On 2024-Nov-27, Ashutosh Bapat wrote: > > > > > > > I noticed that. But two reasons why I c

Re: Skip collecting decoded changes of already-aborted transactions

On Thu, Dec 12, 2024 at 11:08 AM Amit Kapila wrote: > > On Wed, Dec 11, 2024 at 8:21 AM Dilip Kumar wrote: > > > > On Wed, Dec 11, 2024 at 3:18 AM Masahiko Sawada > > wrote: > > > > > > On Mon, Dec 9, 2024 at 10:19 PM Dilip Kumar wrote: > > > > > > > > > > > > If the largest transaction is non

Re: Memory leak in WAL sender with pgoutput (v10~)

On Wed, Dec 11, 2024 at 11:09 AM Masahiko Sawada wrote: > > On Tue, Dec 10, 2024 at 6:13 PM Zhijie Hou (Fujitsu) > wrote: > > > > On Wednesday, December 11, 2024 2:14 AM Masahiko Sawada > > wrote: > > > > > > On Tue, Dec 10, 2024 at 1:16 AM Amit Kapila > > > wrote: > > > > > > > > On Tue, Dec

Re: Skip collecting decoded changes of already-aborted transactions

On Wed, Dec 11, 2024 at 8:21 AM Dilip Kumar wrote: > > On Wed, Dec 11, 2024 at 3:18 AM Masahiko Sawada wrote: > > > > On Mon, Dec 9, 2024 at 10:19 PM Dilip Kumar wrote: > > > > > > > > > If the largest transaction is non-streamable, won't the transaction > > > > returned by ReorderBufferLargestT

Re: Fix comments related to pending statistics

Hi, On Thu, Dec 12, 2024 at 09:20:15AM +0900, Michael Paquier wrote: > On Wed, Dec 11, 2024 at 07:32:38AM +, Bertrand Drouvot wrote: > > On Wed, Dec 11, 2024 at 02:56:08PM +0900, Michael Paquier wrote: > >> Your suggestion does not look completely right to me. There is > >> nothing preventing

Re: pg_createsubscriber TAP test wrapping makes command options hard to read.

On Thu, Dec 12, 2024 at 03:24:42PM +1100, Peter Smith wrote: > PSA v2-0001. This time it can survive pgperltidy unchanged. Confirmed. It looks to apply cleanly to v17 as well. Better to backpatch to avoid conflict frictions, even if it's cosmetic. > In passing I also removed the duplicated '--v

Re: per backend I/O statistics

On Mon, Nov 25, 2024 at 03:47:59PM +, Bertrand Drouvot wrote: > === Remarks > > R1: as compared to v5, v6 removes the per-backend I/O stats reset from > pg_stat_reset_shared(). I think it makes more sense that way, since we are > adding pg_stat_reset_single_backend_io_counters(). The per-back

Re: COPY performance on Windows

On Thu, Dec 12, 2024 at 1:18 AM Ryohei Takahashi (Fujitsu) wrote: > The performance of PG16.6 and PG17.0 are worse than PG16.4. > So, I think the commits between August and September affects the performance. > I will analyze these commits. If it reproduces reliably, maybe git bisect? Do you have

Re: Pass ParseState as down to utility functions.

On Thu, Dec 12, 2024 at 10:29 AM Michael Paquier wrote: > > I think that the patch should be split a bit more. Even if different > areas of the code are touched, there's more than one idea of how to > create this information for the error position, so each piece could be > committed separately wi

Re: Track the amount of time waiting due to cost_delay

Hi, On Wed, Dec 11, 2024 at 10:40:04AM -0600, Nathan Bossart wrote: > That's roughly what I had in mind. Thanks for confirming, done that way in v11 attached. > I'd vote for leaving that out, if for no other reason than it can be > deduced from the rest of the description. Yeah, fair enough. R

Re: Add Postgres module info

On 12/12/24 10:44, Michael Paquier wrote: On Wed, Dec 11, 2024 at 10:39:38PM -0500, Tom Lane wrote: Michael Paquier writes: Presumably, the extra tracking can be done in dfmgr.c with more fields added to DynamicFileList to track the information involved. I wouldn't add any overhead to the no

Re: pg_createsubscriber TAP test wrapping makes command options hard to read.

On Thu, Dec 12, 2024 at 2:53 PM Michael Paquier wrote: ... > > So, AFAICT I can workaround the perltidy wrapping just by putting all > > the noarg options at the bottom of the command, then all the > > option/optarg pairs (ie 2s) will stay together. I can post another > > patch to do it this way

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

On Tue, 10 Dec 2024 at 17:21, Nisha Moond wrote: > > On Fri, Dec 6, 2024 at 11:04 AM vignesh C wrote: > > > > > > Determining the correct time may be challenging for users, as it > > depends on when the active_since value is set, as well as when the > > checkpoint_timeout occurs and the subsequen

Re: per backend I/O statistics

On Wed, Nov 27, 2024 at 04:00:14PM +, Bertrand Drouvot wrote: > I'd vote to just keep the pgstat_create_backend_stat() call in > pgstat_beinit(). > > That said, we probably should document that init_backend_cb() should not call > pgstat_get_entry_ref(), but that's probably worth another threa

Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.

On Thu, 12 Dec 2024 at 08:14, Hayato Kuroda (Fujitsu) wrote: > > Dear Shubham, > > > Thank you for pointing this out and for suggesting the changes. I > > agree with your approach. > > Also, I found a mistake in getopt_long and fixed it in this version of > > the patch. > > The attached patch cont

Re: pg_createsubscriber TAP test wrapping makes command options hard to read.

On Thu, Dec 12, 2024 at 02:13:40PM +1100, Peter Smith wrote: > TBH, I have no idea what logic perltidy uses. I did find some > configurations here [1] (are those what it pgperltidy uses?) but those > claim max line length is 78 which I didn't come anywhere near > exceeding. Gave up trying to under

Re: Statistics Import and Export

> > +1, assuming such an option is wanted at all. I suppose it should be > there for the unlikely (and hopefully impossible) case that statistics > are causing a problem during upgrade. > Here you go, rebased and re-ordered: 0001-0004 are the pg_dump/pg_upgrade related patches. 0005 is an optimiz

Re: Add Postgres module info

On Wed, Dec 11, 2024 at 10:39:38PM -0500, Tom Lane wrote: > Michael Paquier writes: >> Presumably, >> the extra tracking can be done in dfmgr.c with more fields added to >> DynamicFileList to track the information involved. > > I wouldn't add any overhead to the normal case for this. Couldn't >

Re: Add Postgres module info

Michael Paquier writes: > On Wed, Dec 11, 2024 at 08:34:28PM -0500, Tom Lane wrote: >> What would you foresee as the SQL API for inspecting a module that's >> not tied to an extension? > Rather than a function that can be called with a specific module name > in input, invent a new system SRF func

Re: Remove useless GROUP BY columns considering unique index

On 12/12/24 10:09, David Rowley wrote: On Mon, 2 Dec 2024 at 17:18, Andrei Lepikhov wrote: Patch 0002 looks helpful and performant. I propose to check 'relid > 0' to avoid diving into 'foreach(lc, parse->rtable)' at all if nothing has been found. I did end up adding another fast path there, b

Re: Fix early elog(FATAL)

On Tue, Dec 10, 2024 at 04:18:19PM -0600, Nathan Bossart wrote: > On Sat, Dec 07, 2024 at 07:46:14PM -0800, Noah Misch wrote: > > Three ways to fix this: > > I noticed that you committed a fix for this. Sorry for not responding > earlier. > > > 1. Call InitProcessGlobals() earlier. This could a

Re: Add Postgres module info

On Wed, Dec 11, 2024 at 08:34:28PM -0500, Tom Lane wrote: > "Euler Taveira" writes: >> +1 for the general idea. I received some reports like [1] related to wal2json >> that people wants to obtain the output plugin version. Since it is not >> installed >> via CREATE EXTENSION, it is not possible t

Re: FileFallocate misbehaving on XFS

Hi Andres On Thu, 12 Dec 2024 at 10:50, Andres Freund wrote: > Just to make sure - you're absolutely certain that you actually have space at > the time of the errors? As sure as I can be. The RHEL8 system that I took prints from yesterday has > 1.5TB free. I can't see it varying by that much. I

Re: pg_createsubscriber TAP test wrapping makes command options hard to read.

On Thu, Dec 12, 2024 at 1:46 PM Tom Lane wrote: > > Peter Smith writes: > > The strange thing is there are other commands in that file very > > similar to the ones I had changed but those already looked good, yet > > they remained unaffected by the pgperltidy. Why? > > You sure it's not just luck

Re: Remove useless GROUP BY columns considering unique index

On Mon, 2 Dec 2024 at 17:18, Andrei Lepikhov wrote: > Patch 0002 looks helpful and performant. I propose to check 'relid > 0' > to avoid diving into 'foreach(lc, parse->rtable)' at all if nothing has > been found. I did end up adding another fast path there, but I felt like checking relid > 0 was

Re: Remove useless GROUP BY columns considering unique index

On Mon, 2 Dec 2024 at 17:22, jian he wrote: > regarding v10. > you placed remove_useless_groupby_columns right after add_base_rels_to_query > makes so much sense. > so we can be safely use cached RelOptInfo->indexlist, > RelOptInfo->notnullattnums > overall it didn't find any issue. Thanks for l

Re: not null constraints, again

On Wed, Dec 4, 2024 at 10:52 AM jian he wrote: > > hi. > > heap_create_with_catalog argument (cooked_constraints): > passed as NIL in function {create_toast_table, make_new_heap} > passed as list_concat(cookedDefaults,old_constraints) in DefineRelation > > in DefineRelation we have function call:

Re: pg_createsubscriber TAP test wrapping makes command options hard to read.

Peter Smith writes: > The strange thing is there are other commands in that file very > similar to the ones I had changed but those already looked good, yet > they remained unaffected by the pgperltidy. Why? You sure it's not just luck-of-the-draw? I think that perltidy is just splitting the lin

Re: Wrong results with right-semi-joins

On Wed, Dec 11, 2024 at 11:27 AM Richard Guo wrote: > I spent some time on this and came up with a simpler query to > reproduce the issue. > > explain (costs off) > select * from tbl_rs t1 join > lateral (select * from tbl_rs t2 where t2.a in > (select t1.a+t3.a from tbl_rs t3) and t

RE: Adding a '--two-phase' option to 'pg_createsubscriber' utility.

Dear Shubham, > Thank you for pointing this out and for suggesting the changes. I > agree with your approach. > Also, I found a mistake in getopt_long and fixed it in this version of > the patch. > The attached patch contains the suggested changes. Thanks for updating the patch. I think the patch

Re: Pass ParseState as down to utility functions.

On Thu, Dec 12, 2024 at 4:48 AM Tom Lane wrote: > > jian he writes: > > add parser_errposition to some places in > > transformTableConstraint, transformColumnDefinition > > where v8 didn't. > > I'm not loving the idea of cons'ing up ParseStates in random places in > tablecmds.c. I think we ought

Re: pg_createsubscriber TAP test wrapping makes command options hard to read.

On Thu, Dec 12, 2024 at 12:41 PM Tom Lane wrote: > > Peter Smith writes: > > While reviewing a patch for another pg_createsubscriber thread I found > > that multiple TAP tests have a terrible wrapping where the command > > options and their associated oparg are separated on different lines > > in

Re: CRC32C Parallel Computation Optimization on ARM

On Wed, Dec 11, 2024 at 11:54 PM Nathan Bossart wrote: > > On Wed, Dec 11, 2024 at 02:08:58PM +0700, John Naylor wrote: > > and how light it was. With more hardware support, we can go much lower > > than 1024 bytes, but that can be left for future work. > > Nice. I'm curious how this compares to

Re: Pass ParseState as down to utility functions.

On Thu, Dec 12, 2024 at 10:08:04AM +0800, jian he wrote: > On Thu, Dec 12, 2024 at 4:48 AM Tom Lane wrote: >> I'm not loving the idea of cons'ing up ParseStates in random places in >> tablecmds.c. I think we ought to fix things so that the one made in >> standard_ProcessUtility is passed down to

Re: Pass ParseState as down to utility functions.

On Tue, Dec 10, 2024 at 10:38:41PM +0800, jian he wrote: > add parser_errposition to some places in > transformTableConstraint, transformColumnDefinition > where v8 didn't. I've looked at the new tests in 0001. Here are some notes. And I've found some mistakes and simplifications on the way. C

Re: Add support to TLS 1.3 cipher suites and curves lists

On 12/11/24 10:14 AM, Daniel Gustafsson wrote: On 11 Dec 2024, at 18:47, Tom Lane wrote: Oh yay, another naming problem :-(. I think that neither "ciphers" vs. "cipher suites" nor "ssl_ciphers" vs. "ssl_ciphers_tlsv13" is going to convey a lot to the average person who's not steeped in TLS m

Re: Add Postgres module info

Andrei Lepikhov writes: > It makes sense. But I want to clarify that I avoided changing > PG_MODULE_MAGIC because the newly introduced structure has a totally > different purpose and usage logic: the struct is designed to check > compatibility, but module info isn't connected to the core versio

Re: pg_createsubscriber TAP test wrapping makes command options hard to read.

Peter Smith writes: > While reviewing a patch for another pg_createsubscriber thread I found > that multiple TAP tests have a terrible wrapping where the command > options and their associated oparg are separated on different lines > instead of paired together nicely. This makes it unnecessarily >

Re: Add Postgres module info

"Euler Taveira" writes: > +1 for the general idea. I received some reports like [1] related to wal2json > that people wants to obtain the output plugin version. Since it is not > installed > via CREATE EXTENSION, it is not possible to detect what version is installed, > hence, some tools cannot h

pg_createsubscriber TAP test wrapping makes command options hard to read.

Hi, While reviewing a patch for another pg_createsubscriber thread I found that multiple TAP tests have a terrible wrapping where the command options and their associated oparg are separated on different lines instead of paired together nicely. This makes it unnecessarily difficult to see what the

Re: Add Postgres module info

On 12/12/2024 01:21, Tom Lane wrote: Andrei Lepikhov writes: I would like to propose the module_info structure, which aims to let extension maintainers sew some data into the binary file. Being included in the module code, this information remains unchanged and is available for reading by a bac

Re: Add Postgres module info

On Wed, Dec 11, 2024, at 4:26 PM, Andres Freund wrote: > On 2024-12-11 13:21:03 -0500, Tom Lane wrote: > > Andrei Lepikhov writes: > > > I would like to propose the module_info structure, which aims to let > > > extension maintainers sew some data into the binary file. Being included > > > in the

Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.

Hi Shubham, Here are some review comments for the patch v4-0001. == GENERAL. 1. After reading Vignesh's last review and then the pg_createsubscriber documentation I see there can be multiple databases simultaneously specified (by writing multiple -d switches) and in that case each one gets i

Buffering in tuplesort.c for in-sort deduplication; nbtree edition

Hi, In the GIN parallel build thread [0] I proposed adding a 'flush' callback to the tuplesort API [1], to be called by the tuplesort machinery after writing each run, so that users of tuplesort can buffer write calls within each sorted run and use that buffer state to merge/deduplicate sorttuples

Re: Fix comments related to pending statistics

On Wed, Dec 11, 2024 at 07:32:38AM +, Bertrand Drouvot wrote: > On Wed, Dec 11, 2024 at 02:56:08PM +0900, Michael Paquier wrote: >> Your suggestion does not look completely right to me. There is >> nothing preventing us from using something else than event counters >> since we don't use memcpy

Re: FileFallocate misbehaving on XFS

Hi, FWIW, I tried fairly hard to reproduce this. An extended cycle of 80 backends copying into relations and occasionally truncating them (to simulate the partitions being dropped and new ones created). For this I ran a 4TB filesystem very close to fully filled (peaking at 99.998 % full). I did

Re: Pre-proposal: unicode normalized text

On Thu, 2024-02-29 at 17:02 -0800, Jeff Davis wrote: > Attached is an implementation of a per-database option STRICT_UNICODE > which enforces the use of assigned code points only. I'm withdrawing this patch due to lack of interest. Regards, Jeff Davis

Re: Add Pipelining support in psql

On Tue, 10 Dec 2024 at 11:44, Anthonin Bonnefoy wrote: > num_queries (2nd element in the pipeline status prompt) is now used to > track queued queries that were not flushed (with a flush request or > sync) to the server. It used to count both unflushed queries and > flushed queries. I skimmed the

Re: connection establishment versus parallel workers

On Thu, Dec 12, 2024 at 11:36 AM Thomas Munro wrote: > ... instead of > reporting only the lowest priority one) s/priority/position/

Re: connection establishment versus parallel workers

On Thu, Dec 12, 2024 at 9:43 AM Nathan Bossart wrote: > My team recently received a report about connection establishment times > increasing substantially from v16 onwards. Upon further investigation, > this seems to have something to do with commit 7389aad (which moved a lot > of postmaster code

Re: Assert failure on running a completed portal again

On Tue, Dec 10, 2024 at 4:45 PM Tom Lane wrote: > Anyway, if you feel like rewriting that stuff, step right up. > My feeling about it is that the law of conservation of cruft > will prevent a replacement from being all that much cleaner, > but maybe I'm wrong. Thanks for the thoughts. It's always

Re: VACUUM cleaning of CF 2024-11

> On 11 Dec 2024, at 06:17, Michael Paquier wrote: > I've done a pass over the CF app, and did some routine vacuuming of > the whole. FWIW, thank you very much for doing that! -- Daniel Gustafsson

Re: [BUG] Possible occurrence of segfault in ecpg test

Daniil Davydov <3daniss...@gmail.com> writes: > Thus, if the program behaves in an unexpected way and the transaction > is aborted before it executes the > "select data1 into :recv_vlen_buf from test" query, dump_binary will > refer to a null pointer. So, instead of an error > message, the user wil

Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE

On Thu, 12 Dec 2024 at 00:16, David Rowley wrote: > There were a few places that were missing a BUFFERS OFF as indicated > by the buildfarm. I've fixed a few of these, but there's at least one > more in pg_stat_statements's level_tracking.sql. I'm currently running > a -DRELCACHE_FORCE_RELEASE -DC

Re: Pass ParseState as down to utility functions.

jian he writes: > add parser_errposition to some places in > transformTableConstraint, transformColumnDefinition > where v8 didn't. I'm not loving the idea of cons'ing up ParseStates in random places in tablecmds.c. I think we ought to fix things so that the one made in standard_ProcessUtility i

Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE

Le mer. 11 déc. 2024 à 21:41, Jelte Fennema-Nio a écrit : > On Wed, 11 Dec 2024 at 10:38, David Rowley wrote: > > I've pushed the main patch. I'm not planning on pushing the > > auto_explain.log_buffers default change unless there's a bit more > > discussion about it. > > FreeBSD CFBot seems bro

connection establishment versus parallel workers

My team recently received a report about connection establishment times increasing substantially from v16 onwards. Upon further investigation, this seems to have something to do with commit 7389aad (which moved a lot of postmaster code out of signal handlers) in conjunction with workloads that gen

Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE

On Wed, 11 Dec 2024 at 10:38, David Rowley wrote: > I've pushed the main patch. I'm not planning on pushing the > auto_explain.log_buffers default change unless there's a bit more > discussion about it. FreeBSD CFBot seems broken on a pg_stat_statements test because of this change: https://api.c

Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE

Le mer. 11 déc. 2024 à 15:00, jian he a écrit : > do we also need to update doc/src/sgml/rules.sgml? > > https://www.postgresql.org/docs/current/rules-materializedviews.html > Yes, you're right. Here is a fix. (Not a patch with a commit message as I don't know if David will want to commit everyt

Re: Make use of pg_memory_is_all_zeros() in more places

Committed. -- nathan

Re: Add Postgres module info

Andres Freund writes: > On 2024-12-11 13:21:03 -0500, Tom Lane wrote: >> There are a couple of ways that we could deal with the API >> seen by module authors: > To be future proof, I think it'd be good to declare the arguments as > designated initializers. E.g. like > PG_MODULE_MAGIC_EXT( > .v

Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans)

On Sat, Nov 9, 2024 at 1:46 PM Peter Geoghegan wrote: > On Sat, Nov 9, 2024 at 12:37 PM Alena Rybakina > wrote: > > I noticed that the "Index Searches" cases shown in the regression tests are > > only for partitioned tables, maybe something you should add some tests for > > regular tables like

Re: Add Postgres module info

Hi, On 2024-12-11 13:21:03 -0500, Tom Lane wrote: > Andrei Lepikhov writes: > > I would like to propose the module_info structure, which aims to let > > extension maintainers sew some data into the binary file. Being included > > in the module code, this information remains unchanged and is avai

Re: Unmark gen_random_uuid() function leakproof

On Tue, Dec 10, 2024 at 1:52 PM Masahiko Sawada wrote: > > On Mon, Dec 9, 2024 at 2:48 PM Masahiko Sawada wrote: > > > > On Mon, Dec 9, 2024 at 2:23 PM Andres Freund wrote: > > > > > > Hi, > > > > > > On 2024-12-09 14:10:30 -0800, Masahiko Sawada wrote: > > > > While reviewing UUIDv7 patch[1], I

Re: Count and log pages set all-frozen by vacuum

On Thu, Dec 5, 2024 at 4:32 PM Melanie Plageman wrote: > > On Mon, Dec 2, 2024 at 9:28 AM Robert Haas wrote: > > > > On Fri, Nov 29, 2024 at 2:46 PM Masahiko Sawada > > wrote: > > > Finally, in case where we have: > > > > > > visibility map: 1 pages set all-visible, 1 pages set all-froz

Re: Add support to TLS 1.3 cipher suites and curves lists

On Wed, Dec 11, 2024 at 12:47:01PM -0500, Tom Lane wrote: > Jacob Champion writes: >> On Wed, Dec 11, 2024 at 9:11 AM Nathan Bossart >> wrote: >>> Sorry for chiming in so late here, but I was a little surprised to see the >>> TLS version in the GUC name. ISTM this would require us to create a n

Re: SCRAM pass-through authentication for postgres_fdw

Em qua., 4 de dez. de 2024 às 20:39, Jacob Champion escreveu: > > On Wed, Dec 4, 2024 at 3:05 PM Jelte Fennema-Nio wrote: > > I only see advantages over the > > alternative, which is copying the plaintext password around. In case > > of compromise of the server, only the salt+verifier has to be r

Re: Document NULL

> > Em ter., 10 de dez. de 2024 às 20:00, David G. Johnston < > david.g.johns...@gmail.com> escreveu: > Section nullvalues-filtering you are showing filtering with equal and not equal. Wouldn't it be better if you show just one of them and the other using DISTINCT FROM, which would get different r

Re: Add Postgres module info

Andrei Lepikhov writes: > I would like to propose the module_info structure, which aims to let > extension maintainers sew some data into the binary file. Being included > in the module code, this information remains unchanged and is available > for reading by a backend. I don't have much of a

Re: Add support to TLS 1.3 cipher suites and curves lists

> On 11 Dec 2024, at 18:47, Tom Lane wrote: > Oh yay, another naming problem :-(. I think that neither "ciphers" > vs. "cipher suites" nor "ssl_ciphers" vs. "ssl_ciphers_tlsv13" is > going to convey a lot to the average person who's not steeped in > TLS minutiae. However, following the preceden

Re: Add support to TLS 1.3 cipher suites and curves lists

Jacob Champion writes: > On Wed, Dec 11, 2024 at 9:11 AM Nathan Bossart > wrote: >> Sorry for chiming in so late here, but I was a little surprised to see the >> TLS version in the GUC name. ISTM this would require us to create a new >> GUC for every new TLS version, or explain that ssl_tls13_c

Re: Add support to TLS 1.3 cipher suites and curves lists

On Wed, Dec 11, 2024 at 9:11 AM Nathan Bossart wrote: > Sorry for chiming in so late here, but I was a little surprised to see the > TLS version in the GUC name. ISTM this would require us to create a new > GUC for every new TLS version, or explain that ssl_tls13_ciphers isn't just > for 1.3. I

Re: CREATE SCHEMA ... CREATE DOMAIN support

Kirill Reshke writes: > On Wed, 4 Dec 2024 at 01:07, Tom Lane wrote: >> I'm totally willing to throw that possibility overboard >> permanently in order to expand the set of creatable object types >> without introducing a ton of restrictions and weird behaviors. >> What do you think? > Im +1 on t

Re: Add support to TLS 1.3 cipher suites and curves lists

First of all, thank you all for working on this feature. On Wed, Sep 25, 2024 at 10:51:05AM +0200, Peter Eisentraut wrote: > On 18.09.24 22:48, Jacob Champion wrote: >> > +#ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed TLSv1.2 ciphers >> > +#ssl_cipher_suites = ''# allowed TLSv1.3 cipher

Re: CRC32C Parallel Computation Optimization on ARM

On Wed, Dec 11, 2024 at 02:08:58PM +0700, John Naylor wrote: > I added a port to x86 and poked at it, with the intent to have an easy > on-ramp to that at least accelerates computation of CRCs on FPIs. > > The 0008 patch only worked on chunks of 1024 at a time. At that size, > the presence of hard

Re: Track the amount of time waiting due to cost_delay

On Wed, Dec 11, 2024 at 07:00:50AM +, Bertrand Drouvot wrote: > On Tue, Dec 10, 2024 at 11:55:41AM -0600, Nathan Bossart wrote: >> I wonder if it makes sense to provide this value as an interval instead of >> the number of milliseconds to make it more human-readable. > > Yeah we could do so,

Re: Proposal to add a new URL data type.

On Fri, Dec 6, 2024 at 8:46 AM Daniel Gustafsson wrote: > A URL datatype is a *good idea* but one which I personally believe is best > handled as an external extension. +1. I don't think that it's an intrinsically bad idea to have a URL data type in the core distribution, but no compelling reason

Re: FileFallocate misbehaving on XFS

Hi, On 2024-12-10 16:33:06 -0500, Andres Freund wrote: > Maybe. I think we would have gotten a lot more reports if it were common. I > know of quite a few very busy installs using xfs. > > I think there must be some as-of-yet-unknown condition gating it. E.g. that > the filesystem has been created

Re: Proposal to add a new URL data type.

10.12.2024 13:59, Victor Yegorov пишет: чт, 5 дек. 2024 г. в 17:02, Alexander Borisov >: [..] Hey, I had a look at this patch and found its functionality mature and performant. As Peter mentioned pguri, I used it to compare with the proposed extension. This

Re: Suggestion to standardize comment format in pg_dump

"Euler Taveira" writes: > On Wed, Dec 11, 2024, at 3:37 AM, Nohez Poonawala wrote: >> To maintain consistency, I suggest modifying the comment format for >> indexes to include the associated TABLENAME, similar to constraints. >> For example: >> - for Index: >> -- Name: TABLENAME INDEXNAME; Type: I

Re: Suggestion to standardize comment format in pg_dump

On Wed, Dec 11, 2024, at 3:37 AM, Nohez Poonawala wrote: > Currently, the pg_dump tool outputs comments in different formats for > primary/foreign keys and indexes. Below is the comment format. > > - for Primary key: > -- Name: TABLENAME CONSTRAINTNAME; Type: CONSTRAINT; Schema: SCHEMA; > Owner

Re: Document NULL

Em ter., 10 de dez. de 2024 às 20:00, David G. Johnston < david.g.johns...@gmail.com> escreveu: > I got rid of the row counts on the examples. > Cool, I would love to get rid all of them, like I proposed on [1]. > When I finalize the examples I'm probably going to \pset null . > Yes, much better

Re: on_error table, saving error info to a table

On 2024-12-02 Mo 11:28 PM, jian he wrote: On Tue, Nov 5, 2024 at 6:30 PM Nishant Sharma wrote: Thanks for the v2 patch! I see v1 review comments got addressed in v2 along with some further improvements. 1) v2 Patch again needs re-base. 2) I think we need not worry whether table name is uni

Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE

do we also need to update doc/src/sgml/rules.sgml? https://www.postgresql.org/docs/current/rules-materializedviews.html

Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE

Le mer. 11 déc. 2024 à 12:16, David Rowley a écrit : > On Wed, 11 Dec 2024 at 22:38, David Rowley wrote: > > I've pushed the main patch. I'm not planning on pushing the > > auto_explain.log_buffers default change unless there's a bit more > > discussion about it. > > There were a few places that

Re: NOT ENFORCED constraint feature

On Wed, Dec 11, 2024 at 6:12 PM jian he wrote: > > On Tue, Dec 10, 2024 at 7:48 PM Amul Sul wrote: > > > > > > > > static bool > > > MergeWithExistingConstraint(Relation rel, const char *ccname, Node *expr, > > > bool allow_merge, bool is_local, > > > + bool is_enforced, > > > bool is_initia

Re: NOT ENFORCED constraint feature

On Tue, Dec 10, 2024 at 7:48 PM Amul Sul wrote: > > > > > static bool > > MergeWithExistingConstraint(Relation rel, const char *ccname, Node *expr, > > bool allow_merge, bool is_local, > > + bool is_enforced, > > bool is_initially_valid, > > bool is_no_inherit) > > { > > @@ -2729,12 +2738,

RE: COPY performance on Windows

Hi, I continuously investigate the performance problem of COPY on Windows. I noticed that not only PG17.0 but also PG16.6 have performance problem compared to PG16.4. The performance is 2.5%-5.8% worse, especially when the number of clients is 1 or 2. I modified the performance measurement sc

Re: FileFallocate misbehaving on XFS

On Wed, Dec 11, 2024 at 4:00 AM Michael Harris wrote: > Hi Jakub > > On Tue, 10 Dec 2024 at 22:36, Jakub Wartak > wrote: [..] > > > 3. Maybe somehow there is a bigger interaction between posix_fallocate() > and delayed XFS's dynamic speculative preallocation from many processes all > writing

Re: on_error table, saving error info to a table

Thanks for the v3 patch! Please find review comments on v3:- 1) I think no need to change the below if condition, we can keep it the way it was before i.e with "cstate->opts.on_error != COPY_ON_ERROR_STOP" and we add a new error ereport the way v3 has. Because for cstate->opts.on_error as COPY_ON

Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE

On Wed, 11 Dec 2024 at 22:38, David Rowley wrote: > I've pushed the main patch. I'm not planning on pushing the > auto_explain.log_buffers default change unless there's a bit more > discussion about it. There were a few places that were missing a BUFFERS OFF as indicated by the buildfarm. I've fi

Re: advanced patch feedback session at FOSDEM, responses needed

On 12/11/24 08:05, Peter Eisentraut wrote: > Hi all, > > I'm trying to organize an advanced patch feedback session adjacent to > FOSDEM.  Right now, I'm looking to gauge interest so that concrete > plans can be made.  Specifically, if you would like to participate and > have your patches reviewed,

Re: pg_dump memory leak of 400 bytes

> On 11 Dec 2024, at 10:59, Oleg Tselebrovskiy > wrote: > When I was looking through static analyzer output I've found a memory leak in > pg_dump Thanks for the report, although 400 bytes won't break the bank in the grand scheme of things considering how much memory pg_dump use there is little

Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.

On Wed, Dec 11, 2024 at 2:08 PM vignesh C wrote: > > On Wed, 11 Dec 2024 at 11:21, Shubham Khanna > wrote: > > > > On Wed, Dec 11, 2024 at 4:21 AM Peter Smith wrote: > > > > I have fixed the given comments. The attached patch contains the > > suggested changes. > > Since all the subscriptions ar

pg_dump memory leak of 400 bytes

Greetings, everyone! When I was looking through static analyzer output I've found a memory leak in pg_dump In function dumpFunc, when dumping a function with TRANSFORMs, we allocate memory for typeids array that contains OIDs of types that need to be transformed. The memory is allocated wit

  1   2   >