RE: simplifying foreign key/RI checks

Hi amit, (sorry about not cc the hacker list) I have an issue about command id here. It's probably not directly related to your patch, so I am sorry if it bothers you. + /* +* Start the scan. To make the changes of the current command visible to +* the scan and for subseque

Re: repeated decoding of prepared transactions

On Tue, Mar 2, 2021 at 9:33 AM Amit Kapila wrote: > > 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. >

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

On Tue, 2 Mar 2021 at 04:32, 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. > > We should fix the error message to be less misleading. It would be good to change the message as

Re: 64-bit XIDs in deleted nbtree pages

On Tue, Mar 2, 2021 at 1:06 PM Masahiko Sawada wrote: > > 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 + para

Removing vacuum_cleanup_index_scale_factor

Hi all, I've started this new thread separated from the thread[1] to discuss removing vacuum_cleanup_index_scale_factor GUC parameter proposed by Peter Geoghegan. btvacuumcleanup() has been playing two roles: recycling deleted pages and collecting index statistics. This discussion focuses on the

Re: Add --tablespace option to reindexdb

On Mon, Mar 01, 2021 at 10:12:54AM -0800, Mark Dilger wrote: > Your check verifies that reindexing a system table on a new > tablespace fails, but does not verify what the failure was. I > wonder if you might want to make it more robust, something like: I was not sure if that was worth adding or

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

On Tue, Mar 2, 2021, at 06:22, Isaac Morland wrote: > On Tue, 2 Mar 2021 at 00:06, Joel Jacobson wrote: >> I find it strange two ranges of zero-length with different bounds are >> considered equal: >> >> SELECT '[7,7)'::int4range = '[8,8)'::int4range; >> ?column? >> -- >> t >> (1 row) >>

Re: libpq compression

> 26 февр. 2021 г., в 02:18, Daniil Zakhlystov > написал(а): > > Yes, there is still no possibility for compressed traffic pass-through for > poolers, > but do we actually need it? > I don’t see any solution except starting a new compression context for > each message in order to make it work

Re: New IndexAM API controlling index vacuum strategies

On Mon, Mar 1, 2021 at 7:00 PM Peter Geoghegan wrote: > I think that you're right. However, in practice it isn't harmful > because has_dead_tuples is only used when "all_visible = true", and > only to detect corruption (which should never happen). I think that it > should be fixed as part of this

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

"Joel Jacobson" writes: > Unless fixed, then the way I see it, I don't think we can use int4range[] for > regexp_positions(), Yeah. It's a cute idea, but the semantics aren't quite right. regards, tom lane

Re: repeated decoding of prepared transactions

On Tue, Mar 2, 2021 at 10:38 AM Ajin Cherian wrote: > > On Tue, Mar 2, 2021 at 3:03 PM Amit Kapila wrote: > > One minor comment: > + > + > + True if the slot is enabled for decoding prepared transactions. > Always > + false for physical slots. > + > + > > Ther

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

On Tue, 2 Mar 2021 at 00:06, Joel Jacobson wrote: > I find it strange two ranges of zero-length with different bounds are > considered equal: > > SELECT '[7,7)'::int4range = '[8,8)'::int4range; > ?column? > -- > t > (1 row) > > This seems like a bug to me. What am I missing here? > > Unle

Re: repeated decoding of prepared transactions

On Tue, Mar 2, 2021 at 3:03 PM Amit Kapila wrote: One minor comment: + + + True if the slot is enabled for decoding prepared transactions. Always + false for physical slots. + + There is an extra space before Always. But when rendered in html this is not seen,

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

On Tue, Mar 2, 2021, at 01:12, Mark Dilger wrote: > I like the idea so I did a bit of testing. I think the following should not > error, but does: > > +SELECT regexp_positions('foObARbEqUEbAz', $re$(?=beque)$re$, 'i'); > +ERROR: range lower bound must be less than or equal to range upper bound

Re: 64-bit XIDs in deleted nbtree pages

On Mon, Mar 1, 2021 at 8:06 PM Masahiko Sawada wrote: > I think that removing vacuum_cleanup_index_scale_factor in the back > branches would affect the existing installation much. It would be > better to have btree indexes not use this parameter while not changing > the contents of meta page. That

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

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: 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: 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: 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: [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: 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: 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: 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

[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: [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

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: 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: 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: 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: 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: [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: 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: 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: [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: 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: 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: 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: 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: 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: [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: [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: 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: 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: 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

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: 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: 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: 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: 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: 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: 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: [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: 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

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: 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

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: [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: 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: 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: [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: [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: 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.

> 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: [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

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] 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

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.

> 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: [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] 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

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] 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

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: 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: 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

[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: > > 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

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: 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

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

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

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

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: 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

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: 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

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

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

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

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

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: 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: 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

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

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 (?);

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

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: 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: 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

  1   2   >