Re: partition table and stddev() /variance() behaviour

Thanks for commit. I have verified reported case. it is fixed now. Thanks & Regards, Rajkumar Raghuwanshi QMG, EnterpriseDB Corporation On Fri, Jun 22, 2018 at 8:38 AM, David Rowley wrote: > On 22 June 2018 at 03:30, Tom Lane wrote: > >> I think some coverage of the numerical aggregates is a g

Re: ERROR: ORDER/GROUP BY expression not found in targetlist

Thanks for commit. I have verified reported case. it is fixed now. Thanks & Regards, Rajkumar Raghuwanshi QMG, EnterpriseDB Corporation On Thu, Jun 21, 2018 at 1:54 AM, Tom Lane wrote: > I wrote: > > Thanks for the report. I traced through this, and the problem seems to > > be that split_patht

Re: server crashed with TRAP: FailedAssertion("!(!parallel_aware || pathnode->path.parallel_safe)"

Thanks for commit. I have verified reported case. it is fixed now. Thanks & Regards, Rajkumar Raghuwanshi QMG, EnterpriseDB Corporation On Thu, Jun 21, 2018 at 7:21 PM, Tom Lane wrote: > Amit Kapila writes: > > On Thu, Jun 21, 2018 at 11:51 AM, Amit Khandekar > wrote: > >> After list_concat,

Speeding up INSERTs and UPDATEs to partitioned tables

Hi, As part of my efforts to make partitioning scale better for larger numbers of partitions, I've been looking at primarily INSERT VALUES performance. Here the overheads are almost completely in the executor. Planning of this type of statement is very simple since there is no FROM clause to proc

Re: Server crashed with TRAP: FailedAssertion("!(parallel_workers > 0)" when partitionwise_aggregate true.

On Fri, Jun 22, 2018 at 11:15 AM, Jeevan Chalke < jeevan.cha...@enterprisedb.com> wrote: > Hi, > > Off-list Ashutosh Bapat has suggested using a flag instead of counting > number of > dummy rels and then manipulating on it. That will be simple and smoother. > > I agree with his suggestion and upda

Re: Wrong cost estimation for foreign tables join with use_remote_estimate disabled

On 21.06.2018 20:08, Tom Lane wrote: Konstantin Knizhnik writes: The following very simple test reduce the problem with wrong cost estimation: create foreign table t1_fdw(x integer, y integer) server pg_fdw options (table_name 't1', use_remote_estimate 'false'); create foreign table t2_fdw(x

Re: PANIC during crash recovery of a recently promoted standby

On Fri, Jun 22, 2018 at 02:34:02PM +0900, Kyotaro HORIGUCHI wrote: > Hello, sorry for the absense and I looked the second patch. Thanks for the review! > At Fri, 22 Jun 2018 13:45:21 +0900, Michael Paquier > wrote in <20180622044521.gc5...@paquier.xyz> >> long as crash recovery runs. And XLogNe

Incorrect errno used with %m for backend code

Hi all, I have been reviewing the use of errno in the backend code when %m is used in the logs, and found more places than when I looked at improving the error messages for read() calls which bloat the errno value because of intermediate system calls. As the problem is separate and should be back

Re: Server crashed with TRAP: FailedAssertion("!(parallel_workers > 0)" when partitionwise_aggregate true.

Hi, Off-list Ashutosh Bapat has suggested using a flag instead of counting number of dummy rels and then manipulating on it. That will be simple and smoother. I agree with his suggestion and updated my patch accordingly. Thanks -- Jeevan Chalke Technical Architect, Product Development Enterpri

Re: PANIC during crash recovery of a recently promoted standby

Hello, sorry for the absense and I looked the second patch. At Fri, 22 Jun 2018 13:45:21 +0900, Michael Paquier wrote in <20180622044521.gc5...@paquier.xyz> > On Fri, Jun 22, 2018 at 10:08:24AM +0530, Pavan Deolasee wrote: > > On Fri, Jun 22, 2018 at 9:28 AM, Michael Paquier > > wrote: > >> So

RE: Threat models for DB cryptography (Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key) Management Service (KMS)

From: Nico Williams [mailto:n...@cryptonector.com] > Let's start with a set of threat models then. I'll go first: Thank you so much for summarizing the current situation. I'd appreciate it if you could write this on the PostgreSQL wiki, when the discussion has settled somehow. > - local adv

Re: PANIC during crash recovery of a recently promoted standby

On Fri, Jun 22, 2018 at 10:08:24AM +0530, Pavan Deolasee wrote: > On Fri, Jun 22, 2018 at 9:28 AM, Michael Paquier > wrote: >> So an extra pair of eyes from another committer would be >> welcome. I am letting that cool down for a couple of days now. > > I am not a committer, so don't know if my

Re: PANIC during crash recovery of a recently promoted standby

On Fri, Jun 22, 2018 at 9:28 AM, Michael Paquier wrote: > > > This is not really a complicated patch, and it took a lot of energy from > me the last couple of days per the nature of the many scenarios to think > about... Thanks for the efforts. It wasn't an easy bug to chase to begin with. So I

Re: Incorrect comments in commit_ts.c

On Fri, Jun 22, 2018 at 03:45:01AM +, shao bret wrote: > I think there is some mistake for this comment. It should be > ‘commitTS page’, not ‘CLOG page’. You are right, so pushed. -- Michael signature.asc Description: PGP signature

Re: [HACKERS] Pluggable storage

On Thu, Jun 14, 2018 at 12:25 PM Amit Kapila wrote: > On Thu, Jun 14, 2018 at 1:50 AM, Haribabu Kommi > wrote: > > > > On Fri, Apr 20, 2018 at 4:44 PM Haribabu Kommi > > > wrote: > > > > VACUUM: > > Not much changes are done in this apart moving the Vacuum visibility > > functions as part of th

Threat models for DB cryptography (Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key) Management Service (KMS)

On Thu, Jun 21, 2018 at 07:46:35PM -0400, Bruce Momjian wrote: > Agreed. I can see from this discussion that we have a long way to go > before we can produce something clearly useful, but it will be worth it. Let's start with a set of threat models then. I'll go first: 1) storage devices as the

Re: Server crashed with TRAP: FailedAssertion("!(parallel_workers > 0)" when partitionwise_aggregate true.

On Wed, Jun 20, 2018 at 7:11 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Tue, Jun 19, 2018 at 2:13 PM, Jeevan Chalke > wrote: > > > > > > In the reported testcase, parallel_workers is set to 0 for all partition > > (child) relations. Which means partial parallel paths are no

Re: PATCH: backtraces for error messages

On Fri, Jun 22, 2018 at 6:18 AM, Andres Freund wrote: > On 2018-06-22 08:24:45 +0800, Craig Ringer wrote: > > > > > > Huge +1 from me on being able to selectively manage logging on a > > module/subsystem, file, or line level. > > > > I don't think I saw the post. > > > > Such a thing would obviou

Re: PANIC during crash recovery of a recently promoted standby

On Thu, Jun 07, 2018 at 07:58:29PM +0900, Kyotaro HORIGUCHI wrote: > (I believe that) By definition recovery doesn't end until the > end-of-recovery check point ends so from the viewpoint I think it > is wrong to clear ControlFile->minRecoveryPoint before the end. > > Invalid-page checking during

Incorrect comments in commit_ts.c

Hi, Here is the comment for CommitTsPagePrecedes in commit_ts.c /* * Decide which of two CLOG page numbers is "older" for truncation purposes. … */ I think there is some mistake for this comment. It should be ‘commitTS page’, not ‘CLOG page’. Thanks, Br. Bret 发送自 Windows 10 版邮件

Re: partition table and stddev() /variance() behaviour

On 22 June 2018 at 03:30, Tom Lane wrote: >> I think some coverage of the numerical aggregates is a good idea, so >> I've added some in the attached. I managed to get a parallel plan >> going with a query to onek, which is pretty cheap to execute. I didn't >> touch the bool aggregates. Maybe I sho

Re: Considering signal handling in plpython again

Hi Heikki, Not working on it now, you can go ahead. On Fri, Jun 22, 2018 at 12:56 AM, Heikki Linnakangas wrote: > Hi Hubert, > > Are you working on this, or should I pick this up? Would be nice to get > this done as soon as v12 development begins. > > - Heikki > -- Thanks Hubert Zhang

Re: PATCH: backtraces for error messages

On 2018-06-22 08:24:45 +0800, Craig Ringer wrote: > On Thu., 21 Jun. 2018, 19:26 Pavan Deolasee, > wrote: > > > > > > > On Thu, Jun 21, 2018 at 11:02 AM, Michael Paquier > > wrote: > > > >> On Thu, Jun 21, 2018 at 12:35:10PM +0800, Craig Ringer wrote: > >> > I wrote it because I got sick of Asse

Re: Sample values for pg_stat_statements

On Thu, Jun 21, 2018 at 12:28:01PM +0200, Daniel Gustafsson wrote: > I happened to notice that this patch was moved from Returned with Feedback to > Needs Review after the CF closed, which means it’s now sitting open in a > closed > CF. The intended flow after RWF is that the patch is resubmitted

Re: PATCH: backtraces for error messages

On Thu., 21 Jun. 2018, 19:26 Pavan Deolasee, wrote: > > > On Thu, Jun 21, 2018 at 11:02 AM, Michael Paquier > wrote: > >> On Thu, Jun 21, 2018 at 12:35:10PM +0800, Craig Ringer wrote: >> > I wrote it because I got sick of Assert(false) debugging, and I was >> chasing >> > down some "ERROR: 08P0

Re: Spilling hashed SetOps and aggregates to disk

On Thu, 2018-06-21 at 13:44 -0700, David Gershuni wrote: > To handle hash collisions, we can do the following: > > 1) We track the current hash code we’re processing, in ascending > order. > > 2) Instead of combining one group at at time, we’ll maintain a list > of > all groups we’ve seen that ma

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Thu, Jun 21, 2018 at 12:12:40PM -0500, Nico Williams wrote: > On Thu, Jun 21, 2018 at 10:14:54AM -0400, Bruce Momjian wrote: > > On Wed, Jun 20, 2018 at 04:57:18PM -0500, Nico Williams wrote: > > > Client-side crypto is hard to do well and still get decent performance. > > > So on the whole I th

Re: libpq compression

On Thu, Jun 21, 2018 at 10:12:17AM +0300, Konstantin Knizhnik wrote: > On 20.06.2018 23:34, Robbie Harwood wrote: > >Konstantin Knizhnik writes: > >Well, that's a design decision you've made. You could put lengths on > >chunks that are sent out - then you'd know exactly how much is needed. > >(Fo

Re: Fast default stuff versus pg_upgrade

Alvaro Herrera writes: > In terms of pgindent, I'm surprised about these lines: > +missingval = OidFunctionCall3( > + F_ARRAY_IN, > Why did you put a newline there? In ancient times there was a reason > for that in some cases, because pgindent would move the

Re: Fast default stuff versus pg_upgrade

In terms of pgindent, I'm surprised about these lines: +missingval = OidFunctionCall3( + F_ARRAY_IN, Why did you put a newline there? In ancient times there was a reason for that in some cases, because pgindent would move the argument to the left of the open

Re: Spilling hashed SetOps and aggregates to disk

On Jun 21, 2018, at 1:04 PM, Jeff Davis wrote: > On Thu, 2018-06-21 at 11:04 -0700, David Gershuni wrote: >> This approach seems functionally correct, but I don't like the idea >> of >> transforming O(N) tuples of disk I/O into O(S*N) tuples of disk I/O >> (in the worst case). > > It's the same a

Re: Fast default stuff versus pg_upgrade

Andrew Dunstan writes: > I left that for a separate exercise. I think this does things the way > you want. I must admit to being a bit surprised, I was expecting you to > have more to say about the upgrade function than the pg_dump changes :-) Well, the upgrade function is certainly a bit ugly

Re: XML/XPath issues: text/CDATA in XMLTABLE, XPath evaluated with wrong context

I have pushed the patch now (in your original form rather than my later formulation) -- let's see how the buildfarm likes it. There are (at least) three issues remaining, as per below; Pavel, do you have any insight on these? First one is about array indexes not working sanely (I couldn't get thi

Re: Spilling hashed SetOps and aggregates to disk

On Thu, 2018-06-21 at 11:04 -0700, David Gershuni wrote: > This approach seems functionally correct, but I don't like the idea > of > transforming O(N) tuples of disk I/O into O(S*N) tuples of disk I/O > (in the worst case). It's the same amount of I/O as the idea you suggested as putting the hash

PSA: --enable-coverage interferes with parallel query scheduling

I've been poking at why coverage.postgresql.org shows that the second stanza in int8_avg_combine isn't exercised, when it clearly should be. I can reproduce the problem here, so it's fairly robust. Eventually it occurred to me to try a straight EXPLAIN ANALYZE VERBOSE, and what I find is that with

Re: Fast default stuff versus pg_upgrade

On 06/21/2018 01:53 PM, Tom Lane wrote: Andrew Dunstan writes: On 06/21/2018 01:44 PM, Tom Lane wrote: So I'm thinking that the attidentity code is just wrong, and you should change that too while you're at it. That should be backpatched if changed, no? I don't think we'd want this to get o

Continue work on changes to recovery.conf API

Hello all I would like to continue work on new recovery api proposed in thread [1]. We have some form of consensus but thread has been inactive for a long time and i hope i can help. I start from last published patch [2] and make some changes: - updated to current HEAD - made the patch pass make

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Fri, May 25, 2018 at 08:41:46PM +0900, Moon, Insung wrote: > Issues on data encryption of PostgreSQL > == > Currently, in PostgreSQL, data encryption can be using pgcrypto Tool. > However, it is inconvenient to use pgcrypto to encrypts data in some cases. > > There are two significant i

Re: Spilling hashed SetOps and aggregates to disk

> On Jun 19, 2018, at 10:36 PM, Jeff Davis wrote: > > But I am worried that I am missing something, because it appears that > for AGG_MIXED, we wait until the end of the last phase to emit the > contents of the hash tables. Wouldn't they be complete after the first > phase? You're right. They'

Re: Fast default stuff versus pg_upgrade

Andrew Dunstan writes: > On 06/21/2018 01:44 PM, Tom Lane wrote: >> So I'm thinking that the attidentity code is just wrong, and you should >> change that too while you're at it. > That should be backpatched if changed, no? I don't think we'd want this > to get out of sync between the branches.

Re: Fast default stuff versus pg_upgrade

Andres Freund writes: > On 2018-06-21 13:44:19 -0400, Tom Lane wrote: >> Actually, now that I think about it, there is a concrete reason for the >> historical pattern: it provides a cross-check that you did not fat-finger >> the query, ie misspell the column alias vs the PQfnumber parameter. This

Re: Fast default stuff versus pg_upgrade

On 06/21/2018 01:44 PM, Tom Lane wrote: Andrew Dunstan writes: On 06/21/2018 01:18 PM, Tom Lane wrote: I might be OK with a patch that converts *all* of pg_dump's cross-version difference handling code to depend on PQfnumber silently returning -1 rather than failing, but I don't want to see

Re: Fast default stuff versus pg_upgrade

On 2018-06-21 13:44:19 -0400, Tom Lane wrote: > Andrew Dunstan writes: > > On 06/21/2018 01:18 PM, Tom Lane wrote: > >> I might be OK with a patch that converts *all* of pg_dump's cross-version > >> difference handling code to depend on PQfnumber silently returning -1 > >> rather than failing, but

Re: Fast default stuff versus pg_upgrade

Andrew Dunstan writes: > On 06/21/2018 01:18 PM, Tom Lane wrote: >> I might be OK with a patch that converts *all* of pg_dump's cross-version >> difference handling code to depend on PQfnumber silently returning -1 >> rather than failing, but I don't want to see it done like that in just >> one or

Re: Speedup of relation deletes during recovery

On 2018-06-21 14:40:58 +0900, Michael Paquier wrote: > On Wed, Jun 20, 2018 at 08:43:11PM -0700, Andres Freund wrote: > > On 2018-06-18 11:13:47 -0700, Andres Freund wrote: > >> We could do that - but add_to_unowned_list() is actually a bottleneck in > >> other places during recovery too. We pretty

Re: Fast default stuff versus pg_upgrade

Hi, On 2018-06-21 13:28:46 -0400, Andrew Dunstan wrote: > I don't think it's at all a bad idea, TBH. It means you only have to add one > query per version rather than having to adjust all of them. I'd even say it's an excellent idea. Greetings, Andres Freund

Re: Fast default stuff versus pg_upgrade

On 06/21/2018 12:08 PM, Tom Lane wrote: I wrote: We could do without the unrelated whitespace changes in dumpDefaultACL, too (or did pgindent introduce those? Seems surprising ... oh, looks like "type" has somehow snuck into typedefs.list. Time for another blacklist entry.) Hmm .. actually

Re: location reporting in TAP test failures

On 05/06/18 18:28, Peter Eisentraut wrote: Right now, when a TAP test reports a failure, it looks something like this: # Failed test 'creating a replication slot' # at /../postgresql/src/bin/pg_basebackup/../../../src/test/perl/TestLib.pm line 371. That file location is where we cal

Re: Fast default stuff versus pg_upgrade

On 06/21/2018 01:18 PM, Tom Lane wrote: Andrew Dunstan writes: On 06/21/2018 12:39 PM, Tom Lane wrote: Andres Freund writes: On June 21, 2018 9:04:28 AM PDT, Tom Lane wrote: This isn't really ready to go. One clear problem is that you broke pg_dump'ing from any pre-v11 version, because

Re: Fast default stuff versus pg_upgrade

Andrew Dunstan writes: > On 06/21/2018 12:39 PM, Tom Lane wrote: >> Andres Freund writes: > On June 21, 2018 9:04:28 AM PDT, Tom Lane wrote: > This isn't really ready to go. One clear problem is that you broke > pg_dump'ing from any pre-v11 version, because you did not add suitable > null outpu

Re: libpq compression

Konstantin Knizhnik writes: > On 21.06.2018 17:56, Robbie Harwood wrote: >> Konstantin Knizhnik writes: >>> On 20.06.2018 23:34, Robbie Harwood wrote: Konstantin Knizhnik writes: Well, that's a design decision you've made. You could put lengths on chunks that are sent out -

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Thu, Jun 21, 2018 at 10:14:54AM -0400, Bruce Momjian wrote: > On Wed, Jun 20, 2018 at 04:57:18PM -0500, Nico Williams wrote: > > Client-side crypto is hard to do well and still get decent performance. > > So on the whole I think that crypto is a poor fit for the DBAs-are-the- > > threat threat m

Re: Wrong cost estimation for foreign tables join with use_remote_estimate disabled

Konstantin Knizhnik writes: > The following very simple test reduce the problem with wrong cost > estimation: > create foreign table t1_fdw(x integer, y integer) server pg_fdw options > (table_name 't1', use_remote_estimate 'false'); > create foreign table t2_fdw(x integer) server pg_fdw options

Re: Fast default stuff versus pg_upgrade

On 06/21/2018 12:39 PM, Tom Lane wrote: Andres Freund writes: On June 21, 2018 9:04:28 AM PDT, Tom Lane wrote: This isn't really ready to go. One clear problem is that you broke pg_dump'ing from any pre-v11 version, because you did not add suitable null outputs to the pre-v11 query varian

Re: WAL prefetch

On 06/21/2018 04:01 PM, Konstantin Knizhnik wrote: I continue my experiments with WAL prefetch. I have embedded prefetch in Postgres: now walprefetcher is started together with startup process and is able to help it to speedup recovery. The patch is attached. Unfortunately result is negativ

Re: Considering signal handling in plpython again

Hi Hubert, Are you working on this, or should I pick this up? Would be nice to get this done as soon as v12 development begins. - Heikki

Wrong cost estimation for foreign tables join with use_remote_estimate disabled

Hi hackers, I hope that somebody understand postgres_fdw cost calculation magic better than I;) The following very simple test reduce the problem with wrong cost estimation: create table t1(x integer primary key, y integer); create index on t1(y); insert into t1 values (generate_series(1,100

Re: phraseto_tsquery design

Hello, On Thu, Jun 21, 2018 at 11:02:32AM -0400, Sagiv Some wrote: > 2. However, it seems impossible to bypass the performance problem of phrase > searching. I conduct quite a bit of phrase searching, and although > postgres' "phraseto_tsquery" performs great on phrases with uncommon words, > it s

Re: Fast default stuff versus pg_upgrade

Andres Freund writes: > On June 21, 2018 9:04:28 AM PDT, Tom Lane wrote: >> This isn't really ready to go. One clear problem is that you broke >> pg_dump'ing from any pre-v11 version, because you did not add suitable >> null outputs to the pre-v11 query variants in getTableAttrs. > Thought the

Re: Fast default stuff versus pg_upgrade

On June 21, 2018 9:04:28 AM PDT, Tom Lane wrote: >Andrew Dunstan writes: >> Patch after pgindent attached. This will involve a catversion bump >since >> we're adding a new function. > >This isn't really ready to go. One clear problem is that you broke >pg_dump'ing from any pre-v11 version, b

Re: Fast default stuff versus pg_upgrade

I wrote: > We could do without the unrelated whitespace changes in dumpDefaultACL, > too (or did pgindent introduce those? Seems surprising ... oh, looks > like "type" has somehow snuck into typedefs.list. Time for another > blacklist entry.) Hmm .. actually, "type" already is in pgindent's blac

Re: libpq compression

On 21.06.2018 17:56, Robbie Harwood wrote: Konstantin Knizhnik writes: On 20.06.2018 23:34, Robbie Harwood wrote: Konstantin Knizhnik writes: My idea was the following: client want to use compression. But server may reject this attempt (for any reasons: it doesn't support it, has no pro

Re: Fast default stuff versus pg_upgrade

Andrew Dunstan writes: > Patch after pgindent attached. This will involve a catversion bump since > we're adding a new function. This isn't really ready to go. One clear problem is that you broke pg_dump'ing from any pre-v11 version, because you did not add suitable null outputs to the pre-v11

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Wed, Jun 20, 2018 at 05:28:43PM -0500, Nico Williams wrote: > On Wed, Jun 20, 2018 at 06:19:40PM -0400, Joe Conway wrote: > > On 06/20/2018 05:12 PM, Bruce Momjian wrote: > > > On Mon, Jun 18, 2018 at 11:06:20AM -0400, Joe Conway wrote: > > > Even if they are encrypted with the same key, they us

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Wed, Jun 20, 2018 at 06:19:40PM -0400, Joe Conway wrote: > On 06/20/2018 05:12 PM, Bruce Momjian wrote: > > On Mon, Jun 18, 2018 at 11:06:20AM -0400, Joe Conway wrote: > >>> At the same time, having to have a bunch of independently-decipherable > >>> short field values is not real secure either,

Re: partition table and stddev() /variance() behaviour

David Rowley writes: > On 22 June 2018 at 02:01, Tom Lane wrote: >> coverage.postgresql.org shows that numeric_poly_serialize/combine() >> aren't exercised at all by the regression tests. Which is embarrassing >> for this case, but I'm a bit leery of trying to insist on 100% coverage. >> It migh

Re: partition table and stddev() /variance() behaviour

On 22 June 2018 at 03:11, David Rowley wrote: > I think some coverage of the numerical aggregates is a good idea, so > I've added some in the attached. I managed to get a parallel plan > going with a query to onek, which is pretty cheap to execute. I didn't > touch the bool aggregates. Maybe I sho

Re: partition table and stddev() /variance() behaviour

On 22 June 2018 at 02:01, Tom Lane wrote: > David Rowley writes: >> Well, that's quite surprising. It appears to be a bug in >> numeric_poly_combine for machines without a working int128 type. The >> parameters in accum_sum_copy are in the incorrect order. > > Ouch. Yeah. Looks like this functio

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Thu, Jun 21, 2018 at 04:49:34PM +0900, Masahiko Sawada wrote: > >> On Thu, Jun 21, 2018 at 6:57 AM, Nico Williams > >> wrote: > >> So on the whole I think that crypto is a poor fit for the DBAs-are-the- > >> threat threat model. It's better to reduce the number of DBAs/sysadmins > >> and audi

phraseto_tsquery design

I recently migrated over from SQL Server to Postgres (through Amazon Aurora) for the cost. I have been working with the full-text search functions for quite some time, but have encountered a few major roadblocks in my quest to use postgres full-text search functionality to its fullest. I am using

Re: libpq compression

Konstantin Knizhnik writes: > On 20.06.2018 23:34, Robbie Harwood wrote: >> Konstantin Knizhnik writes: >> >> >> My idea was the following: client want to use compression. But server >> may reject this attempt (for any reasons: it doesn't support it, has >> no proper compression library, do not

Re: [PATCH] Include application_name in "connection authorized" log message

On Wed, Jun 20, 2018 at 2:45 PM, Stephen Frost wrote: > > diff --git a/src/include/libpq/libpq-be.h b/src/include/libpq/libpq-be.h > index 7698cd1f88..088ef346a8 100644 > --- a/src/include/libpq/libpq-be.h > +++ b/src/include/libpq/libpq-be.h > @@ -135,6 +135,7 @@ typedef struct Port > *

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Wed, Jun 20, 2018 at 04:57:18PM -0500, Nico Williams wrote: > On Wed, Jun 20, 2018 at 05:16:46PM -0400, Bruce Momjian wrote: > > On Mon, Jun 18, 2018 at 12:29:57PM -0500, Nico Williams wrote: > > > Note that unless the pg_catalog is protected against manipulation by > > > remote storage, then TD

Re: partition table and stddev() /variance() behaviour

David Rowley writes: > Well, that's quite surprising. It appears to be a bug in > numeric_poly_combine for machines without a working int128 type. The > parameters in accum_sum_copy are in the incorrect order. Ouch. > The very minimal fix is attached, but I'll need to go look at where > the test

Re: WAL prefetch

I continue my experiments with WAL prefetch. I have embedded prefetch in Postgres: now walprefetcher is started together with startup process and is able to help it to speedup recovery. The patch is attached. Unfortunately result is negative (at least at my desktop: SSD, 16Gb RAM). Recovery wi

Re: server crashed with TRAP: FailedAssertion("!(!parallel_aware || pathnode->path.parallel_safe)"

Amit Kapila writes: > On Thu, Jun 21, 2018 at 11:51 AM, Amit Khandekar > wrote: >> After list_concat, the subpaths no longer has only non-partial paths, >> which it is supposed to have. So it anyways should not be used in the >> subsequent code in that function. So I think the following change >

Re: partition table and stddev() /variance() behaviour

On 22 June 2018 at 00:18, Rajkumar Raghuwanshi wrote: > CREATE TABLE part (c1 INT,c2 INT) PARTITION BY RANGE (c1); > CREATE TABLE part_p1 PARTITION OF part FOR VALUES FROM (1) TO (3); > CREATE TABLE part_p2 PARTITION OF part FOR VALUES FROM (3) TO (5); > > INSERT INTO part VALUES (1,5),(2,15),(3,3

Re: server crashed with TRAP: FailedAssertion("!(!parallel_aware || pathnode->path.parallel_safe)"

On Thu, Jun 21, 2018 at 11:51 AM, Amit Khandekar wrote: > On 20 June 2018 at 14:28, Amit Khandekar wrote: >>> >>> Did you get a chance to look at it? >> >> Not yet, but I have planned to do this by tomorrow. > > > After list_concat, the subpaths no longer has only non-partial paths, > which

Re: Postgres 11 release notes

On Tue, Jun 19, 2018 at 1:40 PM Alexander Korotkov wrote: > On Tue, Jun 19, 2018 at 12:15 PM Alexander Korotkov > wrote: > > On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski > > wrote: > > >> > > >> > I'm not sure it is usefull in release notes since it is more about > > >> > API,

partition table and stddev() /variance() behaviour

Hi, I am getting different output for stddev/variance functions with partition tables. CREATE TABLE part (c1 INT,c2 INT) PARTITION BY RANGE (c1); CREATE TABLE part_p1 PARTITION OF part FOR VALUES FROM (1) TO (3); CREATE TABLE part_p2 PARTITION OF part FOR VALUES FROM (3) TO (5); INSERT INTO par

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

On Wed, Jun 20, 2018 at 1:00 PM, Haribabu Kommi wrote: > The pg_stat_statements contains the statistics of the queries that are > cumulative. > I find that any optimizations that are done to improve the performance of a > query > are not be visible clearly until the stats are reset. Currently ther

Re: Fast default stuff versus pg_upgrade

On 06/20/2018 09:04 PM, Andres Freund wrote: Probably couldn't hurt to run the changed files through pgindent and fix the damage... Looks reasonable to me, but I've not tested it. Thanks Patch after pgindent attached. This will involve a catversion bump since we're adding a new funct

Re: PATCH: backtraces for error messages

On Thu, Jun 21, 2018 at 11:02 AM, Michael Paquier wrote: > On Thu, Jun 21, 2018 at 12:35:10PM +0800, Craig Ringer wrote: > > I wrote it because I got sick of Assert(false) debugging, and I was > chasing > > down some "ERROR: 08P01: insufficient data left in message" errors. > Then I > > got kind

Re: PATCH: backtraces for error messages

Hello, I basically like this. At Thu, 21 Jun 2018 12:35:10 +0800, Craig Ringer wrote in > This is what the stacks look like btw > > > [2018-06-21 12:26:45.309 AWST] [7293] [] [] [:0] DEBUG: 0: > find_in_dynamic_libpath: trying > "/home/craig/pg/10/lib/postgresql/pglogical.so" > [2018-06-

Re: Possible bug in logical replication.

On Thu, Jun 21, 2018 at 12:18:44PM +0200, Petr Jelinek wrote: > On 20/06/18 09:59, Arseny Sher wrote: >> Michael Paquier writes: >>> It seems to me that we still want to have the slot forwarding finish in >>> this case even if this is interrupted. Petr, isn't that the intention >>> here? > > Wel

Re: Sample values for pg_stat_statements

> On 17 Apr 2018, at 17:58, Vik Fearing wrote: > Thanks! Attached is a patch addressing your concerns. I happened to notice that this patch was moved from Returned with Feedback to Needs Review after the CF closed, which means it’s now sitting open in a closed CF. The intended flow after RWF i

Re: Possible bug in logical replication.

On 20/06/18 09:59, Arseny Sher wrote: > > Michael Paquier writes: > >> On Mon, Jun 18, 2018 at 09:42:36PM +0900, Michael Paquier wrote: >>> On Fri, Jun 15, 2018 at 06:27:56PM +0300, Arseny Sher wrote: >>> It seems to me that we still want to have the slot forwarding finish in >>> this case even

Re: bug with expression index on partition

On 2018/06/21 16:19, Amit Langote wrote: > I updated the patch so that even DefineIndex will check if any whole-row > Vars were encountered during conversion and error out if so. I first thought of starting a new thread for this, but thought I'd just reply here because the affected code is nearby.

Making "COPY partitioned_table FROM" faster

I was looking at the COPY FROM performance gap between bulk loads with partitioned tables vs non-partitioned tables. There's quite a gap! Almost twice as slow in my test. It seems to be mostly down to lack of usage of heap_multi_insert() for the partitioned table case, which I guess is because we

Re: Fix slot's xmin advancement and subxact's lost snapshots in decoding.

Hello, Thank you for your time. Alvaro Herrera writes: > On 2018-Jun-11, Antonin Houska wrote: > >> >> One comment about the coding: since you introduce a new transaction list and >> it's sorted by LSN, I think you should make the function AssertTXNLsnOrder() >> more generic and use it to check

"wal receiver" process hang in syslog() while exiting after receiving SIGTERM while the postgres has been promoted.

Hi Hackers, We encounter one problem happened while we try to promote standby postgres(version 9.6.9) server to active. From the trace(we triggered the process abort). We can see the process was hang in syslog() while handling SIGTERM. According to below article. Looks it is risky to write s

Re: Push down Aggregates below joins

On 21/06/18 09:11, Antonin Houska wrote: Tomas Vondra wrote: On 06/20/2018 10:12 PM, Heikki Linnakangas wrote: Currently, the planner always first decides the scan/join order, and adds Group/Agg nodes on top of the joins. Sometimes it would be legal, and beneficial, to perform the aggregation

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Thu, Jun 21, 2018 at 2:53 PM, Nico Williams wrote: > On Thu, Jun 21, 2018 at 10:05:41AM +0900, Masahiko Sawada wrote: >> On Thu, Jun 21, 2018 at 6:57 AM, Nico Williams wrote: >> > On Wed, Jun 20, 2018 at 05:16:46PM -0400, Bruce Momjian wrote: >> >> On Mon, Jun 18, 2018 at 12:29:57PM -0500, Nic

Buildfarm failure in rolenames.sql

Hi all, Some of your may have noticed, but the buildfarm has thrown up the following failure today: https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=gull&br=HEAD The failure is the following one: -- ALTER TABLE OWNER TO \c - ! \connect: FATAL: could not read block 3 in file "base/1638

Re: bug with expression index on partition

On 2018/06/21 15:35, Amit Langote wrote: > So, CompareIndexInfo and generateClonedIndexStmt are both doing the right > thing, but DefineIndex is not. Attached is a patch to fix DefineIndex so > that it converts indexParams before recursing to create the index on a > partition. I noticed that whil

Re: libpq compression

On 20.06.2018 23:34, Robbie Harwood wrote: Konstantin Knizhnik writes: My idea was the following: client want to use compression. But server may reject this attempt (for any reasons: it doesn't support it, has no proper compression library, do not want to spend CPU for decompression,...) Ri