Re: First-draft back-branch release notes are up for review

On Sat, Nov 9, 2019 at 6:52 AM Tom Lane wrote: > > See > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1add2e09b9a4c2d2c72ce51991fa4efaf577a29f > > Please send any corrections by Sunday. > I have read it once and didn't find any obvious errors. -- With Regards, Amit

Re: proposal: minscale, rtrim, btrim functions for numeric

so 9. 11. 2019 v 21:34 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > four years ago Marko Tiikkaja send a patch for numeric_trim functions. > This > > functions removed ending zeroes from numeric value. This is useful > feature, > > but there was not any progress on this patch. I

Re: Handy describe_pg_lock function

Andres Freund writes: > On 2019-11-08 14:49:25 +0800, Craig Ringer wrote: >> I recently found the need to pretty-print the contents of pg_locks. So >> here's a little helper to do it, for anyone else who happens to have that >> need. pg_identify_object is far from adequate for the purpose. Reckon

Re: Coding in WalSndWaitForWal

On Sun, Nov 10, 2019 at 5:51 AM Jeff Janes wrote: > > in src/backend/replication/walsender.c, there is the section quoted below. > It looks like nothing interesting happens between the GetFlushRecPtr just > before the loop starts, and the one inside the loop the first time through > the loop.

Re: CountDBSubscriptions check in dropdb

On Sat, Nov 9, 2019 at 9:38 PM Tom Lane wrote: > > Amit Kapila writes: > > On Sat, Nov 9, 2019 at 3:58 PM Peter Eisentraut > > wrote: > >> On 2019-11-08 14:38, Amit Kapila wrote: > >>> I am planning to commit and backpatch this till PG10 where it was > >>> introduced on Monday morning (IST).

Coding in WalSndWaitForWal

in src/backend/replication/walsender.c, there is the section quoted below. It looks like nothing interesting happens between the GetFlushRecPtr just before the loop starts, and the one inside the loop the first time through the loop. If we want to avoid doing CHECK_FOR_INTERRUPTS(); etc.

Re: Using multiple extended statistics for estimates

On 11/9/19 12:33 PM, Mark Dilger wrote: On 11/6/19 11:58 AM, Tomas Vondra wrote: On Wed, Nov 06, 2019 at 08:54:40PM +0100, Tomas Vondra wrote: On Mon, Oct 28, 2019 at 04:20:48PM +0100, Tomas Vondra wrote: Hi, PostgreSQL 10 introduced extended statistics, allowing us to consider

segfault in geqo on experimental gcc animal

QL 13devel on x86_64-pc-linux-gnu, compiled by gcc (GCC) 10.0.0 20191102 (experimental), 64-bit first failure: 2019-11-09 11:19:36.277 CET [42512:1] LOG: starting PostgreSQL 13devel on x86_64-pc-linux-gnu, compiled by gcc (GCC) 10.0.0 20191109 (experimental), 64-bit so it sure looks like a gcc upgr

Re: Handy describe_pg_lock function

Hi, On 2019-11-08 14:49:25 +0800, Craig Ringer wrote: > I recently found the need to pretty-print the contents of pg_locks. So > here's a little helper to do it, for anyone else who happens to have that > need. pg_identify_object is far from adequate for the purpose. Reckon I > should turn it

Re: int64-timestamp-dependent test vs. --disable-integer-timestamps

Hi, On 2019-11-09 12:06:33 -0500, Tom Lane wrote: > Commits a7145f6bc et al. added a test to verify integer overflow > detection in interval_mul. The buildfarm has now reminded me that > you're not going to get integer overflow if timestamps ain't integers, > cf >

Re: logical replication empty transactions

On Fri, Nov 8, 2019 at 8:59 PM Euler Taveira wrote: > Em seg., 21 de out. de 2019 às 21:20, Jeff Janes > escreveu: > > > > After setting up logical replication of a slowly changing table using > the built in pub/sub facility, I noticed way more network traffic than made > sense. Looking into I

Re: base backup client as auxiliary backend process

On 2019-11-07 05:16, Michael Paquier wrote: The current defaults of pg_basebackup have been thought so as the backups taken have a good stability and so as monitoring is eased thanks to --wal-method=stream and the use of replication slots. Shouldn't the use of a least a temporary replication

Re: Option to dump foreign data in pg_dump

