Re: Trigger violates foreign key constraint

I fully support this addition to the documentation. The legal possibility of breaking data consistency must be documented at least. Please, consider small suggestion to replace last sentence. - This is not considered a bug, and it is the responsibility of the user to write triggers so that

Re: [PATCH]: Not to invaldiate CatalogSnapshot for local invalidation messages

Hi, I updated the comment about the CatalogSnapshot `src/backend/utils/time/ snapmgr.c` Xiaoran Wang 于2023年12月18日周一 15:02写道： > Hi, > Thanks for your reply. > > jian he 于2023年12月18日周一 08:20写道： > >> Hi >> ---setup. >> drop table s2; >> create table s2(a int); >> >> After apply the patch >> alter

Optimization outcome depends on the index order

On 21/12/2023 12:10, Alexander Korotkov wrote: > I took a closer look at the patch in [9]. I should drop my argument > about breaking the model, because add_path() already considers other > aspects than just costs. But I have two more note about that patch: > > 1) It seems that you're

A typo in a messsage?

I found the following message introduced by a recent commit. > errdetail("The first unsummarized LSN is this range is %X/%X.", Shouldn't the "is" following "LSN" be "in"? diff --git a/src/backend/backup/basebackup_incremental.c b/src/backend/backup/basebackup_incremental.c index

Re: Transaction timeout

On Tue, 19 Dec 2023 at 22:06, Japin Li wrote: > On Tue, 19 Dec 2023 at 18:27, Andrey M. Borodin wrote: >>> On 19 Dec 2023, at 13:26, Andrey M. Borodin wrote: >>> >>> I don’t have Windows machine, so I hope CF bot will pick this. >> >> I used Github CI to produce version of tests that seems to

Re: trying again to get incremental backup

21.12.2023 23:43, Robert Haas wrote: There are also two deadcode.DeadStores complaints from clang. First one is about: /* * Align the wait time to prevent drift. This doesn't really matter, * but we'd like the warnings about how long we've been waiting to say

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

On Thu, Dec 21, 2023 at 5:35 PM Sutou Kouhei wrote: > > Hi, > > In > "Re: Make COPY format extendable: Extract COPY TO format implementations" > on Mon, 11 Dec 2023 23:31:29 +0900, > Masahiko Sawada wrote: > > > I've sketched the above idea including a test module in > >

Re: Track in pg_replication_slots the reason why slots conflict?

On Fri, Dec 22, 2023 at 5:00 AM Michael Paquier wrote: > > On Thu, Dec 21, 2023 at 07:26:56AM -0800, Andres Freund wrote: > > On 2023-12-21 19:55:51 +0530, Amit Kapila wrote: > >> We can return int2 value from the function pg_get_replication_slots() > >> and then use that to display a string in

Re: int4->bool test coverage

On Thu, Dec 21, 2023 at 11:56:22AM +0100, Christoph Berg wrote: > The first cast is the int4_bool function, but it isn't covered by the > regression tests at all. The attached patch adds tests. I don't see why not. Interesting that there are a few more of these in int.c, like int2up, int4inc,

Re: ci: Build standalone INSTALL file

On Thu, Dec 21, 2023 at 02:22:02PM -0500, Tom Lane wrote: > Here's a draft patch for this. Most of it is mechanical removal of > infrastructure for building the INSTALL file. If anyone wants to > bikeshed on the new wording of README, feel free. Thanks for putting this together. That looks

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

On Thu, Dec 21, 2023 at 6:35 PM Sutou Kouhei wrote: > > Hi, > > In > "Re: Make COPY format extendable: Extract COPY TO format implementations" > on Mon, 11 Dec 2023 23:31:29 +0900, > Masahiko Sawada wrote: > > > I've sketched the above idea including a test module in > >

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

On Fri, Dec 22, 2023 at 10:00 AM Michael Paquier wrote: > > On Thu, Dec 21, 2023 at 06:35:04PM +0900, Sutou Kouhei wrote: > >* If we just require "copy_to_${FORMAT}(internal)" > > function and "copy_from_${FORMAT}(internal)" function, > > we can remove the tricky approach. And it

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

On Thu, Dec 21, 2023 at 06:35:04PM +0900, Sutou Kouhei wrote: >* If we just require "copy_to_${FORMAT}(internal)" > function and "copy_from_${FORMAT}(internal)" function, > we can remove the tricky approach. And it also avoid > name collisions with other handler such as

Re: Track in pg_replication_slots the reason why slots conflict?

On Thu, Dec 21, 2023 at 07:26:56AM -0800, Andres Freund wrote: > On 2023-12-21 19:55:51 +0530, Amit Kapila wrote: >> We can return int2 value from the function pg_get_replication_slots() >> and then use that to display a string in the view >> pg_replication_slots. > > I strongly dislike that

Re: Remove MSVC scripts from the tree

On Thu, Dec 21, 2023 at 03:43:32PM -0500, Andrew Dunstan wrote: > On 2023-12-21 Th 03:01, Michael Paquier wrote: >> Andrew, was the original target of pgperlsyncheck committers and >> hackers who played with the MSVC scripts but could not run sanity >> checks on Windows (see [1])? > > > yes.

Re: broken master regress tests

On Wed, 2023-12-20 at 17:48 -0800, Jeff Davis wrote: > Attached. It appears to increase the coverage. I committed it and I'll see how the buildfarm reacts. Regards, Jeff Davis

Re: Built-in CTYPE provider

On Wed, 2023-12-20 at 15:47 -0800, Jeremy Schneider wrote: > One other thing that comes to mind: how does the parser do case > folding > for relation names? Is that using OS-provided libc as of today? Or > did > we code it to use ICU if that's the DB default? I'm guessing libc, > and > global

Re: Built-in CTYPE provider

On Wed, 2023-12-20 at 16:29 -0800, Jeremy Schneider wrote: > found some more. here's my running list of everything user-facing I > see > in core PG code so far that might involve case: > > * upper/lower/initcap > * regexp_*() and *_REGEXP() > * ILIKE, operators ~* !~* ~~ !~~ ~~* !~~* > * citext +

Re: pg_serial bloat

On Fri, Dec 15, 2023 at 9:53 AM Thomas Munro wrote: > ... We've seen a system with ~30GB of files in there > (note: full/untruncated be would be 2³² xids × sizeof(uint64_t) = > 32GB). It's not just a gradual disk space leak: according to disk > space monitoring, this system suddenly wrote ~half

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Fri, Nov 17, 2023 at 6:12 PM Melanie Plageman wrote: > > On Mon, Nov 13, 2023 at 5:28 PM Melanie Plageman > wrote: > > When there are no indexes on the relation, we can set would-be dead > > items LP_UNUSED and remove them during pruning. This saves us a vacuum > > WAL record, reducing WAL

Re: Eager page freeze criteria clarification

On Thu, Dec 21, 2023 at 10:56 AM Melanie Plageman wrote: > Agreed. I plan to test with another distribution. Though, the exercise > of determining which ones are useful is probably more challenging. > I imagine we will have to choose one distribution (as opposed to > supporting different

Re: Eager page freeze criteria clarification

On Wed, Dec 13, 2023 at 12:24 PM Robert Haas wrote: > > Great results. Thanks! > On Sat, Dec 9, 2023 at 5:12 AM Melanie Plageman > wrote: > > Values can be "removed" from the accumulator by simply decrementing its > > cardinality and decreasing the sum and sum squared by a value that will > >

Re: Remove MSVC scripts from the tree

On 2023-12-21 Th 03:01, Michael Paquier wrote: On Wed, Dec 20, 2023 at 11:39:15PM -0800, Andres Freund wrote: Can't we teach the tool that it should not validate src/tools/win32tzlist.pl on !windows? It's obviously windows specific code, and it's special case enough that there doesn't seem

Re: trying again to get incremental backup

On Thu, Dec 21, 2023 at 10:00 AM Alexander Lakhin wrote: > Please look at the attached patch; it corrects all 29 items ("recods" > fixed in two places), but maybe you find some substitutions wrong... Thanks, committed with a few additions. > I've also observed that those commits introduced new

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

vignesh C wrote: > Thanks for the updated patch, any reason why this is handled only in csv. > postgres=# copy test1 from '/home/vignesh/postgres/inst/bin/copy1.out'; > COPY 1 > postgres=# select * from test1; > c1 > --- > line1 > (1 row) I believe it's safer to not change anything

Re: ci: Build standalone INSTALL file

Andres Freund writes: > On 2023-12-21 10:46:02 -0500, Tom Lane wrote: >> Let's go with "/devel/ in master and a number in release branches" >> for now, and tweak that if the web team wants to take on maintaining >> a redirect. I'll put together a concrete patch proposal in a little >> bit. >

Re: index prefetching

On 12/21/23 18:14, Robert Haas wrote: > On Thu, Dec 21, 2023 at 11:08 AM Andres Freund wrote: >> But I'd like you to feel guilty (no, not really) and fix it (yes, really) :) > > Sadly, you're more likely to get the first one than you are to get the > second one. I can't really see going back to

authentication/t/001_password.pl trashes ~/.psql_history

I happened to notice this stuff getting added to my .psql_history: \echo background_psql: ready SET password_encryption='scram-sha-256'; ; \echo background_psql: QUERY_SEPARATOR SET scram_iterations=42; ; \echo background_psql: QUERY_SEPARATOR \password scram_role_iter \q After grepping for

Re: Functions to return random numbers in a given range

Hi čt 21. 12. 2023 v 18:06 odesílatel Dean Rasheed napsal: > Attached is a patch that adds 3 SQL-callable functions to return > random integer/numeric values chosen uniformly from a given range: > > random(min int, max int) returns int > random(min bigint, max bigint) returns bigint >

Re: index prefetching

On Thu, Dec 21, 2023 at 11:08 AM Andres Freund wrote: > But I'd like you to feel guilty (no, not really) and fix it (yes, really) :) Sadly, you're more likely to get the first one than you are to get the second one. I can't really see going back to revisit that decision as a basis for somebody

Functions to return random numbers in a given range

Attached is a patch that adds 3 SQL-callable functions to return random integer/numeric values chosen uniformly from a given range: random(min int, max int) returns int random(min bigint, max bigint) returns bigint random(min numeric, max numeric) returns numeric The return value is in the

Re: Eager page freeze criteria clarification

On 12/21/23 10:56, Melanie Plageman wrote: On Sat, Dec 9, 2023 at 9:24 AM Joe Conway wrote: However, even if we assume a more-or-less normal distribution, we should consider using subgroups in a way similar to Statistical Process Control[1]. The reasoning is explained in this quote: The

Re: index prefetching

Hi, On 2023-12-21 11:00:34 -0500, Robert Haas wrote: > On Thu, Dec 21, 2023 at 10:33 AM Tomas Vondra > wrote: > > > I continue to think that we should not have split plain and index only > > > scans > > > into separate files... > > > > I do agree with that opinion. Not just because of this

Re: index prefetching

On Thu, Dec 21, 2023 at 10:33 AM Tomas Vondra wrote: > > I continue to think that we should not have split plain and index only scans > > into separate files... > > I do agree with that opinion. Not just because of this prefetching > thread, but also because of the discussions about index-only

Re: ci: Build standalone INSTALL file

Hi, On 2023-12-21 10:46:02 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2023-12-21 10:22:49 -0500, Tom Lane wrote: > >> We could make it version-specific, > >> https://www.postgresql.org/docs/17/installation.html > >> and task src/tools/version_stamp.pl with updating it. But that's >

Re: Eager page freeze criteria clarification

On Sat, Dec 9, 2023 at 9:24 AM Joe Conway wrote: > > On 12/8/23 23:11, Melanie Plageman wrote: > > > > I'd be delighted to receive any feedback, ideas, questions, or review. > > > This is well thought out, well described, and a fantastic improvement in > my view -- well done! Thanks, Joe! That

Re: ci: Build standalone INSTALL file

Andres Freund writes: > On 2023-12-21 10:22:49 -0500, Tom Lane wrote: >> We could make it version-specific, >> https://www.postgresql.org/docs/17/installation.html >> and task src/tools/version_stamp.pl with updating it. But that's >> problematic for not-yet-released branches (there's no 17

Re: index prefetching

Hi, On 2023-12-21 16:20:45 +0100, Tomas Vondra wrote: > On 12/21/23 14:43, Andres Freund wrote: > >> AFAICS this seems similar to some of the AIO patch, I wonder what that > >> plans to do. I need to check. > > > > Yes, most of this exists there. The difference that with the AIO you don't > >

Re: index prefetching

On 12/21/23 14:27, Andres Freund wrote: > Hi, > > On 2023-12-09 19:08:20 +0100, Tomas Vondra wrote: >> But there's a layering problem that I don't know how to solve - I don't >> see how we could make indexam.c entirely oblivious to the prefetching, >> and move it entirely to the executor.

Re: ci: Build standalone INSTALL file

Hi, On 2023-12-21 10:22:49 -0500, Tom Lane wrote: > I think the only real question is what URL to point at exactly. We can't > simply say > > https://www.postgresql.org/docs/current/installation.html > > because that will be wrong for any version more than one major > release back. Right. >

Re: Track in pg_replication_slots the reason why slots conflict?

On 2023-12-21 19:55:51 +0530, Amit Kapila wrote: > On Thu, Dec 21, 2023 at 5:05 PM Andres Freund wrote: > > We clearly can't just expose the numerical value for a C enum. So it has to > > be > > converted to something SQL representable. > > > > We can return int2 value from the function

Re: ci: Build standalone INSTALL file

Andres Freund writes: > On 2023-12-21 08:39:26 +0900, Michael Paquier wrote: >> On Wed, Dec 20, 2023 at 11:36:28AM -0500, Tom Lane wrote: >>> I thought the plan was to get rid of that file, in pursuit of making >>> our distribution tarballs be more or less pure git pulls. Instead of >>>

Re: Set log_lock_waits=on by default

Le 21/12/2023 à 14:29, Laurenz Albe a écrit : Here is a patch to implement this. Being stuck behind a lock for more than a second is almost always a problem, so it is reasonable to turn this on by default. I think it's a really good idea. At Dalibo, we advise our customers to switch it on.

Re: index prefetching

On 12/21/23 14:43, Andres Freund wrote: > Hi, > > On 2023-12-21 13:30:42 +0100, Tomas Vondra wrote: >> You're right a lot of this is a guesswork. I don't think we can do much >> better, because it depends on stuff that's out of our control - each OS >> may do things differently, or perhaps

Re: trying again to get incremental backup

21.12.2023 15:07, Robert Haas wrote: On Wed, Dec 20, 2023 at 11:00 PM Alexander Lakhin wrote: I've found several typos/inconsistencies introduced with 174c48050 and dc2123400. Maybe you would want to fix them, while on it?: That's an impressively long list of mistakes in something I thought

Re: Set log_lock_waits=on by default

On Thu, Dec 21, 2023 at 05:29 Laurenz Albe wrote: > Here is a patch to implement this. > Being stuck behind a lock for more than a second is almost > always a problem, so it is reasonable to turn this on by default. I think it's a very good idea. On all heavily loaded systems I have observed

Re: Track in pg_replication_slots the reason why slots conflict?

Hi, On Thu, Dec 21, 2023 at 07:55:51PM +0530, Amit Kapila wrote: > On Thu, Dec 21, 2023 at 5:05 PM Andres Freund wrote: > > I'm not entirely sure I understand the difference - just whether we add one > > new column or replace the existing 'conflicting' column? I can see arguments > > for either.

Re: GIN-Indexable JSON Patterns

On Dec 17, 2023, at 13:10, David E. Wheeler wrote: > Quick follow-up to my slew of questions back in [September][1]. I wanted to > update [my patch][2] to note that only JSON Path equality operators are > supported by indexes, as [previously discussed][3]. Should I just add it to the patch

Re: Track in pg_replication_slots the reason why slots conflict?

On Thu, Dec 21, 2023 at 5:05 PM Andres Freund wrote: > > On 2023-12-21 16:08:48 +0530, shveta malik wrote: > > On Thu, Dec 21, 2023 at 3:10 PM Andres Freund wrote: > > > > > > Extra columns aren't free from a usability perspective. IFF we do > > > something, I > > > think it should be a single

Re: Set log_lock_waits=on by default

On Thu, Dec 21, 2023 at 8:29 AM Laurenz Albe wrote: > Here is a patch to implement this. > Being stuck behind a lock for more than a second is almost > always a problem, so it is reasonable to turn this on by default. I think it depends somewhat on the lock type, and also on your threshold for

Re: logical decoding and replication of sequences, take 2

On 12/15/23 03:33, Amit Kapila wrote: > On Thu, Dec 14, 2023 at 9:14 PM Ashutosh Bapat > wrote: >> >> On Thu, Dec 14, 2023 at 2:51 PM Amit Kapila wrote: >>> >>> It can only be cleaned if we process it but xact_decode won't allow us >>> to process it and I don't think it would be a good idea to

Re: "pgoutput" options missing on documentation

> But the xref seems present only in the master/v16/v15 patches, but not > for the earlier patches v14/v13/v12. Why not? I missed it. > But the change was only in the patches v14 onwards. Although the new > error message was only added for HEAD, isn't it still correct to say > "A valid version

Re: index prefetching

Hi, On 2023-12-21 13:30:42 +0100, Tomas Vondra wrote: > You're right a lot of this is a guesswork. I don't think we can do much > better, because it depends on stuff that's out of our control - each OS > may do things differently, or perhaps it's just configured differently. > > But I don't

Re: index prefetching

Hi, On 2023-12-09 19:08:20 +0100, Tomas Vondra wrote: > But there's a layering problem that I don't know how to solve - I don't > see how we could make indexam.c entirely oblivious to the prefetching, > and move it entirely to the executor. Because how else would you know > what to prefetch? >

Set log_lock_waits=on by default

Here is a patch to implement this. Being stuck behind a lock for more than a second is almost always a problem, so it is reasonable to turn this on by default. Yours, Laurenz Albe From a767e69c724fbbff14114729272be5d29c3d69d8 Mon Sep 17 00:00:00 2001 From: Laurenz Albe Date: Thu, 21 Dec 2023

Re: GUC names in messages

On 21.12.23 07:24, Peter Smith wrote: #1. GUC name quoting. Some basic guidelines were decided and a patch is already pushed [1]. In messages containing configuration variable names, do not include quotes when the names are visibly not natural English words, such as when they

Re: logical decoding and replication of sequences, take 2

On 12/19/23 13:54, Christophe Pettus wrote: > Hi, > > I wanted to hop in here on one particular issue: > >> On Dec 12, 2023, at 02:01, Tomas Vondra >> wrote: >> - desirability of the feature: Random IDs (UUIDs etc.) are likely a much >> better solution for distributed (esp. active-active)

Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

Hello. Realized my last idea is invalid (because tuples are frozen by using dynamically calculated horizon) - so, don't waste your time on it :) Need to think a little bit more here. Thanks, Mikhail.

RE: Synchronizing slots from primary to standby

Dear Shveta, Thanks for updating the patch! Here is my comments for v52-0002. ~ system-views.sgml 01. ``` + + + + sync_state char + + + Defines slot synchronization state. This is meaningful on the physical + standby which has configured = true. +

Re: [DOC] Introducing Quick Start Guide to PL/pgSQL and PL/Python Documentation

Hi čt 21. 12. 2023 v 13:37 odesílatel Ishaan Adarsh napsal: > The recent documentation patches are part of my GSoC 2023 project > > to develop a comprehensive PostgreSQL extension development tutorial, it >

Re: index prefetching

On 12/21/23 07:49, Dilip Kumar wrote: > On Wed, Dec 20, 2023 at 7:11 AM Tomas Vondra > wrote: >> > I was going through to understand the idea, couple of observations > > -- > + for (int i = 0; i < PREFETCH_LRU_SIZE; i++) > + { > + entry = >prefetchCache[lru * PREFETCH_LRU_SIZE + i]; > + > +

Re: [DOC] Introducing Quick Start Guide to PL/pgSQL and PL/Python Documentation

The recent documentation patches are part of my GSoC 2023 project to develop a comprehensive PostgreSQL extension development tutorial, it assumes only a basic knowledge of Postgres and the target programming

Re: index prefetching

On 12/20/23 20:09, Robert Haas wrote: > On Tue, Dec 19, 2023 at 8:41 PM Tomas Vondra > ... >> I have imagined something like this: >> >> nodeIndexscan / index_getnext_slot() >> -> no callback, all TIDs are prefetched >> >> nodeIndexonlyscan / index_getnext_tid() >> -> callback checks VM for the

Re: Building PosgresSQL with LLVM fails on Solaris 11.4

Hi, On 2023-12-13 15:18:02 +, Sacha Hottinger wrote: > Thanks for your reply. > The reason I was suspicious with the warnings of the gcc build was, because > gmake check reported 138 out of 202 tests to have failed. I have attached the > output of gmake check. That'll likely be due to

Re: Detecting some cases of missing backup_label

On 12/21/23 07:37, Andres Freund wrote: On 2023-12-20 13:11:37 -0400, David Steele wrote: I've run this through a bunch of scenarios (in my head) with parallel backups and it does seem to hold up. I think we'd need to write the state file before XLOG_BACKUP_START just in case. Seems better to

Re: Track in pg_replication_slots the reason why slots conflict?

On Thu, Dec 21, 2023 at 5:04 PM Andres Freund wrote: > > Hi, > > On 2023-12-21 16:08:48 +0530, shveta malik wrote: > > On Thu, Dec 21, 2023 at 3:10 PM Andres Freund wrote: > > > > > > Hi, > > > > > > On 2023-12-21 09:21:04 +0900, Michael Paquier wrote: > > > > While listening at Bertrand's talk

Re: trying again to get incremental backup

On Wed, Dec 20, 2023 at 11:00 PM Alexander Lakhin wrote: > I've found several typos/inconsistencies introduced with 174c48050 and > dc2123400. Maybe you would want to fix them, while on it?: That's an impressively long list of mistakes in something I thought I'd been careful about. Sigh. I

Re: Detecting some cases of missing backup_label

Hi, On 2023-12-20 13:11:37 -0400, David Steele wrote: > I've run this through a bunch of scenarios (in my head) with parallel > backups and it does seem to hold up. > > I think we'd need to write the state file before XLOG_BACKUP_START just in > case. Seems better to have an extra state file

Re: Track in pg_replication_slots the reason why slots conflict?

Hi, On 2023-12-21 16:08:48 +0530, shveta malik wrote: > On Thu, Dec 21, 2023 at 3:10 PM Andres Freund wrote: > > > > Hi, > > > > On 2023-12-21 09:21:04 +0900, Michael Paquier wrote: > > > While listening at Bertrand's talk about logical decoding on standbys > > > last week at Prague, I got

Re: [PoC] Improve dead tuple storage for lazy vacuum

Hi, On 2023-12-21 14:41:37 +0700, John Naylor wrote: > I've attached v47, which is v46 plus some fixes for radix tree. Could either of you summarize what the design changes you've made in the last months are and why you've done them? Unfortunately this thread is very long, and the comments in

Re: Autonomous transactions 2023, WIP

> On 15 Dec 2023, at 16:28, Ivan Kush wrote: > > > > Hello. I'm working on the support of autonomous transactions in Postgres. > > # Summary > * Add pragma AUTONOMOUS_TRANSACTION in the functions. When function > contains this pragma, the it's executed autonomously > * Background workers

Re: partitioning and identity column

On 19.12.23 11:47, Ashutosh Bapat wrote: At this point I am looking for opinions on the above rules and whether the implementation is on the right track. This looks on the right track to me. 0001 - change to get_partition_ancestors() prologue. Can be reviewed and committed independent of

Re: Add --check option to pgindent

On Tue, 19 Dec 2023 at 17:54, Tristan Partin wrote: > I was envisioning something along the lines of: > > pgindent --check --diff > patches.txt > status=$? > patch with manual parsing > exit $status Okay, I got a working version. And I updated the pre-commit hook

int4->bool test coverage

I was surprised to learn that 2 is a valid boolean (thanks Berge): # select 2::boolean; bool ── t ... while '2' is not: # select '2'::boolean; ERROR: 22P02: invalid input syntax for type boolean: "2" LINE 1: select '2'::boolean; ^ LOCATION: boolin, bool.c:151 The first

Re: POC: GROUP BY optimization

Hi! On Sun, Oct 1, 2023 at 11:45 AM Andrei Lepikhov wrote: > > New version of the patch. Fixed minor inconsistencies and rebased onto > current master. Thank you (and other authors) for working on this subject. Indeed to GROUP BY clauses are order-agnostic. Reordering them in the most

Re: ci: Build standalone INSTALL file

> On 21 Dec 2023, at 10:16, Andres Freund wrote: > > Hi, > > On 2023-12-20 15:28:56 +0100, Daniel Gustafsson wrote: >> + time make -s -j${BUILD_JOBS} -C doc/src/sgml all INSTALL >> unrelated pet peeve: "make -C doc/src/sgml all" doesn't build all docs >> targets.. > > Well, building the

Re: [DOC] Introducing Quick Start Guide to PL/pgSQL and PL/Python Documentation

Hi čt 21. 12. 2023 v 11:18 odesílatel Peter Eisentraut napsal: > On 19.12.23 17:26, Ishaan Adarsh wrote: > > Subject: Clarification on the Purpose of the Patch > > > > Hi Peter, > > > > The intention was to address the challenge faced by newcomers in > > understanding how to write an extension

Re: Track in pg_replication_slots the reason why slots conflict?

On Thu, Dec 21, 2023 at 3:10 PM Andres Freund wrote: > > Hi, > > On 2023-12-21 09:21:04 +0900, Michael Paquier wrote: > > While listening at Bertrand's talk about logical decoding on standbys > > last week at Prague, I got surprised by the fact that we do not > > reflect in the catalogs the

Re: [DOC] Introducing Quick Start Guide to PL/pgSQL and PL/Python Documentation

On 19.12.23 17:26, Ishaan Adarsh wrote: Subject: Clarification on the Purpose of the Patch Hi Peter, The intention was to address the challenge faced by newcomers in understanding how to write an extension for PostgreSQL. The existing documentation, while comprehensive, lacks a consolidated

Re: speed up a logical replica setup

On Wed, Nov 1, 2023 at 7:10 PM Ashutosh Bapat wrote: > > Here are some comments about functionality and design. > > + > + > + pg_subscriber creates one replication slot for > + each specified database on the source server. The replication slot name > + contains a pg_subscriber prefix. These

Re: Postgres picks suboptimal index after building of an extended statistics

On Thu, Dec 21, 2023 at 10:41 AM Andrei Lepikhov wrote: > > On 18/12/2023 15:29, Alexander Korotkov wrote: > > Also, there is a set of patches [7], [8], and [9], which makes the > > optimizer consider path selectivity as long as path costs during the > > path selection. I've rechecked that none

Re: Track in pg_replication_slots the reason why slots conflict?

Hi, On 2023-12-21 09:21:04 +0900, Michael Paquier wrote: > While listening at Bertrand's talk about logical decoding on standbys > last week at Prague, I got surprised by the fact that we do not > reflect in the catalogs the reason why a conflict happened for a slot. > There are three of them

Re: Synchronizing slots from primary to standby

Hi, On Thu, Dec 21, 2023 at 02:23:12AM +, Zhijie Hou (Fujitsu) wrote: > On Wednesday, December 20, 2023 8:42 PM Zhijie Hou (Fujitsu) > wrote: > > > > Attach the V51 patch set which addressed Kuroda-san's comments. > > I also tried to improve the test in 0003 to make it stable. > > The

Re: Autonomous transactions 2023, WIP

Hi although I like the idea related to autonomous transactions, I don't think so this way is the best 1. The solution based on background workers looks too fragile - it can be easy to exhaust all background workers, and because this feature is proposed mainly for logging, then it is a little bit

Re: Synchronizing slots from primary to standby

On Wed, Dec 20, 2023 at 12:02 PM Peter Smith wrote: > > Here are some comments for the patch v50-0002. Thank You for the feedback. I have addressed these in v52. > == > GENERAL > > (I made a short study of all the ereports in this patch -- here are > some findings) > > ~~~ > > 0.1 Don't

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

Hi, In "Re: Make COPY format extendable: Extract COPY TO format implementations" on Mon, 11 Dec 2023 23:31:29 +0900, Masahiko Sawada wrote: > I've sketched the above idea including a test module in > src/test/module/test_copy_format, based on v2 patch. It's not splitted > and is dirty so

Re: Function to get invalidation cause of a replication slot.

On Thu, Dec 21, 2023 at 12:07 PM Michael Paquier wrote: > > On Thu, Dec 21, 2023 at 11:53:04AM +0530, Amit Kapila wrote: > > On Thu, Dec 21, 2023 at 11:18 AM Michael Paquier > > wrote: > > Yeah, if one uses them independently then there is no such guarantee. > > This could be possible in the

Re: ci: Build standalone INSTALL file

Hi, On 2023-12-21 08:39:26 +0900, Michael Paquier wrote: > On Wed, Dec 20, 2023 at 11:36:28AM -0500, Tom Lane wrote: > > Andres Freund writes: > >> We fairly regularly have commits breaking the generation of INSTALL. IIRC > >> we > >> recently discussed building it locally unconditionally, but

Re: ci: Build standalone INSTALL file

Hi, On 2023-12-20 15:28:56 +0100, Daniel Gustafsson wrote: > + time make -s -j${BUILD_JOBS} -C doc/src/sgml all INSTALL > unrelated pet peeve: "make -C doc/src/sgml all" doesn't build all docs > targets.. Well, building the PDF takes a *long* time and is rarely required. I think there's an

Re: ci: Build standalone INSTALL file

On 2023-12-21 08:44:33 +0900, Michael Paquier wrote: > On Wed, Dec 20, 2023 at 03:28:56PM +0100, Daniel Gustafsson wrote: > > + time make -s -j${BUILD_JOBS} -C doc/src/sgml all INSTALL > > unrelated pet peeve: "make -C doc/src/sgml all" doesn't build all docs > > targets.. > > That seems

Re: Remove MSVC scripts from the tree

On 20.12.23 16:43, Peter Eisentraut wrote: On 20.12.23 12:40, Andres Freund wrote: Hm, or perhaps we should just get rid of sed use altogether. The sepgsql case is trivially translateable to perl, and postprocess_dtrace.sed isn't much harder. Maybe yeah, but also it seems fine as is and we

Re: Postgres picks suboptimal index after building of an extended statistics

On 18/12/2023 15:29, Alexander Korotkov wrote: Also, there is a set of patches [7], [8], and [9], which makes the optimizer consider path selectivity as long as path costs during the path selection.  I've rechecked that none of these patches could resolve the original problem described in [1].

Re: Remove MSVC scripts from the tree

On Wed, Dec 20, 2023 at 11:39:15PM -0800, Andres Freund wrote: > Can't we teach the tool that it should not validate src/tools/win32tzlist.pl > on !windows? It's obviously windows specific code, and it's special case > enough that there doesn't seem like a need to develop it on !windows. I am not