Re: archive_command / pg_stat_archiver & documentation

Le lun. 1 mars 2021 à 08:36, Michael Paquier a écrit : > On Fri, Feb 26, 2021 at 10:03:05AM +0100, Benoit Lobréau wrote: > > Done here : https://commitfest.postgresql.org/32/3012/ > > Documenting that properly for the archive command, as already done for > restore_command, sounds good to me. I a

Re: A reloption for partitioned tables - parallel_workers

On Tue, Feb 23, 2021 at 7:24 PM houzj.f...@fujitsu.com wrote: > > > It seems the patch does not include the code that get the > > > parallel_workers from new struct " PartitionedTableRdOptions ", Did I miss > > something ? > > > > Aren't the following hunks in the v2 patch what you meant? > > > >

Re: Asynchronous Append on postgres_fdw nodes.

On Sat, Feb 20, 2021 at 3:35 PM Etsuro Fujita wrote: > So I’ll update the patch using your patch without the > postgresIterateForeignScan() change. Here is an updated version of the patch. Based on your idea of completing an in-progress command (if any) before sending a new command to the remote

Re: repeated decoding of prepared transactions

On Mon, Mar 1, 2021 at 7:23 AM Ajin Cherian wrote: > Few minor comments on 0002 patch = 1. ctx->streaming &= enable_streaming; - ctx->twophase &= enable_twophase; + } Spurious line addition. 2. - proallargtypes => '{name,name,text,oid,bool,bool,int4,xid,xid,pg_lsn

Re: archive_command / pg_stat_archiver & documentation

On Mon, Mar 1, 2021 at 4:33 PM Benoit Lobréau wrote: > > Le lun. 1 mars 2021 à 08:36, Michael Paquier a écrit : >> >> On Fri, Feb 26, 2021 at 10:03:05AM +0100, Benoit Lobréau wrote: >> > Done here : https://commitfest.postgresql.org/32/3012/ >> >> Documenting that properly for the archive command

Re: archive_command / pg_stat_archiver & documentation

I like the idea ! If it's not too complicated, I'd like to take a stab at it. Le lun. 1 mars 2021 à 10:16, Julien Rouhaud a écrit : > On Mon, Mar 1, 2021 at 4:33 PM Benoit Lobréau > wrote: > > > > Le lun. 1 mars 2021 à 08:36, Michael Paquier a > écrit : > >> > >> On Fri, Feb 26, 2021 at 10:03

Re: archive_command / pg_stat_archiver & documentation

On Mon, Mar 1, 2021 at 5:24 PM Benoit Lobréau wrote: > > I like the idea ! > > If it's not too complicated, I'd like to take a stab at it. Great! And it shouldn't be too complicated. Note that unfortunately this will likely not be included in pg14 as the last commitfest should begin today.

Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier?

> On 1 Mar 2021, at 05:46, Thomas Munro wrote: >> The 0003 patch to achieve $SUBJECT needs >> more discussion. > > Rebased. > > The more I think about it, the more I think that this approach is good > enough for an initial solution to the problem. It only affects > Windows, dropping tablespace

Re: [HACKERS] logical decoding of two-phase transactions

On Fri, Feb 26, 2021 at 4:28 PM Amit Kapila wrote: > > On Fri, Feb 26, 2021 at 9:56 AM Amit Kapila wrote: > > > > On Thu, Feb 25, 2021 at 12:32 PM Peter Smith wrote: > > > > > > > 5. You need to write/sync the spool file at prepare time because after > > restart between prepare and commit prepar

[PATCH] Add --create-only option to pg_dump/pg_dumpall

Hi, There is (to my knowledge) no direct way to get the `CREATE DATABASE` and assorted `GRANT foo ON DATABASE` etc. commands out of a pg_dump without having to edit the TOC or filter the SQL output with e.g. grep. It is not part of pg_dumpall -g, and if one uses pg_dump / pg_dumpall -s -C, one ge

Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)

On Mon, Nov 16, 2020 at 8:56 PM Michael Paquier wrote: > On Thu, Sep 24, 2020 at 05:55:17PM +1200, Thomas Munro wrote: > > Right, RestoreArchivedFile() uses system(), so I guess it can hang > > around for a long time after unexpected postmaster exit on every OS if > > the command waits. To respon