On 20 Sep 2019, at 17:20, Luis Carril wrote:I took a look at this patch again today for a review of the latest version.While I still think it's a potential footgun due to read-only FDW's, I can seeusecases for having it so I'm mildly +1 on adding it.The patch applies to master with a little bit

Re: proposal: minscale, rtrim, btrim functions for numeric

Pavel Stehule writes: > four years ago Marko Tiikkaja send a patch for numeric_trim functions. This > functions removed ending zeroes from numeric value. This is useful feature, > but there was not any progress on this patch. I think so this feature can > be interesting, so I would to revitalize

Re: Using multiple extended statistics for estimates

On 11/6/19 11:58 AM, Tomas Vondra wrote: On Wed, Nov 06, 2019 at 08:54:40PM +0100, Tomas Vondra wrote: On Mon, Oct 28, 2019 at 04:20:48PM +0100, Tomas Vondra wrote: Hi, PostgreSQL 10 introduced extended statistics, allowing us to consider correlation between columns to improve estimates,

Re: Removing pg_pltemplate and creating "trustable" extensions

I wrote: > Stephen Frost writes: >> Really? Why do you think that DB ownership shouldn't be enough for >> this, for trusted extensions? > DB owners have never been particularly highly privileged in the past. > I think that suddenly saying they can install extensions is moving > the

proposal: minscale, rtrim, btrim functions for numeric

Hi, four years ago Marko Tiikkaja send a patch for numeric_trim functions. This functions removed ending zeroes from numeric value. This is useful feature, but there was not any progress on this patch. I think so this feature can be interesting, so I would to revitalize this patch. Original

int64-timestamp-dependent test vs. --disable-integer-timestamps

Commits a7145f6bc et al. added a test to verify integer overflow detection in interval_mul. The buildfarm has now reminded me that you're not going to get integer overflow if timestamps ain't integers, cf https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill=2019-11-08%2019%3A42%3A32

Re: CountDBSubscriptions check in dropdb

Amit Kapila writes: > On Sat, Nov 9, 2019 at 3:58 PM Peter Eisentraut > wrote: >> On 2019-11-08 14:38, Amit Kapila wrote: >>> I am planning to commit and backpatch this till PG10 where it was >>> introduced on Monday morning (IST). Pavel agreed that this is a good >>> change in the other thread

Re: Missing constant propagation in planner on hash quals causes join slowdown

