Re: Conflict detection and logging in logical replication

On Wed, Aug 28, 2024 at 3:53 PM shveta malik wrote: > > On Wed, Aug 28, 2024 at 9:44 AM Zhijie Hou (Fujitsu) > wrote: > > > > > > +1 on 'update_origin_differs' instead of 'update_origins_differ' as > > > > the former is somewhat similar to other conflict names 'insert_exists' > > > > and 'update_

Re: macOS prefetching support

On 26.08.24 07:54, Thomas Munro wrote: On Sat, Aug 24, 2024 at 12:28 AM Peter Eisentraut wrote: In terms of $subject, this patch seems sufficient for now. WFM. I noticed you don't have an EINTR retry loop, but the man page doesn't say you need one, so overall this patch LGTM. + * posix_fadv

Re: Test 041_checkpoint_at_promote.pl faild in installcheck due to missing injection_points

By the way, we have the same kind of "problem" with the meson build. As we are deliberately not want to install src/test/modules, after b6a0d469cae and 0d237aeebaee we must add step "meson compile install-test-files" in order to "meson test -q --setup running" to be successful. To be honest, this

Re: Collect statistics about conflicts in logical replication

On Tue, Aug 27, 2024 at 3:21 PM Zhijie Hou (Fujitsu) wrote: > > On Tuesday, August 27, 2024 10:59 AM Peter Smith > wrote: > > > > ~~~ > > > > 3. > > +# Enable track_commit_timestamp to detect origin-differ conflicts in > > +logical # replication. Reduce wal_retrieve_retry_interval to 1ms to > >

Re: Pgoutput not capturing the generated columns

On Mon, May 20, 2024 at 1:49 PM Masahiko Sawada wrote: > > On Wed, May 8, 2024 at 4:14 PM Shubham Khanna > wrote: > > > > On Wed, May 8, 2024 at 11:39 AM Rajendra Kumar Dangwal > > wrote: > > > > > > Hi PG Hackers. > > > > > > We are interested in enhancing the functionality of the pgoutput plug

Re: Conflict detection and logging in logical replication

On Wed, Aug 28, 2024 at 9:44 AM Zhijie Hou (Fujitsu) wrote: > > > > +1 on 'update_origin_differs' instead of 'update_origins_differ' as > > > the former is somewhat similar to other conflict names 'insert_exists' > > > and 'update_exists'. > > > > Since we reached a consensus on this, I am attachi

Re: Conflict Detection and Resolution

On Wed, Aug 28, 2024 at 10:30 AM Ajin Cherian wrote: > >> 2) >> Currently pg_dump is dumping even the default resolvers configuration. >> As an example if I have not changed default configuration for say >> sub1, it still dumps all: >> >> CREATE SUBSCRIPTION sub1 CONNECTION '..' PUBLICATION pub1 W

Re: New function normal_rand_array function to contrib/tablefunc.