Re: Regex back-reference semantics and performance

On Mon, Mar 1, 2021, at 01:53, Tom Lane wrote: >0001-fix-backref-semantics.patch >0002-backref-performance-hack.patch I've successfully tested both patches. On HEAD the trouble-query took forever, I cancelled it after 23 minutes. HEAD (f5a5773a9dc4185414fe538525e20d8512c2ba35): SELECT regexp_mat

Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier?

On Mon, Mar 1, 2021 at 11:07 PM Daniel Gustafsson wrote: > I don't know Windows at all so I can't really comment on that portion, but > from > my understanding of procsignalbarriers I think this seems right. No tests > break when forcing the codepath to run on Linux and macOS. Hey Daniel, Than

Re: [PATCH] Note effect of max_replication_slots on subscriber side in documentation.

On Sat, Feb 27, 2021 at 2:35 PM Amit Kapila wrote: > > On Sat, Feb 27, 2021 at 2:47 AM Paul Martinez wrote: > > > > On Fri, Feb 26, 2021 at 5:22 AM Amit Kapila wrote: > > > > > > https://www.postgresql.org/docs/devel/logical-replication-config.html > > > > > > > Ah, yep. I added a clause to the

Re: [HACKERS] Custom compression methods

On Mon, Mar 1, 2021 at 11:06 AM Justin Pryzby wrote: > Thanks. It seems like that explains it. > I think if that's a problem with recent versions, then you'll have to > conditionally disable slicing. > https://packages.debian.org/liblz4-dev > > Slicing isn't generally usable if it sometimes make

Re: Improving connection scalability: GetSnapshotData()

Hi, Greatly appreciate if you could please reply to the following questions as time allows. I have seen previous discussion/patches on a built-in connection pooler. How does this scalability improvement, particularly idle connection improvements etc, affect that built-in pooler need, if any? Sa

Re: Improving connection scalability: GetSnapshotData()

- Mensagem original - > De: "AJG" > Para: "Pg Hackers" > Enviadas: Sábado, 27 de fevereiro de 2021 14:40:58 > Assunto: Re: Improving connection scalability: GetSnapshotData() > Hi, > Greatly appreciate if you could please reply to the following questions as > time allows. > I have se

Re: proposal: psql –help reflecting service or URI usage

Hi Mark, I revisited my first admittedly naive and faulty attempt. > On 28. Feb, 2021, at 19:10, Paul Förster wrote: > >> but of course being careful to still fit in the line length limit. > I agree to all, thanks. What is the line length limit? still, what is the line length limit? Where do I

Re: [PATCH] Bug fix in initdb output

On Mon, Mar 1, 2021 at 5:52 AM Nitin Jadhav wrote: > >> Please share your thoughts on this. If we go ahead with this change, > then we need to back-patch. I would be happy to create those patches. > A full path works, even with the slashes. The commiter will take care of back-patching, if needed

Improvements in prepared statements

Hello, some improvements in the prepared statements would facilitate their use from applications: - Use of table and column names in prepared statements. Example: select # from # where # = ?; - Use of arrays in prepared statements. Example: select # from article where id in (?);

SSL negotiation error on massive connect/disconnect

Hi! I have primary server on port 55942 and two standbys on 55943 and 55944. Then use connection string like "postgresql://127.0.0.1:55942,127.0.0.1:55943,127.0.0.1:55944/postgres" to connect to the servers via psql. Everything works perfectly no matter how many attempts to connect I do. But

Re: Improvements in prepared statements

Hi po 1. 3. 2021 v 15:20 odesílatel Alejandro Sánchez napsal: > Hello, some improvements in the prepared statements would facilitate > their use from applications: > > - Use of table and column names in prepared statements. > > Example: select # from # where # = ?; > > - Use of arrays in pre

Re: proposal: psql –help reflecting service or URI usage

On Mon, Mar 1, 2021, at 10:32 AM, Paul Förster wrote: > still, what is the line length limit? Where do I find it? We try to limit it to 80 characters but it is not a hard limit. Long descriptions should certainly be split into multiple lines.

Re: macOS SIP, next try

Peter Eisentraut writes: > I have since learned that there is a way to disable only the part of SIP > that is relevant for us. This seems like a useful compromise, and it > appears that a number of other open-source projects are following the > same route. I suggest the attached documentation