On Fri, Oct 18, 2019 at 03:40:34PM +, Hans Buschmann wrote: ... Both queries are logically equivalent. The planner correctly identifies the Index Cond: (tfact.t2_season = 3) for selecting from the index uk_fact_season_id. Are those queries actually equivalent? I've been repeatedly

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, Nov 8, 2019 at 3:31 PM Julien Rouhaud wrote: > > On Fri, Nov 8, 2019 at 5:35 AM imai.yoshik...@fujitsu.com > wrote: > > > > On Tue, Sept 10, 2019 at 11:27 PM, Julien Rouhaud wrote: > > > > [0002 patch] > > > > In pgss_planner_hook: > > > > > > > > + /* calc differences of

Re: Monitoring disk space from within the server

## Michael Paquier (mich...@paquier.xyz): > Total bytes and free bytes looks like a good first cut. Have you > looked at the portability of statfs() on other BSD flavors and > Solaris? "The statfs() system call first appeared in 4.4BSD." (from the statfs(2) manpage on FreeBSD). struct statfs

Re: TestLib::command_fails_like enhancement

On 11/8/19 4:40 PM, Mark Dilger wrote: > > > On 11/8/19 9:22 AM, Andrew Dunstan wrote: > ... >> This will need to be rewritten in light of the above, but see >> >> > > Thanks for the reference.  Having

Re: Performance improvement for queries with IN clause

On Sat, Nov 9, 2019 at 5:22 PM Andreas Karlsson wrote: > > On 11/8/19 2:52 PM, Rafia Sabih wrote: > > Now, my question is shouldn't we always use this list in sorted order, > > in other words can there be scenarios where such a sorting will not > > help? I am talking about only the cases where

Re: Does 'instead of delete' trigger support modification of OLD

Hello Eugen, Saturday, November 9, 2019, 2:05:02 PM, you wrote: > Hello Bruce, > Friday, November 8, 2019, 12:28:18 AM, you wrote: >> On Thu, Nov 7, 2019 at 04:26:55PM -0500, Bruce Momjian wrote: >>> On Thu, Nov 7, 2019 at 11:24:29AM +0200, Eugen Konkov wrote: >>> > >> As far as allowing

Re: CountDBSubscriptions check in dropdb

On Sat, Nov 9, 2019 at 3:58 PM Peter Eisentraut wrote: > > On 2019-11-08 14:38, Amit Kapila wrote: > > I am planning to commit and backpatch this till PG10 where it was > > introduced on Monday morning (IST). Pavel agreed that this is a good > > change in the other thread where we need it [1].

Re: Does 'instead of delete' trigger support modification of OLD

Hello Bruce, Friday, November 8, 2019, 12:28:18 AM, you wrote: > On Thu, Nov 7, 2019 at 04:26:55PM -0500, Bruce Momjian wrote: >> On Thu, Nov 7, 2019 at 11:24:29AM +0200, Eugen Konkov wrote: >> > >> As far as allowing DELETE to modify the trigger row for RETURNING, I am >> > >> not sure how

Re: ssl passphrase callback

On Fri, Nov 08, 2019 at 11:12:08PM +0900, Simon Riggs wrote: On Thu, 7 Nov 2019 at 10:24, Bruce Momjian wrote: What is the value of a shared library over a shell command? We had this discussion in relation to archive_command years ago, and decided on a shell command as the best API. I

Re: Performance improvement for queries with IN clause

On 11/8/19 2:52 PM, Rafia Sabih wrote: Now, my question is shouldn't we always use this list in sorted order, in other words can there be scenarios where such a sorting will not help? I am talking about only the cases where the list consists of all constants and could fit in memory. Basically,

Re: Reorderbuffer crash during recovery

On Fri, Nov 8, 2019 at 10:05 AM vignesh C wrote: > > On Thu, Nov 7, 2019 at 10:01 PM Andres Freund wrote: > > > > Hi, > > > > On 2019-11-07 17:03:44 +0530, Amit Kapila wrote: > > > On Thu, Nov 7, 2019 at 4:48 PM Tomas Vondra > > > wrote: > > > > > > > > I'm a bit confused - does this happen

Re: The flinfo->fn_extra question, from me this time.

>> On 3 Nov 2019, at 13:33, Pavel Stehule wrote: >> >> can be nice, if patch has some regress tests - it is good for memory >> refreshing what is target of patch. I’ve updated the patch, and added some regression tests. denty. pipeline-functionscan-v3.patch Description: Binary data

Re: CountDBSubscriptions check in dropdb

On 2019-11-08 14:38, Amit Kapila wrote: I am planning to commit and backpatch this till PG10 where it was introduced on Monday morning (IST). Pavel agreed that this is a good change in the other thread where we need it [1]. It is not an urgent thing, so I can wait if we think this is not a

Re: Collation versions on Windows (help wanted, apply within)

On Fri, Nov 8, 2019 at 12:44 AM Thomas Munro wrote: > > recommend a better way to display the collation version as text. > > There is a major and a minor version. The attached patch applies on top the previous. Regards, Juan José Santamaría Flecha

[PATH] spell.c (avoid call strlen repeatedly in loop.

Hi Mark, Another example, can you take a look? --- \dll\postgresql-12.0\a\backend\tsearch\spell.c Mon Sep 30 17:06:55 2019 +++ spell.c Sat Nov 09 05:55:23 2019 @@ -186,7 +186,7 @@ #define MAX_NORM 1024 #define MAXNORMLEN 256 -#define STRNCMP(s,p) strncmp( (s), (p), strlen(p) )

RE: Patch avoid call strlen repeatedly in loop.

Hi Mark, "In general, writing a string with snprintf and then calling strlen on that same string is not guaranteed to give the same lengths. You can easily construct a case where they differ: char foo[3] = {0}; int foolen; foolen = snprintf(foo, sizeof(foo), "%s", "");

RE: Patch avoid call strlen repeatedly in loop.

De: Mark Dilger Enviado: sábado, 9 de novembro de 2019 00:12 Para: Ranier VF; pgsql-hackers@lists.postgresql.org Assunto: Re: Patch avoid call strlen repeatedly in loop. On 11/8/19 9:41 AM, Ranier VF wrote: > ---

Re: Add A Glossary

Hello Corey, My 0.02€: On principle, I'm fine with having a glossary, i.e. word definitions, which are expected to be rather stable in the long run. I'm wondering whether the effort would not be made redundant by other on-line effort such as wikipedia, wiktionary, stackoverflow, standards,