On Wed, 28 Aug 2024 at 12:27, Andy Fan wrote: > Japin Li writes: > > >> Thanks for updating the patch. Here are some comments. >> >> +if (minlen >= maxlen) >> +ereport(ERROR, >> +(errcode(ERRCODE_INVALID_PARAMETER_VALUE), >> +

Re: Conflict Detection and Resolution

On Wed, Aug 28, 2024 at 2:27 PM shveta malik wrote: > > 2) > Currently pg_dump is dumping even the default resolvers configuration. > As an example if I have not changed default configuration for say > sub1, it still dumps all: > > CREATE SUBSCRIPTION sub1 CONNECTION '..' PUBLICATION pub1 WITH (.

Re: Streaming read-ready sequential scan code

On Wed, Aug 28, 2024 at 1:00 AM Alexander Lakhin wrote: > gives me unstable numbers on unpatched master: > Buffers: shared hit=226 > Buffers: shared hit=217 > Buffers: shared hit=162 > Buffers: shared

Re: New function normal_rand_array function to contrib/tablefunc.

Japin Li writes: > Thanks for updating the patch. Here are some comments. > > + if (minlen >= maxlen) > + ereport(ERROR, > + (errcode(ERRCODE_INVALID_PARAMETER_VALUE), > + errmsg("minlen must be greater than > maxlen.")));

Re: Conflict Detection and Resolution

On Tue, Aug 27, 2024 at 1:51 PM Nisha Moond wrote: > > Please find v10 patch-set. Changes are: > > 1) patch-001: > - Corrected a patch application warning. > - Added support for pg_dump. > - As suggested in pt.4 of [1]: added a warning during CREATE and > ALTER subscription when track_commit_ti

RE: Conflict detection and logging in logical replication

On Wednesday, August 28, 2024 12:11 PM Zhijie Hou (Fujitsu) wrote: > > > > Peter Smith mentioned to me off-list that the names of conflict > > > > types 'update_differ' and 'delete_differ' are not intuitive as > > > > compared to all other conflict types like insert_exists, > > > > update_missin

RE: Conflict detection and logging in logical replication

On Wednesday, August 28, 2024 11:30 AM shveta malik wrote: > > On Tue, Aug 27, 2024 at 4:37 AM Peter Smith > wrote: > > > > On Mon, Aug 26, 2024 at 7:52 PM Amit Kapila > wrote: > > > > > > On Thu, Aug 22, 2024 at 2:21 PM Amit Kapila > wrote: > > > > > > > > On Thu, Aug 22, 2024 at 1:33 PM Pet

Re: Eager aggregation, take 3

Richard Guo 于2024年8月21日周三 15:11写道： > On Fri, Aug 16, 2024 at 4:14 PM Richard Guo > wrote: > > I had a self-review of this patchset and made some refactoring, > > especially to the function that creates the RelAggInfo structure for a > > given relation. While there were no major changes, the cod

Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.

On Wed, Aug 28, 2024 at 11:30 AM Richard Guo wrote: > On Wed, Aug 28, 2024 at 5:52 AM Tom Lane wrote: > > I realized that actually we do have the mechanism for making that > > work: we could apply add_nulling_relids to the expression, if it > > meets those same conditions. > > I think this should

Re: Flush pgstats file during checkpoints

Hi, On Mon, Aug 26, 2024 at 01:56:40PM +0900, Michael Paquier wrote: > On Fri, Aug 02, 2024 at 02:11:34AM +0900, Michael Paquier wrote: > > Applied 0003 for now to add the redo LSN to the pgstats file, adding > > the redo LSN to the two DEBUG2 entries when reading and writing while > > on it, that

Re: consider -Wmissing-variable-declarations

On Wed, Jun 19, 2024 at 3:02 AM Andres Freund wrote: > > -const char *EAN13_range[][2] = { > > +static const char *EAN13_range[][2] = { > > {"000", "019"}, /* GS1 US */ > > {"020", "029"}, /* Restricted distribution > > (MO defined) */ >

Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.

On Wed, Aug 28, 2024 at 5:52 AM Tom Lane wrote: > I realized that actually we do have the mechanism for making that > work: we could apply add_nulling_relids to the expression, if it > meets those same conditions. I think this should work, as long as we apply add_nulling_relids only to Vars/PHVs

Re: Conflict detection and logging in logical replication

On Tue, Aug 27, 2024 at 4:37 AM Peter Smith wrote: > > On Mon, Aug 26, 2024 at 7:52 PM Amit Kapila wrote: > > > > On Thu, Aug 22, 2024 at 2:21 PM Amit Kapila wrote: > > > > > > On Thu, Aug 22, 2024 at 1:33 PM Peter Smith wrote: > > > > > > > > Do you think the documentation for the 'column_valu

Re: Allow logical failover slots to wait on synchronous replication

On Tue, Aug 27, 2024 at 12:56 AM John H wrote: > > Hi Shveta, > > On Sun, Jul 21, 2024 at 8:42 PM shveta malik wrote: > > > > Ah that's a gap. Let me add some logging/warning in a similar fashion. > > > Although I think I'd have the warning be relatively generic (e.g. > > > changes are blocked be

Re: RFC: Additional Directory for Extensions

On Wed, 28 Aug 2024 at 03:26, David E. Wheeler wrote: > Right. ISTM it could complicate PGXS quite a bit. If we set, say, > > SET extension_search_path = $extsdir, /mnt/extensions/pg16, > /mnt/extensions/pg16/gosuperfast/extensions; > > What should be the output of `pg_config --sharedir`? `pg_co

Re: Parallel CREATE INDEX for GIN indexes

On Wed, 28 Aug 2024 at 02:38, Andy Fan wrote: > > Matthias van de Meent writes: > > tuplesort_performsort usually only needs to flush the last elements of > > ... In certain rare > > cases it may take a longer time as it may have to merge sorted runs, > > but those cases are quite rare in my expe

RE: Doc: fix the note related to the GUC "synchronized_standby_slots"

> > > So, will it be okay if we just remove ".. without losing data" from > > > the sentence? Will that avoid the confusion you have? > > Yes. Additionally, it would be better to add notes about data > > consistency after failover for example > > > > Note that data consistency after failover can va

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

On Wed, 28 Aug 2024 at 01:42, Peter Geoghegan wrote: > > On Tue, Aug 27, 2024 at 7:22 PM Matthias van de Meent > wrote: > > On Tue, 27 Aug 2024 at 23:40, Peter Geoghegan wrote: > > > Right, "trivial". Except in that it requires inventing a whole new > > > general purpose infrastructure. > > > >

Re: Parallel CREATE INDEX for GIN indexes

Matthias van de Meent writes: > tuplesort_performsort usually only needs to flush the last elements of > ... In certain rare > cases it may take a longer time as it may have to merge sorted runs, > but those cases are quite rare in my experience. OK, I am expecting such cases are not rare, Supp

Re: Segfault in jit tuple deforming on arm64 due to LLVM issue

Slightly better version, which wraps the conditional code in #ifdef USE_LLVM_BACKPORT_SECTION_MEMORY_MANAGER. v5-0001-Backport-of-LLVM-code-to-fix-ARM-relocation-bug.patch Description: Binary data

Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.

On Wed, 28 Aug 2024 at 11:37, Tom Lane wrote: > Oh, scratch that, I see you mean this is an additional way to do it > not the only way to do it. But I'm confused why it works for > t1.two+1 AS c1 > but not > t1.two+t2.two AS c1 > Those ought to look pretty much the same for this p

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

On Tue, Aug 27, 2024 at 7:22 PM Matthias van de Meent wrote: > On Tue, 27 Aug 2024 at 23:40, Peter Geoghegan wrote: > > Right, "trivial". Except in that it requires inventing a whole new > > general purpose infrastructure. > > Which seems to be in the process of being invented already elsewhere.

Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.

I wrote: > That seems like a pretty fishy way to do it. Are you saying that > Memoize is never applicable if there aren't outer joins in the > query? Without OJs there probably won't be any PHVs. Oh, scratch that, I see you mean this is an additional way to do it not the only way to do it. But

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

On Tue, 27 Aug 2024 at 23:40, Peter Geoghegan wrote: > > On Tue, Aug 27, 2024 at 5:03 PM Matthias van de Meent > wrote: > > If the counter was put into the BTScanOpaque, rather than the > > IndexScanDesc, then this could trivially be used in an explain AM > > callback, as IndexScanDesc and ->opaq

Re: PoC: prefetching data between executor nodes (e.g. nestloop + indexscan)

On Tue, Aug 27, 2024 at 6:44 PM Tomas Vondra wrote: > > One reason to do it this way is because it cuts down on index descent > > costs, and other executor overheads. But it is likely that it will > > also make prefetching itself more effective, too -- just because > > prefetching will naturally e

Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.

David Rowley writes: > On Wed, 28 Aug 2024 at 09:52, Tom Lane wrote: >> The other problem with this is that it breaks one test case in >> memoize.sql: a query that formerly generated a memoize plan >> now does not use memoize. I am not sure why not --- does that >> mean anything to you? > The r

Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.

On Wed, 28 Aug 2024 at 09:52, Tom Lane wrote: > The other problem with this is that it breaks one test case in > memoize.sql: a query that formerly generated a memoize plan > now does not use memoize. I am not sure why not --- does that > mean anything to you? The reason it works in master is th

Re: PoC: prefetching data between executor nodes (e.g. nestloop + indexscan)

On 8/27/24 20:53, Peter Geoghegan wrote: > On Tue, Aug 27, 2024 at 2:40 PM Andres Freund wrote: >> Have you considered instead expanding the parameterized scan logic? Right now >> nestloop passes down values one-by-one via PARAM_EXEC. What if we expanded >> that to allow nodes, e.g. nestloop in

Re: PoC: prefetching data between executor nodes (e.g. nestloop + indexscan)

On 8/27/24 20:40, Andres Freund wrote: > Hi, > > On 2024-08-26 18:06:04 +0200, Tomas Vondra wrote: >> I'm getting back to work on the index prefetching patch [1], but one >> annoying aspect of that patch is that it's limited to the context of a >> single executor node. It can be very effective whe

Re: Segfault in jit tuple deforming on arm64 due to LLVM issue

On Wed, Aug 28, 2024 at 12:07 AM Anthonin Bonnefoy wrote: > On Tue, Aug 27, 2024 at 12:01 PM Thomas Munro wrote: > > Thanks! And that's great news. Do you want to report this experience > > to the PR, in support of committing it? That'd make it seem easier to > > consider shipping a back-porte

Re: pg_upgrade: Support for upgrading to checksums enabled

On Mon, Aug 26, 2024 at 08:23:44AM +0200, Peter Eisentraut wrote: > The purpose of this patch is to allow using pg_upgrade between clusters that > have different checksum settings. When upgrading between instances with > different checksum settings, the --copy (default) mode automatically sets > (

Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.

I wrote: > We didn't see this particular behavior before 2489d76c49 because > pullup_replace_vars avoided inserting a PHV: > * If it contains a Var of the subquery being pulled up, and > * does not contain any non-strict constructs, then it's > * c

Re: Introduce new multi insert Table AM and improve performance of various SQL commands with it for Heap AM

On Mon, 2024-08-26 at 14:18 -0700, Jeff Davis wrote: > 0001 implementation issues: > > * We need default implementations for AMs that don't implement the > new > APIs, so that the AM will still function even if it only defines the > single-tuple APIs. If we need to make use of the AM's multi_inser

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

On Tue, Aug 27, 2024 at 5:03 PM Matthias van de Meent wrote: > If the counter was put into the BTScanOpaque, rather than the > IndexScanDesc, then this could trivially be used in an explain AM > callback, as IndexScanDesc and ->opaque are both still available while > building the explain output.

Re: Introduce new multi insert Table AM and improve performance of various SQL commands with it for Heap AM

On Mon, 2024-08-26 at 11:09 +0530, Bharath Rupireddy wrote: > On Wed, Jun 5, 2024 at 12:42 PM Bharath Rupireddy > wrote: > > > > Please find the v22 patches with the above changes. > > Please find the v23 patches after rebasing 0005 and adapting 0004 for > 9758174e2e. In patches 0002-0004, they

Re: Invalid "trailing junk" error message when non-English letters are used

Hi, Karina! On Tue, 27 Aug 2024 at 19:06, Karina Litskevich wrote: > Hi hackers, > > When error "trailing junk after numeric literal" occurs at a number > followed by a symbol that is presented by more than one byte, that symbol > in the error message is not displayed correctly. Instead of that

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

On Fri, 16 Aug 2024 at 00:34, Peter Geoghegan wrote: > > On Thu, Aug 15, 2024 at 5:47 PM Matthias van de Meent > wrote: > > > > I'm asking, because > > > > I'm not very convinced that 'primitive scans' are a useful metric > > > > across all (or even: most) index AMs (e.g. BRIN probably never will

Re: Partitioned tables and [un]loggedness

On Thu, May 02, 2024 at 03:06:51PM +0900, Michael Paquier wrote: > The case of a temporary persistence is actually *very* tricky. The > namespace, where the relation is created, is guessed and locked with > permission checks done based on the RangeVar when the CreateStmt is > transformed, which is

RE: Proposal for Updating CRC32C with AVX-512 Algorithm.

> Things like sizeof() and offsetof() are known at compile time, so the compiler > will recognize when a condition is always true or false and optimize it out > accordingly. In cases where the value cannot be known at compile time, > checking the length in the macro and dispatching to a different

Re: allowing extensions to control planner behavior

Robert Haas writes: > I believe the minimum viable product here > is probably something like: > - control over scan methods > - control over index selection > - control over join methods > - control over join order Seems reasonable. It might be possible to say that our answer to "control over j

Re: Introduce new multi insert Table AM and improve performance of various SQL commands with it for Heap AM

On Tue, 2024-08-27 at 15:44 +0200, Matthias van de Meent wrote: > > One solution: when the buffer is flushed, we can return an iterator > > over the buffered tuples to the caller. The caller can then use the > > iterator to insert into indexes, return a tuple to the executor, > > etc., > > and then

Re: allowing extensions to control planner behavior

Hi, On Tue, Aug 27, 2024 at 03:11:15PM -0400, Robert Haas wrote: > Third, I think there's simply a lack of critical mass in terms of our > planner hooks. While the ability to add hypothetical indexes has some > use, the ability to remove indexes from consideration is probably > significantly more

Re: allowing extensions to control planner behavior

On Mon, Aug 26, 2024 at 1:37 PM Tom Lane wrote: > For example, I don't see > how this gets us any closer to letting an extension fix a poor choice > of join order. Thinking more about this particular sub-problem, let's say we're joining four tables A, B, C, and D. An extension wants to compel joi

Re: Add contrib/pg_logicalsnapinspect

Hi, On Mon, Aug 26, 2024 at 07:05:27PM +0530, Amit Kapila wrote: > On Thu, Aug 22, 2024 at 5:56 PM Bertrand Drouvot > wrote: > > > > Please find attached a patch to $SUBJECT. > > > > This module provides SQL functions to inspect the contents of serialized > > logical > > snapshots of a running d

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

On Tue, Aug 27, 2024 at 3:04 PM Tom Lane wrote: > TBH, I'm afraid that this patch basically is exposing numbers that > nobody but Peter Geoghegan and maybe two or three other hackers > will understand, and even fewer people will find useful (since the > how-many-primitive-scans behavior is not som

Re: allowing extensions to control planner behavior

On Tue, Aug 27, 2024 at 2:24 PM Tom Lane wrote: > I was just using that to illustrate that making the enable_XXX GUCs > relation-local covers only a small part of the planner-control problem. > You had not, at that point, been very clear that you intended that > patch as only a small part of a sol

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

Peter Geoghegan writes: > I see value in making it obvious to users when and how > pg_stat_all_indexes.idx_scan advances. Being able to easily relate it > to EXPLAIN ANALYZE output is useful, independent of whether or not > SAOPs happen to be used. That's probably the single best argument in > fav

Re: remove adaptive spins_per_delay code

On Tue, Aug 27, 2024 at 02:27:00PM -0400, Andres Freund wrote: > FWIW, I've seen cases on multi-socket machines where performance was vastly > worse under contention with some values of spins_per_delay. With good numbers > being quite different on smaller machines. Most new-ish server CPUs these da

Re: PoC: prefetching data between executor nodes (e.g. nestloop + indexscan)

On Tue, Aug 27, 2024 at 2:40 PM Andres Freund wrote: > Have you considered instead expanding the parameterized scan logic? Right now > nestloop passes down values one-by-one via PARAM_EXEC. What if we expanded > that to allow nodes, e.g. nestloop in this case, to pass down multiple values > in one

Re: PoC: prefetching data between executor nodes (e.g. nestloop + indexscan)

Hi, On 2024-08-26 18:06:04 +0200, Tomas Vondra wrote: > I'm getting back to work on the index prefetching patch [1], but one > annoying aspect of that patch is that it's limited to the context of a > single executor node. It can be very effective when there's an index > scan with many matches for

Re: remove adaptive spins_per_delay code

Hi, On 2024-08-27 11:16:15 -0500, Nathan Bossart wrote: > (creating new thread from [0]) > > On Wed, Apr 10, 2024 at 09:52:59PM -0400, Tom Lane wrote: > > On fourth thought ... the number of tries to acquire the lock, or > > in this case number of tries to observe the lock free, is not > > NUM_DE

Re: allowing extensions to control planner behavior

Robert Haas writes: > Well, now I'm confused. Just yesterday, in response to the 0001 patch > that allows extensions to exert control over the join strategy, you > complained that "Or, if your problem is that the planner wants to scan > index A but you want it to scan index B, enable_indexscan won

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

On Tue, Aug 27, 2024 at 1:45 PM Robert Haas wrote: > I do like "Index Searches" better than "Primitive Index Scans." > > But I think Matthias had some good points about this being > btree-specific. It's not B-Tree specific -- not really. Any index scan that can at least non-natively support Scala

Re: Proposal to have INCLUDE/EXCLUDE options for altering option values

> I'm not convinced > that this problem would arise often enough in practice that it's worth > adding a feature to address it. A user who has this problem can pretty > easily do some scripting to address it > AFAICS this proposal also represents a tiny use case. Thanks Robert and Euler for the fe

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

On Tue, Aug 27, 2024 at 11:16 AM Peter Geoghegan wrote: > On Thu, Aug 15, 2024 at 3:22 PM Peter Geoghegan wrote: > > Attached patch has EXPLAIN ANALYZE display the total number of > > primitive index scans for all 3 kinds of index scan node. > > Attached is v2, which fixes bitrot. > > v2 also use

Re: allowing extensions to control planner behavior

On Tue, Aug 27, 2024 at 12:56 PM Tom Lane wrote: > Robert Haas writes: > > In that vein, here's a new patch set where I've added a second patch > > that allows extensions to control choice of index. > > I'm minus-several on this bit, because that is a solved problem and > we really don't need to

Re: allowing extensions to control planner behavior

Robert Haas writes: > In that vein, here's a new patch set where I've added a second patch > that allows extensions to control choice of index. I'm minus-several on this bit, because that is a solved problem and we really don't need to introduce More Than One Way To Do It. The intention has alwa

Re: allowing extensions to control planner behavior

On Tue, Aug 27, 2024 at 11:57 AM Joe Conway wrote: > On the one hand, excluding indexes by initial vowels is definitely > silly. On the other, I can see how it might be useful for an extension > to exclude indexes based on a regex match of the index name or something > similar, at least for testin

remove adaptive spins_per_delay code

(creating new thread from [0]) On Wed, Apr 10, 2024 at 09:52:59PM -0400, Tom Lane wrote: > On fourth thought ... the number of tries to acquire the lock, or > in this case number of tries to observe the lock free, is not > NUM_DELAYS but NUM_DELAYS * spins_per_delay. Decreasing > spins_per_delay

Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.

[ switching to -hackers list ] David Rowley writes: > In case it saves you a bit of time, I stripped as much of the > unrelated stuff out as I could and got: > create table t (a name, b int); > explain select * from (select a::varchar,b from (select distinct a,b > from t) st) t right join t t2 o

Re: allowing extensions to control planner behavior

On Tue, Aug 27, 2024 at 2:44 AM chungui.wcg wrote: > I really admire this idea. Thanks. > here is my confusion: Isn't the core of this idea whether to turn the > planner into a framework? Personally, I think that under PostgreSQL's heap > table storage, the optimizer might be better off focus

Re: allowing extensions to control planner behavior

On 8/27/24 11:45, Robert Haas wrote: On Mon, Aug 26, 2024 at 3:28 PM Robert Haas wrote: Well, I agree that this doesn't address everything you might want to do, ... I will very happily propose more things to address the other problems that I know about ... In that vein, here's a new patch set

Re: allowing extensions to control planner behavior

On Mon, Aug 26, 2024 at 3:28 PM Robert Haas wrote: > Well, I agree that this doesn't address everything you might want to > do, ... I will very happily propose more things to > address the other problems that I know about ... In that vein, here's a new patch set where I've added a second patch th

Re: Enable data checksums by default

On Tue, Aug 27, 2024 at 05:16:51PM +0200, Peter Eisentraut wrote: > On 27.08.24 15:44, Greg Sabino Mullane wrote: >> On Mon, Aug 26, 2024 at 3:46 PM Nathan Bossart > > wrote: >> >> Should we error if both --data-checksum and --no-data-checksums are >> speci

Re: RFC: Additional Directory for Extensions

On Aug 26, 2024, at 17:35, Craig Ringer wrote: > This looks like a good suggestion to me, it would make the packaging, > distribution and integration of 3rd party extensions significantly > easier without any obvious large or long term cost. Yes! > Also PGXS, the windows extension build support

Re: RFC: Additional Directory for Extensions

On Aug 27, 2024, at 04:56, Gabriele Bartolini wrote: > The extension image could follow a naming convention like this (order can be > adjusted): `-- version>-(-)`. For example, `pgvector-16-0.7.4-bookworm-1` would > represent the first image built in a repository for pgvector 0.7.4 for > Post

Re: Enable data checksums by default

On 27.08.24 15:44, Greg Sabino Mullane wrote: On Mon, Aug 26, 2024 at 3:46 PM Nathan Bossart > wrote: Should we error if both --data-checksum and --no-data-checksums are specified?  IIUC with 0001, we'll use whichever is specified last. Hmmm, that is a

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

On Thu, Aug 15, 2024 at 3:22 PM Peter Geoghegan wrote: > Attached patch has EXPLAIN ANALYZE display the total number of > primitive index scans for all 3 kinds of index scan node. Attached is v2, which fixes bitrot. v2 also uses new terminology. EXPLAIN ANALYZE will now show "Index Searches: N",

Invalid "trailing junk" error message when non-English letters are used

Hi hackers, When error "trailing junk after numeric literal" occurs at a number followed by a symbol that is presented by more than one byte, that symbol in the error message is not displayed correctly. Instead of that symbol there is only its first byte. That makes the error message an invalid UT

Re: proposal: schema variables

time""On Tue, 2024-08-27 at 08:52 +0200, Pavel Stehule wrote: > I can throw 200KB from another 300KB patch set which can be better for > review, but it > can be harder to maintain this patch set. I'll try it, and I'll send a > reduced version. That was not a criticism, and I think the way you sp

Re: New function normal_rand_array function to contrib/tablefunc.

On Tue, 27 Aug 2024 at 16:43, Andy Fan wrote: > Andy Fan writes: > My suggestion would be to mirror the signatures of the core random() functions more closely, and have this: 1). rand_array(numvals int, minlen int, maxlen int) returns setof float8[] >> ..> 4

Re: Better error message when --single is not the first arg to postgres executable

On Mon, Aug 26, 2024 at 11:43 AM Nathan Bossart wrote: > On Sun, Aug 25, 2024 at 01:14:36PM -0400, Greg Sabino Mullane wrote: > > I'm not happy about making this and the const char[] change their > structure > > based on the ifdefs - could we not just leave forkchild in? Their usage > is > > alre

Re: Enable data checksums by default

On Mon, Aug 26, 2024 at 3:46 PM Nathan Bossart wrote: > Should we error if both --data-checksum and --no-data-checksums are > specified? IIUC with 0001, we'll use whichever is specified last. > Hmmm, that is a good question. We have never (to my recollection) flipped a default quite like this b

Re: Introduce new multi insert Table AM and improve performance of various SQL commands with it for Heap AM

On Tue, 27 Aug 2024 at 07:42, Jeff Davis wrote: > > On Mon, 2024-08-26 at 23:59 +0200, Matthias van de Meent wrote: > > Specifically, I'm having trouble seeing how this could be used to > > implement ```INSERT INTO ... SELECT ... RETURNING ctid``` as I see no > > returning output path for the newl

Re: Parallel CREATE INDEX for GIN indexes

On Tue, 27 Aug 2024 at 12:15, Andy Fan wrote: > > Tomas Vondra writes: > > And let's talk about the improvement by Matthias, namely: > > > > * 0008 Use a single GIN tuplesort > > * 0009 Reduce the size of GinTuple by 12 bytes > > > > I haven't really seen any impact on duration - it seems more or

Re: Streaming read-ready sequential scan code

Hello Thomas, 27.08.2024 09:52, Thomas Munro wrote: Here's a really simple way to see the new unfairness at the end of a parallel scan: drop table if exists t; create table t (i int); insert into t select generate_series(1, 10); alter table t set (parallel_workers = 2); set parallel_setup_c

Re: Segfault in jit tuple deforming on arm64 due to LLVM issue

On Tue, Aug 27, 2024 at 12:01 PM Thomas Munro wrote: > > Thanks! And that's great news. Do you want to report this experience > to the PR, in support of committing it? That'd make it seem easier to > consider shipping a back-ported copy... Yes, I will do that.

Re: [PATCH] Add CANONICAL option to xmlserialize

On 26.08.24 16:59, Pavel Stehule wrote: > > 1. what about behaviour of NO INDENT - the implementation is not too > old, so it can be changed if we want (I think), and it is better to do > early than too late While checking the feasibility of removing indentation with NO INDENT I may have found

Re: Redundant Result node

Em ter., 27 de ago. de 2024 às 00:43, Richard Guo escreveu: > On Thu, Aug 22, 2024 at 9:02 PM Ranier Vilela wrote: > > Em qui., 22 de ago. de 2024 às 04:34, Richard Guo < > guofengli...@gmail.com> escreveu: > >> This does not seem right to me, as PathTargets are not canonical, so > >> we cannot

Re: Parallel CREATE INDEX for GIN indexes

On 8/27/24 12:14, Andy Fan wrote: > Tomas Vondra writes: > >> Hi, >> >> I got to do the detailed benchmarking on the latest version of the patch >> series, so here's the results. My goal was to better understand the >> impact of each patch individually - especially the two parts introduced >>

Redux: Throttle WAL inserts before commit

Hello hackers, This is an attempt to resurrect the thread [1] to throttle WAL inserts before the point of commit. Background: Transactions on commit, wait for replication and make sure WAL is flushed up to commit lsn on standby, when synchronous_commit is on. While commit is a mandatory sync/wa

Re: PoC: prefetching data between executor nodes (e.g. nestloop + indexscan)

On 8/26/24 18:06, Tomas Vondra wrote: > > I just noticed there's a couple failures in the regression tests, if I > change the GUC to "true" by default. I haven't looked into that yet, but > I guess there's some mistake in resetting the child node, or something > like that. Will investigate. > Tu

Re: Doc: fix the note related to the GUC "synchronized_standby_slots"

On Tue, Aug 27, 2024 at 3:05 PM wrote: > > > So, will it be okay if we just remove ".. without losing data" from the > > sentence? Will that > > avoid the confusion you have? > Yes. Additionally, it would be better to add notes about data consistency > after failover for example > > Note that da

Re: Parallel CREATE INDEX for GIN indexes

Tomas Vondra writes: > Hi, > > I got to do the detailed benchmarking on the latest version of the patch > series, so here's the results. My goal was to better understand the > impact of each patch individually - especially the two parts introduced > by Matthias, but not only - so I ran the test o

Re: Segfault in jit tuple deforming on arm64 due to LLVM issue

Thanks! And that's great news. Do you want to report this experience to the PR, in support of committing it? That'd make it seem easier to consider shipping a back-ported copy...

RE: Collect statistics about conflicts in logical replication

On Tuesday, August 27, 2024 10:59 AM Peter Smith wrote: > > ~~~ > > 3. > +# Enable track_commit_timestamp to detect origin-differ conflicts in > +logical # replication. Reduce wal_retrieve_retry_interval to 1ms to > +accelerate the # restart of the logical replication worker after > encounterin

RE: Doc: fix the note related to the GUC "synchronized_standby_slots"

> So, will it be okay if we just remove ".. without losing data" from the > sentence? Will that > avoid the confusion you have? Yes. Additionally, it would be better to add notes about data consistency after failover for example Note that data consistency after failover can vary depending on the

Re: list of acknowledgments for PG17

On Sat, Aug 24, 2024 at 11:27 PM Peter Eisentraut wrote: > As usual, please check for problems such as wrong sorting, duplicate > names in different variants, or names in the wrong order etc. I think Japanese names are in the right order except “Sutou Kouhei”. I am 100% sure his given name is Kou

Re: Segfault in jit tuple deforming on arm64 due to LLVM issue

On Tue, Aug 27, 2024 at 1:33 AM Thomas Munro wrote: > I am sure this requires changes for various LLVM versions. I tested > it with LLVM 14 on a Mac where I've never managed to reproduce the > original complaint, but ... h, this might be exacerbated by ASLR, > and macOS only has a small ALSR

Re: Cross-version Compatibility of postgres_fdw

On Tue, Aug 20, 2024 at 8:55 AM Bruce Momjian wrote: > I think it is an improvement, so applied to master. Thanks. Thanks for taking care of this! Best regards, Etsuro Fujita

Re: Set query_id for query contained in utility statement

On Mon, Aug 26, 2024 at 4:55 PM Anthonin Bonnefoy wrote: > /* Evaluate parameters, if any */ if (entry->plansource->num_params) { - ParseState *pstate; - - pstate = make_parsestate(NULL); - pstate->p_sourcetext = queryString; you deleted the above these lines, but passed (ParseState *pstat

Re: RFC: Additional Directory for Extensions

Hi David, Thanks for your email. On Mon, 26 Aug 2024 at 16:07, David E. Wheeler wrote: > I would assume BINDIR, DOCDIR, HTMLDIR, PKGLIBDIR, MANDIR, SHAREDIR, and > perhaps LOCALEDIR. > > But even if it’s just one or two, the only proper way an extension > directory would work, IME, is to define

Re: Doc: fix the note related to the GUC "synchronized_standby_slots"

On Tue, Aug 27, 2024 at 10:18 AM wrote: > > > I think you see such a behavior because you have disabled > > 'synchronized_standby_slots' > > in your script (# disable "synchronized_standby_slots"). You need to enable > > that to > > avoid data loss. Considering that, I don't think your proposed

  1   2   >