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

2019-08-15 Thread Bruce Momjian
On Wed, Aug 14, 2019 at 09:19:44PM -0400, Bruce Momjian wrote: > I think there are several directions we can go after all-cluster > encryption, and it does matter because we would want minimal API > breakage. The options are: > > 1) Allow per-table encyption control to limit encryption

Re: Zedstore - compressed in-core columnar storage

2019-08-15 Thread Heikki Linnakangas
On 14/08/2019 20:32, Ashwin Agrawal wrote: On Wed, Aug 14, 2019 at 2:51 AM Ashutosh Sharma wrote: 2) Is there a chance that IndexOnlyScan would ever be required for zedstore tables considering the design approach taken for it? We have not given much thought to IndexOnlyScans so far. But I

Re: Built-in connection pooler

2019-08-15 Thread Konstantin Knizhnik
On 30.07.2019 16:12, Tomas Vondra wrote: On Tue, Jul 30, 2019 at 01:01:48PM +0300, Konstantin Knizhnik wrote: On 30.07.2019 4:02, Tomas Vondra wrote: My idea (sorry if it wasn't too clear) was that we might handle some cases more gracefully. For example, if we only switch between

Re: Do not check unlogged indexes on standby

2019-08-15 Thread Andrey Borodin
> 13 авг. 2019 г., в 20:30, Peter Geoghegan написал(а): > > That's one possibility. When I first designed amcheck it was important > to be conservative, so I invented a general rule about never acquiring > multiple buffer locks at once. I still think that that was the correct > decision for

Re: Change ereport level for QueuePartitionConstraintValidation

2019-08-15 Thread Sergei Kornilov
Hi > Sergei, can we enlist you to submit a patch for this? Namely reduce the > log level to DEBUG1 and add a TAP test in src/test/modules/alter_table/ > that verifies that the message is or isn't emitted, as appropriate. Yes, will do. Probably in few days. regards, Sergei

Allow cluster owner to bypass authentication

2019-08-15 Thread Peter Eisentraut
This is an implementation of the idea I mentioned in [0]. The naming and description perhaps isn't ideal yet but it works in principle. The idea is that if you connect over a Unix-domain socket and the local (effective) user is the same as the server's (effective) user, then access should be

Re: Don't like getObjectDescription results for pg_amop/pg_amproc

2019-08-15 Thread Tom Lane
Alexander Korotkov writes: > On Thu, Aug 15, 2019 at 2:08 AM Tom Lane wrote: >> Or maybe we're just being too ambitious here and we should discard some of >> this information. I'm not really sure that the format_operator result >> can be included without complete loss of intelligibility. >

Useless bms_free() calls in build_child_join_rel()

2019-08-15 Thread Etsuro Fujita
Hi, While working on the PWJ patch [1], I noticed $SUBJECT. They seem to be leftovers from the original partitionwise-join patch, perhaps. Attached is a patch for removing them. Best regards, Etsuro Fujita [1]

Re: Why is infinite_recurse test suddenly failing?

2019-08-15 Thread Thomas Munro
On Thu, Aug 15, 2019 at 5:49 PM Tom Lane wrote: > So that leads to the thought that "the infinite_recurse test is fine > if it runs by itself, but it tends to fall over if there are > concurrently-running backends". I have absolutely no idea how that > would happen on anything that passes for a

Extension development

2019-08-15 Thread Yonatan Misgan
Hello, I am trying to develop calendar extension for PostgreSQL but there is a difficulties on how to get day, month and year from PostgreSQL source code because when am read the PostgreSQL source code it uses DateADT as a data type and this DateADT returns the total numbers of day. So how can

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

2019-08-15 Thread Antonin Houska
Bruce Momjian wrote: > On Wed, Aug 14, 2019 at 04:36:35PM +0200, Antonin Houska wrote: > > I can work on it right away but don't know where to start. > > I think the big open question is whether there will be acceptance of an > all-cluster encyption feature. I guess if no one objects, we can

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

2019-08-15 Thread Masahiko Sawada
On Thu, Aug 15, 2019 at 10:19 AM Bruce Momjian wrote: > > On Wed, Aug 14, 2019 at 04:36:35PM +0200, Antonin Houska wrote: > > I can work on it right away but don't know where to start. > > I think the big open question is whether there will be acceptance of an > all-cluster encyption feature. I

Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions

2019-08-15 Thread Tom Lane
Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> In hopes of moving this along, I've pushed Ian's last code change, >> as there seems to be no real argument about that anymore. >> >> As for the doc changes, how about the attached revision of what >> I wrote previously? It gives

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

2019-08-15 Thread Bruce Momjian
On Thu, Aug 15, 2019 at 11:24:46AM +0200, Antonin Houska wrote: > > I think there are several directions we can go after all-cluster > > encryption, > > I think I misunderstood. What you summarize in > >

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

2019-08-15 Thread Bruce Momjian
On Thu, Aug 15, 2019 at 06:10:24PM +0900, Masahiko Sawada wrote: > On Thu, Aug 15, 2019 at 10:19 AM Bruce Momjian wrote: > > > > On Wed, Aug 14, 2019 at 04:36:35PM +0200, Antonin Houska wrote: > > > I can work on it right away but don't know where to start. > > > > I think the big open question

Re: pgbench - add \aset to store results of a combined query

2019-08-15 Thread Ibrar Ahmed
On Wed, Jul 10, 2019 at 11:33 AM Fabien COELHO wrote: > > Hello Ibrar, > > >> SELECT 1 AS one \; > >> SELECT 2 AS two UNION SELECT 2 \; > >> SELECT 3 AS three \aset > >> > >> will set both "one" and "three", while "two" is not set because there > were > >> two rows. It is a kind of more

Re: pgbench - add \aset to store results of a combined query

2019-08-15 Thread Ibrar Ahmed
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:not tested The patch passed my review, I have not reviewed the

Re: UNION ALL

2019-08-15 Thread 066ce286
Generally speaking, when executing UNION ; a DISTINCT is run afterward on the resultset. So, if you're sure that each part of UNION cannot return a line returned by another one, you may use UNION ALL, you'll cut the cost of the final implicit DISTINCT. - Mail original - De: "Mark

Re: [PATCH] Implement INSERT SET syntax

2019-08-15 Thread Ibrar Ahmed
Patch conflict with this assertion Assert(pstate->p_expr_kind == EXPR_KIND_UPDATE_SOURCE); src/backend/parser/parse_expr.c line 1570 The new status of this patch is: Waiting on Author

Re: Extension development

2019-08-15 Thread Chapman Flack
On 08/15/19 02:58, Yonatan Misgan wrote: > From this source code how can I get only the year to convert my own > calendar year. I need this because Ethiopian calendar is totally differ > from GC in terms of day, month and year. I find myself wondering whether getting only the year is sufficient

Re: Speed up transaction completion faster after many relations are accessed in a transaction

2019-08-15 Thread Tomas Vondra
On Wed, Aug 14, 2019 at 07:25:10PM +1200, David Rowley wrote: On Thu, 25 Jul 2019 at 05:49, Tom Lane wrote: On the whole, I don't especially like this approach, because of the confusion between peak lock count and end-of-xact lock count. That seems way too likely to cause problems. Thanks

Re: BF failure: could not open relation with OID XXXX while querying pg_views

2019-08-15 Thread Tomas Vondra
On Wed, Aug 14, 2019 at 05:24:26PM +1200, Thomas Munro wrote: On Wed, Aug 14, 2019 at 5:06 PM Tom Lane wrote: Oh, hmm --- yeah, that should mean it's safe. Maybe somebody incautiously changed one of the other tests that run concurrently with "rules"? Looks like stats_ext.sql could be the

Re: Extension development

2019-08-15 Thread Thomas Munro
On Fri, Aug 16, 2019 at 10:55 AM Chapman Flack wrote: > On 08/15/19 02:58, Yonatan Misgan wrote: > > From this source code how can I get only the year to convert my own > > calendar year. I need this because Ethiopian calendar is totally differ > > from GC in terms of day, month and year. > > I

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

2019-08-15 Thread Stephen Frost
Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Aug 15, 2019 at 11:24:46AM +0200, Antonin Houska wrote: > > > I think there are several directions we can go after all-cluster > > > encryption, > > > > I think I misunderstood. What you summarize in > > > >

Re: UNION ALL

2019-08-15 Thread Tom Lane
Mark Pasterkamp writes: > I was wondering if someone could help me understands what a union all > actually does. Generally speaking, it runs the first query and then the second query. You'd really need to provide a lot more detail for anyone to say more than that.

Re: Extension development

2019-08-15 Thread Tomas Vondra
On Thu, Aug 15, 2019 at 06:58:07AM +, Yonatan Misgan wrote: Hello, I am trying to develop calendar extension for PostgreSQL but there is a difficulties on how to get day, month and year from PostgreSQL source code because when am read the PostgreSQL source code it uses DateADT as a data

UNION ALL

2019-08-15 Thread Mark Pasterkamp
Dear all, I was wondering if someone could help me understands what a union all actually does. For my thesis I am using Apache Calcite to rewrite queries into using materialized views which I then give to a Postgres database. For some queries, this means that they will be rewritten in a UNION

Re: UNION ALL

2019-08-15 Thread Ibrar Ahmed
On Fri, Aug 16, 2019 at 12:16 AM <066ce...@free.fr> wrote: > Generally speaking, when executing UNION ; a DISTINCT is run afterward on > the resultset. > > So, if you're sure that each part of UNION cannot return a line returned > by another one, you may use UNION ALL, you'll cut the cost of the

Re: Add "password_protocol" connection parameter to libpq

2019-08-15 Thread Stephen Frost
Greetings, * Jeff Davis (pg...@j-davis.com) wrote: > On Wed, 2019-08-14 at 11:38 +0900, Michael Paquier wrote: > > What I got in mind was a comma-separated list of authorized protocols > > which can be specified as a connection parameter, which extends to > > all > > the types of AUTH_REQ

Re: POC: Cleaning up orphaned files using undo logs

2019-08-15 Thread Dilip Kumar
On Wed, Aug 14, 2019 at 10:35 PM Andres Freund wrote: > > Hi, > > On 2019-08-14 14:48:07 +0530, Dilip Kumar wrote: > > On Wed, Aug 14, 2019 at 12:27 PM Andres Freund wrote: > > > - I think there's two fairly fundamental, and related, problems with > > > the sequence outlined above: > > > > > >

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

2019-08-15 Thread Stephen Frost
Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Aug 15, 2019 at 06:10:24PM +0900, Masahiko Sawada wrote: > > On Thu, Aug 15, 2019 at 10:19 AM Bruce Momjian wrote: > > > > > > On Wed, Aug 14, 2019 at 04:36:35PM +0200, Antonin Houska wrote: > > > > I can work on it right away but

Re: [PATCH] Implement INSERT SET syntax

2019-08-15 Thread Amit Kapila
On Wed, Jul 17, 2019 at 10:00 AM Gareth Palmer wrote: > > Hello, > > Attached is a patch that adds the option of using SET clause to specify > the columns and values in an INSERT statement in the same manner as that > of an UPDATE statement. > > A simple example that uses SET instead of a

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

2019-08-15 Thread Masahiko Sawada
On Fri, Aug 16, 2019 at 10:01 AM Stephen Frost wrote: > > Greetings, > > * Bruce Momjian (br...@momjian.us) wrote: > > On Thu, Aug 15, 2019 at 06:10:24PM +0900, Masahiko Sawada wrote: > > > On Thu, Aug 15, 2019 at 10:19 AM Bruce Momjian wrote: > > > > > > > > On Wed, Aug 14, 2019 at 04:36:35PM

Re: [PATCH] Implement INSERT SET syntax

2019-08-15 Thread Gareth Palmer
Hi Ibrar, > On 16/08/2019, at 7:14 AM, Ibrar Ahmed wrote: > > Patch conflict with this assertion > Assert(pstate->p_expr_kind == EXPR_KIND_UPDATE_SOURCE); > > src/backend/parser/parse_expr.c line 1570 > > The new status of this patch is: Waiting on Author Thank-you for reviewing the patch.

Re: POC: Cleaning up orphaned files using undo logs

2019-08-15 Thread Dilip Kumar
On Wed, Aug 14, 2019 at 2:48 PM Dilip Kumar wrote: > > On Wed, Aug 14, 2019 at 12:27 PM Andres Freund wrote: > > I think that batch reading should just copy the underlying data into a > > char* buffer. Only the records that currently are being used by > > higher layers should get exploded

Re: POC: Cleaning up orphaned files using undo logs

2019-08-15 Thread Thomas Munro
Hi Amit, I've combined three of your messages into one below, and responded inline. New patch set to follow shortly, with the fixes listed below (and others from other reviewers). On Wed, Jul 24, 2019 at 9:15 PM Amit Kapila wrote: > 0003-Add-undo-log-manager.patch > 1. >

Re: Useless bms_free() calls in build_child_join_rel()

2019-08-15 Thread Etsuro Fujita
On Thu, Aug 15, 2019 at 8:31 PM Etsuro Fujita wrote: > While working on the PWJ patch [1], I noticed $SUBJECT. They seem to > be leftovers from the original partitionwise-join patch, perhaps. > Attached is a patch for removing them. Pushed. Best regards, Etsuro Fujita

Re: POC: Cleaning up orphaned files using undo logs

2019-08-15 Thread Thomas Munro
Hi Kuntal, On Thu, Jul 25, 2019 at 5:40 PM Kuntal Ghosh wrote: > Here are some review comments on 0003-Add-undo-log-manager.patch. I've > tried to avoid duplicate comments as much as possible. Thanks! Replies inline. I'll be posting a new patch set shortly with these and other fixes. > 1. In

Re: POC: Cleaning up orphaned files using undo logs

2019-08-15 Thread Andres Freund
Hi, On 2019-08-16 09:44:25 +0530, Dilip Kumar wrote: > On Wed, Aug 14, 2019 at 2:48 PM Dilip Kumar wrote: > > > > On Wed, Aug 14, 2019 at 12:27 PM Andres Freund wrote: > > > > I think that batch reading should just copy the underlying data into a > > > char* buffer. Only the records that