Re: A reloption for partitioned tables - parallel_workers

On Mon, 2021-03-01 at 17:39 +0900, Amit Langote wrote: > > I am not sure. > > IMO, for normal table, we use the following macro to get the > > parallel_workers: > > -- > > /* > > * RelationGetParallelWorkers > > * Returns the relation's parallel_workers relopti

2019-03 CF now in progress

Hackers, The 2019-03 commitfest is now in progress. It's a big one as usual. Needs review: 213. Waiting on Author: 21. Ready for Committer: 28. Committed: 29. Withdrawn: 3. Total: 294. If you are a patch author please check http://commitfest.cputube.org to be sure your patch still applies, com

We should stop telling users to "vacuum that database in single-user mode"

It looks like we are unnecessarily instructing our usiers to vacuum their databases in single-user mode when just vacuuming would be enough. We should fix the error message to be less misleading. == The story I think most of us have at some time seen the following message, if not in their own da

Re: Improvements in prepared statements

Hello, as far as I know it is not done in JDBC, in many frameworks it is.Although the execution plans cannot be reused it would be somethingvery useful. It is included in a lot of frameworks and is a recurrentquestion in database forums. It would be nice if it was included in plain SQL. Best regard

Re: Improving connection scalability: GetSnapshotData()

On 27.02.2021 20:40, AJG wrote: Hi, Greatly appreciate if you could please reply to the following questions as time allows. I have seen previous discussion/patches on a built-in connection pooler. How does this scalability improvement, particularly idle connection improvements etc, affect th

Re: Improvements in prepared statements

po 1. 3. 2021 v 16:39 odesílatel Alejandro Sánchez napsal: > Hello, as far as I know it is not done in JDBC, in many frameworks it is. > > Although the execution plans cannot be reused it would be something > > very useful. It is included in a lot of frameworks and is a recurrent >

Re: proposal: psql –help reflecting service or URI usage

> On Feb 28, 2021, at 10:10 AM, Paul Förster wrote: > > Hi Mark, > >> On 28. Feb, 2021, at 17:54, Mark Dilger wrote: >> >> "definited" is a typo. > > yes, definitely a typo, sorry. Thanks for pointing this out. > >> Should this say "as defined in pg_service.conf"? That's the default, but

Re: Improvements in prepared statements

The benefit is ease of use. One of the great advantages of prepared statements is nothaving to concatenate strings. The use of arrays would also be very useful. query("select " + column1 + "," + column2 from " " + table + " where id in (?), ids); VS query("select # from # where id in (?)", column

Re: Improvements in prepared statements

po 1. 3. 2021 v 17:08 odesílatel Alejandro Sánchez napsal: > The benefit is ease of use. One of the great advantages of prepared > statements is not > > having to concatenate strings. The use of arrays would also be very useful. > > > query("select " + column1 + "," + column2 from " " + table +

Re: Improvements in prepared statements

po 1. 3. 2021 v 17:15 odesílatel Pavel Stehule napsal: > > > po 1. 3. 2021 v 17:08 odesílatel Alejandro Sánchez > napsal: > >> The benefit is ease of use. One of the great advantages of prepared >> statements is not >> >> having to concatenate strings. The use of arrays would also be very usefu

Re: Improvements in prepared statements

It is a matter of taste. I think this functionality would be better in SQLand be the same for all languages without the need to use string functions. El lun, 01-03-2021 a las 17:15 +0100, Pavel Stehule escribió: > po 1. 3. 2021 v 17:08 odesílatel Alejandro Sánchez < > a...@nexttypes.com> napsal: >

Re: Improvements in prepared statements

Hi po 1. 3. 2021 v 17:26 odesílatel Alejandro Sánchez napsal: > It is a matter of taste. I think this functionality would be better in SQL > > and be the same for all languages without the need to use string functions. > > You can try to implement it, and send a patch. But I think a) it will be

Re: Improvements in prepared statements

I have already implemented this in my Java project with some kind of SQL preprocessor. I leave the idea here in case more people are interested and PostgreSQL developers findit convenient to include it. It is just string concatenation but it is a sintactic sugar very useful in any SQL application.

Re: Add --tablespace option to reindexdb

> On Feb 25, 2021, at 10:49 PM, Michael Paquier wrote: > > Hi all, Hi Michael, > Since c5b2860, it is possible to specify a tablespace for a REINDEX, > but the equivalent option has not been added to reindexdb. Attached > is a patch to take care of that. > > This includes documentation and

[PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

Hi, I suggest adding a new function, regexp_positions(), which works exactly like regexp_matches(), except it returns int4range[] start/end positions for *where* the matches occurs. I first thought I could live without this function, and just get the positions using strpos(), but as Andreas Karl

Re: Add --tablespace option to reindexdb

> On Feb 25, 2021, at 10:49 PM, Michael Paquier wrote: > > While on it, I have added tests for toast tables and indexes with a > tablespace move during a REINDEX. In t/090_reindexdb.pl, you add: +# Create a tablespace for testing. +my $ts = $node->basedir . '/regress_reindex_tbspace'; +mkd

Re: Add --tablespace option to reindexdb

> On Feb 25, 2021, at 10:49 PM, Michael Paquier wrote: > > Anyway, I would rather group the whole set of > tests together, and using the --tablespace option introduced here > within a TAP test does the job. Your check verifies that reindexing a system table on a new tablespace fails, but doe

Re: [PATCH] Bug fix in initdb output

On 2021-Mar-01, Juan José Santamaría Flecha wrote: > On Mon, Mar 1, 2021 at 5:52 AM Nitin Jadhav > wrote: > > > > >> Please share your thoughts on this. If we go ahead with this change, > > then we need to back-patch. I would be happy to create those patches. > > A full path works, even with th

Re: [PATCH] Cross-reference comments on signal handling logic

> On Jan 17, 2021, at 11:51 PM, Craig Ringer > wrote: > > In src/backend/postmaster/interrupt.c: + * These handlers are NOT used by normal user backends as they do not support vs. + * Most backends use this handler. These two comments seem to contradict. If interrupt.c contains handler

Re: [PATCH] Bug fix in initdb output

El lun., 1 mar. 2021 19:16, Alvaro Herrera escribió: > > I don't get it. I thought the windows API accepted both forward slashes > and backslashes as path separators. Did you try the command and see it > fail? > This is not a problem with the APi, but the shell. e.g. when using a CMD: - This

Re: [PATCH] Bug fix in initdb output

On 2021-Mar-01, Juan José Santamaría Flecha wrote: > This is not a problem with the APi, but the shell. e.g. when using a CMD: > > - This works: > c:\>c:\Windows\System32\notepad.exe > c:\>c:/Windows/System32/notepad.exe > c:\>/Windows/System32/notepad.exe > > - This doesn't: > c:\>./Windows/Sys

Re: [PATCH] Bug fix in initdb output

On Mon, Mar 1, 2021 at 7:50 PM Alvaro Herrera wrote: > On 2021-Mar-01, Juan José Santamaría Flecha wrote: > > > This is not a problem with the APi, but the shell. e.g. when using a CMD: > > > > - This works: > > c:\>c:\Windows\System32\notepad.exe > > c:\>c:/Windows/System32/notepad.exe > > c:\>/

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

> On Feb 9, 2021, at 10:43 AM, Pavel Borisov wrote: > > вт, 9 февр. 2021 г. в 01:46, Mark Dilger : > > > > On Feb 8, 2021, at 2:46 AM, Pavel Borisov wrote: > > > > 0002 - is a temporary hack for testing. It will allow inserting duplicates > > in a table even if an index with the exact nam

Re: Use extended statistics to estimate (Var op Var) clauses

> On Nov 12, 2020, at 5:14 PM, Tomas Vondra > wrote: > > <0001-Support-estimation-of-clauses-of-the-form-V-20201113.patch> Your patch no longer applies. Can we get a new version please? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

> > The regression test you provided is not portable. I am getting lots of > errors due to differing output of the form "page lsn=0/4DAD7E0". You might > turn this into a TAP test and use a regular expression to check the output. > May I ask you to ensure you used v3 of a patch to check? I've mad

buildfarm windows checks / tap tests on windows

Hi, As part of trying to make the aio branch tests on cirrus CI pass with some tap tests I noticed that "src/tools/msvc/vcregress.pl recoverycheck" hangs. A long phase of remote debugging later I figured out that that's not a fault of the aio branch - it also doesn't pass on master (fixed in [1]).

Re: [PATCH] Bug fix in initdb output

On 2021-Mar-01, Juan José Santamaría Flecha wrote: > On Mon, Mar 1, 2021 at 7:50 PM Alvaro Herrera > wrote: > > Ah, so another way to fix it would be to make the path to pg_ctl be > > absolute? > > Yes, that's right. If you call initdb with an absolute path you won't see a > problem. So, is ma

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

> On Mar 1, 2021, at 12:05 PM, Pavel Borisov wrote: > > The regression test you provided is not portable. I am getting lots of > errors due to differing output of the form "page lsn=0/4DAD7E0". You might > turn this into a TAP test and use a regular expression to check the output. > May I

Re: Regex back-reference semantics and performance

"Joel Jacobson" writes: > On Mon, Mar 1, 2021, at 01:53, Tom Lane wrote: >> 0001-fix-backref-semantics.patch >> 0002-backref-performance-hack.patch > I've successfully tested both patches. Again, thanks for testing! > On HEAD the trouble-query took forever, I cancelled it after 23 minutes. Yea

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

Mark Dilger writes: > Yes, my review was of v2. Updating to v3, I see that the test passes on my > laptop. It still looks brittle to have all the tid values in the test > output, but it does pass. Hm, anyone tried it on 32-bit hardware? regards, tom lane

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

> > If bt_index_check() and bt_index_parent_check() are to have this > functionality, shouldn't there be an option controlling it much as the > option (heapallindexed boolean) controls checking whether all entries in > the heap are indexed in the btree? It seems inconsistent to have an option > to

Re: Improvements in prepared statements

Using any() has the disadvantage that in JDBC it is necessaryto create an array with connection.createArrayOf() and indicatethe type of the array, which complicates automation. With statement.setObject() you can pass any type of parameter.JDBC could add a method that doesn't need the array type. St

Re: Use extended statistics to estimate (Var op Var) clauses

On 3/1/21 8:58 PM, Mark Dilger wrote: On Nov 12, 2020, at 5:14 PM, Tomas Vondra wrote: <0001-Support-estimation-of-clauses-of-the-form-V-20201113.patch> Your patch no longer applies. Can we get a new version please? I do not plan to work on this patch in the 2021-03 commitfest. I'll

Re: [PATCH] Bug fix in initdb output

On Mon, Mar 1, 2021 at 9:09 PM Alvaro Herrera wrote: > On 2021-Mar-01, Juan José Santamaría Flecha wrote: > > > On Mon, Mar 1, 2021 at 7:50 PM Alvaro Herrera > > wrote: > > > > Ah, so another way to fix it would be to make the path to pg_ctl be > > > absolute? > > > > Yes, that's right. If you c

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

> On Mar 1, 2021, at 12:23 PM, Pavel Borisov wrote: > > If bt_index_check() and bt_index_parent_check() are to have this > functionality, shouldn't there be an option controlling it much as the option > (heapallindexed boolean) controls checking whether all entries in the heap > are indexed

Re: Improvements in prepared statements

po 1. 3. 2021 v 21:35 odesílatel Alejandro Sánchez napsal: > Using any() has the disadvantage that in JDBC it is necessary > > to create an array with connection.createArrayOf() and indicate > > the type of the array, which complicates automation. > > > With statement.setObject() you can pass any

Why does the BF sometimes not dump regression.diffs?

Hello, I saw this failure after a recent commit (though the next build succeeded, and I don't yet have any particular reason to believe that the commits it blamed are at fault, we'll see...): https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gombessa&dt=2021-03-01%2004%3A58%3A17 Strangely,

Re: new heapcheck contrib module

On Wed, Feb 24, 2021 at 1:55 PM Mark Dilger wrote: > [ new patches ] Regarding 0001: There seem to be whitespace-only changes to the comment for select_loop(). I wonder if the ParallelSlotsSetupOneDB()/ParallelSlotsSetupMinimal() changes could be simpler. First idea: Suppose you had ParallelSlo

Re: [PATCH] Bug fix in initdb output

On 2021-Mar-01, Juan José Santamaría Flecha wrote: > Uhm, now that you point it out, an absolute path would make the message > more consistent and reusable. Well. This code was introduced in a00c58314745, with discussion at http://postgr.es/m/CAHeEsBeAe1FeBypT3E8R1ZVZU0e8xv3A-7BHg6bEOi=jzny...@m

Re: enable_incremental_sort changes query behavior

Just a bump to see if there is a time frame for a fix on this. Google Cloud doesn't yet support setting the *enable_incremental_sort * flag yet. Was able to temporarily resolve by running the following though: ALTER DATABASE corpdb SET enable_incremental_sort TO OFF; Hope this helps others until

Re: 64-bit XIDs in deleted nbtree pages

On Sun, Feb 28, 2021 at 8:08 PM Masahiko Sawada wrote: > > Even though "the letter of the law" favors removing the > > vacuum_cleanup_index_scale_factor GUC + param in the way I have > > outlined, that is not the only thing that matters -- we must also > > consider "the spirit of the law". > > I

Re: new heapcheck contrib module

> On Mar 1, 2021, at 1:14 PM, Robert Haas wrote: > > On Wed, Feb 24, 2021 at 1:55 PM Mark Dilger > wrote: >> [ new patches ] > > Regarding 0001: > > There seem to be whitespace-only changes to the comment for select_loop(). > > I wonder if the ParallelSlotsSetupOneDB()/ParallelSlotsSetupMi

Re: enable_incremental_sort changes query behavior

On 3/1/21 8:23 PM, rbrooks wrote: Just a bump to see if there is a time frame for a fix on this. Google Cloud doesn't yet support setting the *enable_incremental_sort * flag yet. Was able to temporarily resolve by running the following though: ALTER DATABASE corpdb SET enable_incremental_sort T

Re: Table AM modifications to accept column projection lists

On Thu, Dec 31, 2020 at 01:02:24PM -0800, Soumyadeep Chakraborty wrote: > Hey Masahiko, > > I added it to the Jan CF (https://commitfest.postgresql.org/31/2922/). > > PFA a rebased version against latest head. Thanks for working on this. - pgstat_progress_update_param(PROGRESS_AN

Re: Table AM modifications to accept column projection lists

On Mon, 2021-03-01 at 16:59 -0600, Justin Pryzby wrote: > - > pgstat_progress_update_param(PROGRESS_ANALYZE_CURRENT_CHILD_TABLE_RELID, > > > >

Re: TRIM_ARRAY

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, failed Documentation:tested, failed This basically does what it says, and the code looks good. Th

Re: 2019-03 CF now in progress

Could I suggest to update the CF APP to allow: | Target version: 15 Also, I wanted to suggest that toward the end of the devel cycle, that committers set/unset target version to allow more focused review effort. And so it's not a total surprise when something isn't progressed. And as a simple way

Re: TRIM_ARRAY

On 3/2/21 12:14 AM, Dian Fay wrote: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, failed > Documentation:tested, failed Thank you for l

Re: TRIM_ARRAY

Dian Fay writes: > This basically does what it says, and the code looks good. The > documentation is out of alphabetical order (trim_array should appear > under cardinality rather than over)) but good otherwise. I was able to > "break" the function with an untyped null in psql: > select trim_arra

Re: [PATCH] regexp_positions ( string text, pattern text, flags text ) → setof int4range[]

> On Mar 1, 2021, at 9:38 AM, Joel Jacobson wrote: > > Forgive me for just sending a patch without much discussion on the list, > but it was so easy to implement, so I thought an implementation can > help the discussion on if this is something we want or not. I like the idea so I did a bit of

Re: [PATCH] Bug fix in initdb output

On Mon, Mar 1, 2021 at 10:18 PM Alvaro Herrera wrote: > On 2021-Mar-01, Juan José Santamaría Flecha wrote: > > > Uhm, now that you point it out, an absolute path would make the message > > more consistent and reusable. > > Well. This code was introduced in a00c58314745, with discussion at > > ht

Re: Why does the BF sometimes not dump regression.diffs?

On 3/1/21 4:05 PM, Thomas Munro wrote: > Hello, > > I saw this failure after a recent commit (though the next build > succeeded, and I don't yet have any particular reason to believe that > the commits it blamed are at fault, we'll see...): > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl

Re: Why does the BF sometimes not dump regression.diffs?

On Tue, Mar 2, 2021 at 1:32 PM Andrew Dunstan wrote: > The version numbering is a bit misleading on fairywren, which, as it's a > machine I control runs from a git checkout, which clearly is later than > REL_11 even though that's what the version string says. Commit 13d2143 > fixed this. It was in

Re: TRIM_ARRAY

On Mon Mar 1, 2021 at 6:53 PM EST, Vik Fearing wrote: > > This basically does what it says, and the code looks good. The > > documentation is out of alphabetical order (trim_array should appear > > under cardinality rather than over)) but good otherwise. > > Hmm. It appears between cardinality and

Re: repeated decoding of prepared transactions

On Mon, Mar 1, 2021 at 8:08 PM Amit Kapila wrote: > Few minor comments on 0002 patch > = > 1. > ctx->streaming &= enable_streaming; > - ctx->twophase &= enable_twophase; > + > } > > Spurious line addition. Deleted. > > 2. > - proallargtypes => > '{name,name,text,

Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)

On Tue, Mar 2, 2021 at 12:00 AM Thomas Munro wrote: > On Mon, Nov 16, 2020 at 8:56 PM Michael Paquier wrote: > > No objections with the two changes from pg_usleep() to WaitLatch() so > > they could be applied separately first. > > I thought about committing that first part, and got as far as > sp

Re: [PATCH] Bug fix in initdb output

On Tue, Mar 02, 2021 at 01:28:57AM +0100, Juan José Santamaría Flecha wrote: > For me it is a +1 for the change to absolute. Let's see if more people want > to weigh in on the matter. FWIW, I don't think that it is a good idea to come back to this decision for *nix platforms, so I would let it as-

Re: archive_command / pg_stat_archiver & documentation

On Mon, Mar 01, 2021 at 05:17:06PM +0800, Julien Rouhaud wrote: > Maybe this can be better addressed than with a link in the > documentation. The final outcome is that it can be difficult to > monitor the archiver state in such case. That's orthogonal to this > patch but maybe we can add a new "a

Re: TRIM_ARRAY

On 3/2/21 1:02 AM, Dian M Fay wrote: > On Mon Mar 1, 2021 at 6:53 PM EST, Vik Fearing wrote: >>> This basically does what it says, and the code looks good. The >>> documentation is out of alphabetical order (trim_array should appear >>> under cardinality rather than over)) but good otherwise. >> >>

Re: [BUG] Autovacuum not dynamically decreasing cost_limit and cost_delay

On Mon, Feb 8, 2021 at 11:49 PM Mead, Scott wrote: > > Hello, >I recently looked at what it would take to make a running autovacuum > pick-up a change to either cost_delay or cost_limit. Users frequently will > have a conservative value set, and then wish to change it when autovacuum > ini

Re: doc review for v14

On Mon, Mar 01, 2021 at 03:17:40PM +0900, Michael Paquier wrote: > You could say here "Checksums can be enabled", but "normally" does not > sound bad to me either as it insists on the fact that it is better to > do that when the cluster is initdb'd as this has no downtime compared > to enabling che

Re: simplifying foreign key/RI checks

On Mon, Mar 1, 2021 at 3:14 PM Corey Huinker wrote: >> > It seems to me 1 (RI_PLAN_CHECK_LOOKUPPK) is still alive. (Yeah, I >> > know that doesn't mean the usefulness of the macro but the mechanism >> > the macro suggests, but it is confusing.) On the other hand, >> > RI_PLAN_CHECK_LOOKUPPK_FROM_P

Re: A reloption for partitioned tables - parallel_workers

On Tue, Mar 2, 2021 at 12:10 AM Laurenz Albe wrote: > Here is an updated patch with this fix. Thanks for updating the patch. I was about to post an updated version myself but you beat me to it. > I added regression tests and adapted the documentation a bit. > > I also added support for lowering

Re: We should stop telling users to "vacuum that database in single-user mode"

On Mon, Mar 01, 2021 at 04:32:23PM +0100, Hannu Krosing wrote: > It looks like we are unnecessarily instructing our usiers to vacuum their > databases in single-user mode when just vacuuming would be enough. > When I started looking at improving the situation I discovered, that there > already is

Re: repeated decoding of prepared transactions

On Tue, Mar 2, 2021 at 6:37 AM Ajin Cherian wrote: > > On Mon, Mar 1, 2021 at 8:08 PM Amit Kapila wrote: > > > Few minor comments on 0002 patch > > = > > 1. > > ctx->streaming &= enable_streaming; > > - ctx->twophase &= enable_twophase; > > + > > } > > > > Spurious

Re: [PATCH] pgbench: Bug fix for the -d option

2021-02-26 20:30, Michael Paquier wrote: By the way, I can help but wonder why pgbench has such a different handling for the user name, fetching first PGUSER and then looking at the options while most of the other binaries use get_user_name(). It seems to me that we could simplify the handling a

[PATCH] psql : Improve code for help option

Hi. I found some redundant code in psql/help.c, so I propose a patch to fix it. In the current help.c, the variable "user" is set to the value of $PGUSER (or get_user_name). However, $PGUSER is referenced again in the code that follows. We can replace this part with "user", I think. Regards.

Re: New IndexAM API controlling index vacuum strategies

On Sun, Feb 21, 2021 at 10:28 PM Masahiko Sawada wrote: > Sorry for the late response. Me too! > 1. Whereas skipping index vacuum and heap vacuum is a very attractive > improvement, if we skip that by default I wonder if we need a way to > disable it. Vacuum plays a role in cleaning and diagnosi

Re: archive_command / pg_stat_archiver & documentation

On Tue, Mar 2, 2021 at 9:29 AM Michael Paquier wrote: > > On Mon, Mar 01, 2021 at 05:17:06PM +0800, Julien Rouhaud wrote: > > Maybe this can be better addressed than with a link in the > > documentation. The final outcome is that it can be difficult to > > monitor the archiver state in such case.

Re: 64-bit XIDs in deleted nbtree pages

On Mon, Mar 1, 2021 at 1:40 PM Peter Geoghegan wrote: > > Since it seems not a bug I personally think we don't need to do > > anything for back branches. But if we want not to trigger an index > > scan by vacuum_cleanup_index_scale_factor, we could change the default > > value to a high value (say

Re: [PATCH] refactor ATExec{En,Dis}ableRowSecurity

On Mon, Mar 01, 2021 at 03:30:44PM +0900, Michael Paquier wrote: > 0001 is a clean simplification and a good catch, so I'll see about > applying it. 0002 just makes the code more confusing to the reader > IMO, and its interface could easily lead to unwanted errors. 0001 has been applied as of fab

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Wed, Jan 20, 2021 at 12:43 AM Julien Rouhaud wrote: > > On Fri, Jan 8, 2021 at 1:07 AM Julien Rouhaud wrote: > > > > v15 that fixes recent conflicts. > > Rebase only, thanks to the cfbot! V16 attached. Recent commit exposed that the explain_filter() doesn't filter negative sign. This can no

Re: REINDEX backend filtering

On Fri, Feb 26, 2021 at 11:17:26AM +0100, Magnus Hagander wrote: > On Fri, Feb 26, 2021 at 11:07 AM Julien Rouhaud wrote: > > > > It means that you'll have to distribute the work on a per-table basis > > rather than a per-index basis. The time spent to find out that a > > table doesn't have any i

Re: repeated decoding of prepared transactions

On Tue, Mar 2, 2021 at 8:20 AM vignesh C wrote: > > > I have a minor comment regarding the below: > + > + > + two_phase bool > + > + > + True if two-phase commits are enabled on this slot. > + > + > > Can we change something like: > True if the slot is

Re: 64-bit XIDs in deleted nbtree pages

On Tue, Mar 2, 2021 at 6:40 AM Peter Geoghegan wrote: > > On Sun, Feb 28, 2021 at 8:08 PM Masahiko Sawada wrote: > > > Even though "the letter of the law" favors removing the > > > vacuum_cleanup_index_scale_factor GUC + param in the way I have > > > outlined, that is not the only thing that matt

Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier?

On Tue, Feb 2, 2021 at 11:16 AM Thomas Munro wrote: > Right, the checkpoint itself is probably worse than this > "close-all-your-files!" thing in some cases [...] I've been wondering what obscure hazards these "tombstone" (for want of a better word) files guard against, besides the one described

  1   2   >