Re: [HACKERS] Row Level Security Bug ?

2017-11-12 Thread Joe Conway
On 11/12/2017 10:17 AM, Andrea Adami wrote: > if i do: > > SET ROLE 'manage...@scuola-1.it ' [SELECT from table] > i see only one row (as expected) > > but when i do: [SELECT from VIEWs] > I see all the rows always > > this way i lack all the row level security

Re: [HACKERS] libpq connection strings: control over the cipher suites?

2017-11-09 Thread Joe Conway
On 11/09/2017 03:17 PM, Michael Paquier wrote: > On Fri, Nov 10, 2017 at 2:53 AM, Joe Conway <m...@joeconway.com> wrote: >> On 11/09/2017 03:27 AM, Graham Leggett wrote: >>> Is there a parameter or mechanism for setting the required ssl cipher list >>> from the c

Re: [HACKERS] libpq connection strings: control over the cipher suites?

2017-11-09 Thread Joe Conway
On 11/09/2017 03:27 AM, Graham Leggett wrote: > Is there a parameter or mechanism for setting the required ssl cipher list > from the client side? I don't believe so. That is controlled by ssl_ciphers, which requires a restart in order to change.

Re: [HACKERS] pg_regress help output

2017-10-14 Thread Joe Conway
On 10/14/2017 02:04 PM, Peter Eisentraut wrote: > On 10/10/17 22:31, Joe Conway wrote: >>> Also, why is the patch apparently changing whitespace in all the help >>> lines? Seems like that will create a lot of make-work for translators. >> I debated with m

Re: [HACKERS] pg_control_recovery() return value when not in recovery

2017-10-13 Thread Joe Conway
On 09/17/2017 11:29 PM, Andres Freund wrote: > On 2017-09-18 07:24:43 +0100, Simon Riggs wrote: >> On 18 September 2017 at 05:50, Andres Freund wrote: >> > Hi, >> > >> > Just noticed that we're returning the underlying values for >> > pg_control_recovery() without any checks:

Re: [HACKERS] pg_regress help output

2017-10-10 Thread Joe Conway
On 10/10/2017 07:06 PM, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: >> I have been annoyed at least twice now by the lack of pg_regress command >> line help output for the "--bindir=" option. In passing I noted >> that there was no output for &

[HACKERS] pg_regress help output

2017-10-10 Thread Joe Conway
I have been annoyed at least twice now by the lack of pg_regress command line help output for the "--bindir=" option. In passing I noted that there was no output for "--help" or "--version" options either. Any objections to the attached? It could be argued that it ought to be back-patched too,

Re: [HACKERS] search path security issue?

2017-10-08 Thread Joe Conway
On 10/06/2017 12:52 AM, Magnus Hagander wrote: > It would be a nice feature to have in general, like a "basic guc > permissions" thing. At least allowing a superuser to prevent exactly > this. You could argue the same thing for example for memory parameters > and such. We have no permissions at

Re: [HACKERS] pg_control_recovery() return value when not in recovery

2017-09-18 Thread Joe Conway
Sorry for the top post. Sounds reasonable to me. Cannot look closely until Tuesday or so. Joe On September 17, 2017 11:29:32 PM PDT, Andres Freund wrote: >On 2017-09-18 07:24:43 +0100, Simon Riggs wrote: >> On 18 September 2017 at 05:50, Andres Freund

Re: odd behavior/possible bug (Was: Re: [HACKERS] PG10 partitioning - odd behavior/possible bug)

2017-09-03 Thread Joe Conway
On 09/03/2017 03:34 PM, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: >> Notice that tsr is not empty at all on the first loop, but on the second >> loop it is empty every second time the trigger fires. > > I think the issue is that now() isn't changing w

odd behavior/possible bug (Was: Re: [HACKERS] PG10 partitioning - odd behavior/possible bug)

2017-09-03 Thread Joe Conway
On 09/03/2017 02:28 PM, Joe Conway wrote: > I was playing around with partitioning and found an oddity that is best > described with the following reasonably minimal test case: > Notice that in the first loop iteration tsr is calculated from OLD.tr > correctly. But in the second lo

[HACKERS] PG10 partitioning - odd behavior/possible bug

2017-09-03 Thread Joe Conway
I was playing around with partitioning and found an oddity that is best described with the following reasonably minimal test case: 8<- CREATE TABLE timetravel ( id int8, f1 text not null, tr tstzrange not null default tstzrange(now(), 'infinity', '[]') ) PARTITION BY RANGE

Re: [HACKERS] SCRAM salt length

2017-08-17 Thread Joe Conway
On 08/17/2017 01:50 PM, Peter Eisentraut wrote: > On 8/17/17 12:10, Heikki Linnakangas wrote: >> On 08/17/2017 05:23 PM, Peter Eisentraut wrote: >>> On 8/17/17 09:21, Heikki Linnakangas wrote: The RFC doesn't say anything about salt length, but the one example in it uses a 16 byte string

Re: [HACKERS] git.postgresql.org (and other services) down

2017-08-05 Thread Joe Conway
On 08/05/2017 08:36 AM, Joe Conway wrote: > One of the datacenters that provides two pg.org VM hosts has become > inaccessible. Services that may be affected are: > > git.postgresql.org > search.postgresql.org > Mailinglist archives backend > PostgreSQL Community Association

[HACKERS] git.postgresql.org (and other services) down

2017-08-05 Thread Joe Conway
One of the datacenters that provides two pg.org VM hosts has become inaccessible. Services that may be affected are: git.postgresql.org search.postgresql.org Mailinglist archives backend PostgreSQL Community Association of Canada Download stats analytics database server ftpmaster.postgresql.org

Re: [HACKERS] Macros bundling RELKIND_* conditions

2017-08-03 Thread Joe Conway
On 08/02/2017 10:52 PM, Ashutosh Bapat wrote: > On Wed, Aug 2, 2017 at 11:15 PM, Alvaro Herrera > wrote: >> Alvaro Herrera wrote: >>> I think pg_class is a reasonable place to put more generic relkind lists >>> alongside a matching error message for each, rather than

Re: [HACKERS] Macros bundling RELKIND_* conditions

2017-08-03 Thread Joe Conway
On 08/02/2017 10:30 PM, Ashutosh Bapat wrote: > On Wed, Aug 2, 2017 at 8:47 PM, Robert Haas wrote: >> 0001-RELKIND_HAS_VISIBILITY_MAP.patch - one place >> 0002-RELKIND_HAS_STORAGE.patch - one place >> 0003-RELKIND_HAS_XIDS-macro.patch - one place >>

Re: [HACKERS] autovacuum can't keep up, bloat just continues to rise

2017-07-19 Thread Joe Conway
On 07/19/2017 03:29 PM, Tom Lane wrote: > "Joshua D. Drake" writes: >> At PGConf US Philly last week I was talking with Jim and Jan about >> performance. One of the items that came up is that PostgreSQL can't run >> full throttle for long periods of time. The long and

Re: [HACKERS] PostgreSQL - Weak DH group

2017-07-13 Thread Joe Conway
On 07/13/2017 01:07 PM, Simon Riggs wrote: > On 13 July 2017 at 16:32, Heikki Linnakangas wrote: >> (We dropped the ball back in October, continuing the discussion now) >> >> On 10/10/2016 06:24 PM, Heikki Linnakangas wrote: >>> >>> On 10/06/2016 10:26 PM, Christoph Berg wrote:

Re: [HACKERS] Multi column range partition table

2017-07-06 Thread Joe Conway
On 07/06/2017 01:24 PM, Dean Rasheed wrote: > On 6 July 2017 at 21:04, Tom Lane wrote: >> Dean Rasheed writes: >>> However, this is also an incompatible syntax change, and any attempt >>> to support both the old and new syntaxes is likely to be

Re: [HACKERS] FIPS mode?

2017-06-24 Thread Joe Conway
On 06/23/2017 10:51 PM, Tom Lane wrote: > Michael Paquier writes: >> On Sat, Jun 24, 2017 at 12:56 PM, Curtis Ruck >> wrote: >>> If I clean this up some, maintain styleguide, what is the likely hood of >>> getting this included in

Re: [HACKERS] WIP: Data at rest encryption

2017-06-13 Thread Joe Conway
On 06/13/2017 10:20 AM, Stephen Frost wrote: > * Joe Conway (m...@joeconway.com) wrote: >> Except shell escaping issues, etc, etc > > That's not an issue- we're talking about reading the stdout of some > other process, there's no shell escaping that has to be done there. It

Re: [HACKERS] WIP: Data at rest encryption

2017-06-13 Thread Joe Conway
On 06/13/2017 10:05 AM, Stephen Frost wrote: > Bruce, Joe, > > * Bruce Momjian (br...@momjian.us) wrote: >> On Tue, Jun 13, 2017 at 09:55:10AM -0700, Joe Conway wrote: >> > > That way, if the user wants to store the key in an unencrypted text >> > > file,

Re: [HACKERS] WIP: Data at rest encryption

2017-06-13 Thread Joe Conway
On 06/13/2017 09:28 AM, Robert Haas wrote: > On Tue, Jun 13, 2017 at 12:23 PM, Stephen Frost wrote: >> Key management is an entirely independent discussion from this and the >> proposal from Ants, as I understand it, is that the key would *not* be >> in the database but could

Re: [HACKERS] PG10 Partitioned tables and relation_is_updatable()

2017-06-12 Thread Joe Conway
On 06/12/2017 11:33 AM, Dean Rasheed wrote: > On 12 June 2017 at 17:51, Joe Conway <m...@joeconway.com> wrote: >> After looking I remain convinced - +1 in general. > > Yes, I think this will probably help, but I worry that it will turn > into quite a

Re: [HACKERS] PG10 Partitioned tables and relation_is_updatable()

2017-06-12 Thread Joe Conway
On 06/12/2017 07:40 AM, Joe Conway wrote: > On 06/12/2017 01:49 AM, Amit Langote wrote: >>> On Sun, Jun 11, 2017 at 5:02 PM, Dean Rasheed <dean.a.rash...@gmail.com> >>> wrote: >>>> It looks like relation_is_updatable() didn't get the message about >

Re: [HACKERS] PG10 Partitioned tables and relation_is_updatable()

2017-06-12 Thread Joe Conway
On 06/12/2017 01:49 AM, Amit Langote wrote: >> On Sun, Jun 11, 2017 at 5:02 PM, Dean Rasheed >> wrote: >>> It looks like relation_is_updatable() didn't get the message about >>> partitioned tables. Thus, for example, information_schema.views and >>>

Re: [HACKERS] PG10 Partitioned tables and relation_is_updatable()

2017-06-11 Thread Joe Conway
On 06/11/2017 08:55 AM, Joe Conway wrote: > On 06/11/2017 04:32 AM, Dean Rasheed wrote: >> It looks like relation_is_updatable() didn't get the message about >> partitioned tables. Thus, for example, information_schema.views and >> information_schema.columns report that simp

Re: [HACKERS] PG10 Partitioned tables and relation_is_updatable()

2017-06-11 Thread Joe Conway
On 06/11/2017 04:32 AM, Dean Rasheed wrote: > It looks like relation_is_updatable() didn't get the message about > partitioned tables. Thus, for example, information_schema.views and > information_schema.columns report that simple views built on top of > partitioned tables are non-updatable, which

[HACKERS] Re: [BUGS] BUG #14682: row level security not work with partitioned table

2017-06-11 Thread Joe Conway
On 06/09/2017 02:52 PM, Joe Conway wrote: > On 06/09/2017 06:16 AM, Joe Conway wrote: >> On 06/08/2017 11:09 PM, Noah Misch wrote: >>> On Wed, Jun 07, 2017 at 08:45:20AM -0700, Joe Conway wrote: >>>> On 06/07/2017 06:49 AM, Mike Palmiotto wrote: >>>> >

[HACKERS] Re: [BUGS] BUG #14682: row level security not work with partitioned table

2017-06-09 Thread Joe Conway
On 06/09/2017 06:16 AM, Joe Conway wrote: > On 06/08/2017 11:09 PM, Noah Misch wrote: >> On Wed, Jun 07, 2017 at 08:45:20AM -0700, Joe Conway wrote: >>> On 06/07/2017 06:49 AM, Mike Palmiotto wrote: >>> > I ended up narrowing it down to 4 tables (one parent an

[HACKERS] Re: [BUGS] BUG #14682: row level security not work with partitioned table

2017-06-09 Thread Joe Conway
On 06/08/2017 11:09 PM, Noah Misch wrote: > On Wed, Jun 07, 2017 at 08:45:20AM -0700, Joe Conway wrote: >> On 06/07/2017 06:49 AM, Mike Palmiotto wrote: >> > I ended up narrowing it down to 4 tables (one parent and 3 partitions) >> > in order to demonstrate poli

[HACKERS] Re: [BUGS] BUG #14682: row level security not work with partitioned table

2017-06-07 Thread Joe Conway
On 06/07/2017 06:49 AM, Mike Palmiotto wrote: > I ended up narrowing it down to 4 tables (one parent and 3 partitions) > in order to demonstrate policy sorting and order of RLS/partition > constraint checking. It should be much more straight-forward now, but > let me know if there are any further

[HACKERS] Re: [BUGS] BUG #14682: row level security not work with partitioned table

2017-06-06 Thread Joe Conway
On 06/06/2017 02:44 PM, Mike Palmiotto wrote: > On Tue, Jun 6, 2017 at 4:07 PM, Joe Conway <m...@joeconway.com> wrote: >> On 06/06/2017 11:57 AM, Mike Palmiotto wrote: >>> On Mon, Jun 5, 2017 at 10:36 AM, Robert Haas <robertmh...@gmail.com> wrote: >>>> O

[HACKERS] Re: [BUGS] BUG #14682: row level security not work with partitioned table

2017-06-06 Thread Joe Conway
On 06/06/2017 11:57 AM, Mike Palmiotto wrote: > On Mon, Jun 5, 2017 at 10:36 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Mon, Jun 5, 2017 at 10:20 AM, Joe Conway <m...@joeconway.com> wrote: >>> Unless Robert objects, I'll work with Mike to get a fix posted

[HACKERS] Re: [BUGS] BUG #14682: row level security not work with partitioned table

2017-06-05 Thread Joe Conway
On 06/04/2017 03:33 PM, Noah Misch wrote: > On Fri, Jun 02, 2017 at 09:28:16AM +0900, Michael Paquier wrote: >> On Thu, Jun 1, 2017 at 11:13 AM, Mike Palmiotto >> wrote: >> > This is indeed a bug. fireRIRrules is currently skipping the RLS >> > policy check when

Re: [HACKERS] Hash Functions

2017-06-02 Thread Joe Conway
On 06/02/2017 05:47 AM, Robert Haas wrote: > On Fri, Jun 2, 2017 at 1:24 AM, Jeff Davis wrote: >> 2. I basically see two approaches to solve the problem: >> (a) Tom suggested at PGCon that we could have a GUC that >> automatically causes inserts to the partition to be

Re: [HACKERS] Hash Functions

2017-06-01 Thread Joe Conway
On 06/01/2017 11:25 AM, Andres Freund wrote: > On 2017-06-01 13:59:42 -0400, Robert Haas wrote: >> My personal guess is that most people will prefer the fast >> hash functions over the ones that solve their potential future >> migration problems, but, hey, options are good. > > I'm pretty sure

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

2017-05-30 Thread Joe Conway
r database via an ill-thought-out >>> combination of automatic-initdb-if-$PGDATA-isn't-there and slow mounting. > >> Here is the Joe Conway report from 2004: >> https://postgr.es/m/41bfab7c.5040...@joeconway.com > > Yeah, that's the thread I was remembering.

Re: [HACKERS] Hash Functions

2017-05-12 Thread Joe Conway
On 05/12/2017 10:17 AM, Robert Haas wrote: > On Fri, May 12, 2017 at 1:12 PM, Andres Freund wrote: >> Given that a lot of data types have a architecture dependent >> representation, it seems somewhat unrealistic and expensive to have >> a hard rule to keep them architecture agnostic. And if

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

2017-05-10 Thread Joe Conway
On 05/10/2017 12:22 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, May 10, 2017 at 1:13 PM, Tom Lane wrote: >>> In terms of the alternatives I listed previously, it seems like >>> nobody liked alternatives #3, #4, or #5, leaving us with #1 (do >>>

Re: [HACKERS] CTE inlining

2017-05-04 Thread Joe Conway
On 05/04/2017 07:04 PM, Tom Lane wrote: > Craig Ringer writes: >> We're carefully maintaining this bizarre cognitive dissonance where we >> justify the need for using this as a planner hint at the same time as >> denying that we have a hint. That makes it hard to

Re: [HACKERS] CTE inlining

2017-05-04 Thread Joe Conway
On 05/04/2017 05:03 PM, Craig Ringer wrote: > On 5 May 2017 02:52, "Tom Lane" wrote: > I haven't been keeping close tabs either, but surely we still have > to have > the optimization fence in (at least) all these cases: > > * CTE contains INSERT/UPDATE/DELETE > * CTE contains

Re: [HACKERS] CTE inlining

2017-05-04 Thread Joe Conway
On 05/04/2017 10:56 AM, Andrew Dunstan wrote: > > > On 05/04/2017 01:52 PM, Joe Conway wrote: >> On 05/04/2017 10:33 AM, Alvaro Herrera wrote: >>> I'm not sure what your point is. We know that for some cases the >>> optimization barrier semantics are

Re: [HACKERS] CTE inlining

2017-05-04 Thread Joe Conway
On 05/04/2017 10:33 AM, Alvaro Herrera wrote: > I'm not sure what your point is. We know that for some cases the > optimization barrier semantics are useful, which is why the proposal is > to add a keyword to install one explicitely: > > with materialized r as > ( >

Re: [HACKERS] Row Level Security UPDATE Confusion

2017-04-13 Thread Joe Conway
On 04/13/2017 01:31 PM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Thu, Apr 6, 2017 at 4:05 PM, Rod Taylor wrote: >> > I'm a little confused on why a SELECT policy fires against the NEW record >> > for an UPDATE when using multiple FOR

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-09 Thread Joe Conway
On 04/09/2017 04:14 PM, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: >>> I turned on the buildfarm "keep" setting and looked at the diffs. The >>> issue is that in there are a few places that do "SELECT ... FROM >>> pg_seclabel

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-09 Thread Joe Conway
On 04/09/2017 03:01 PM, Joe Conway wrote: > On 04/09/2017 02:49 PM, Andres Freund wrote: >> On 2017-04-09 14:28:48 -0700, Joe Conway wrote: >>> Interesting -- rhino is now failing. I tested a minute ago manually on >>> the same buildfarm animal and it passed. I

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-09 Thread Joe Conway
On 04/09/2017 02:49 PM, Andres Freund wrote: > On 2017-04-09 14:28:48 -0700, Joe Conway wrote: >> Interesting -- rhino is now failing. I tested a minute ago manually on >> the same buildfarm animal and it passed. I'm on it. > > The module for segpsql really needs to b

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-09 Thread Joe Conway
On 04/09/2017 02:04 PM, Joe Conway wrote: > On 04/08/2017 07:29 AM, Stephen Frost wrote: >> * Joe Conway (m...@joeconway.com) wrote: >>> On 04/07/2017 05:36 PM, Robert Haas wrote: >>> > On Fri, Apr 7, 2017 at 5:22 PM, Joe Conway <m...@joeconway.com> wrote:

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-09 Thread Joe Conway
On 04/08/2017 07:29 AM, Stephen Frost wrote: > * Joe Conway (m...@joeconway.com) wrote: >> On 04/07/2017 05:36 PM, Robert Haas wrote: >> > On Fri, Apr 7, 2017 at 5:22 PM, Joe Conway <m...@joeconway.com> wrote: >> >> 1) commit the 0002 patch now bef

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-07 Thread Joe Conway
On 04/07/2017 05:36 PM, Robert Haas wrote: > On Fri, Apr 7, 2017 at 5:22 PM, Joe Conway <m...@joeconway.com> wrote: >> 1) commit the 0002 patch now before the feature freeze and follow up >>with the regression test patch when ready in a couple of days >> 2) hold off

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-07 Thread Joe Conway
On 04/07/2017 11:37 AM, Mike Palmiotto wrote: >>> I found some missing bits in the 0002 patch -- new version attached. >>> Will wait on new regression tests before committing, but I expect we'll >>> have those by end of today and be able to commit the rest tomorrow. >> >> Attached are the

[HACKERS] Partitioned tables vs GRANT

2017-04-07 Thread Joe Conway
Apparently INSERT and SELECT on the parent partitioned table skip normal acl checks on the partitions. Is that intended behavior? 8<--- test=# create user part_test; CREATE ROLE test=# test=# create table t1 (id int) partition by range ((id % 4)); CREATE TABLE test=#

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-06 Thread Joe Conway
On 04/06/2017 12:35 PM, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: >> Any thoughts on whether 0001a and 0001b ought to be backpatched? I'm >> thinking not given the lack of past complaints but it might make sense >> to do. > > I think 0001

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-06 Thread Joe Conway
On 04/06/2017 08:29 AM, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: >> I'm going to push the attached in a few hours unless there is any >> additional discussion. As stated above we'll do the regression changes >> in a separate patch once that is so

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-06 Thread Joe Conway
On 04/05/2017 02:29 PM, Mike Palmiotto wrote: > I'm going to hold the partition table regression changes for a > separate patch and include some ORDER BY fixes. Will post tomorrow > > In the meantime, attached are the latest and greatest patches. I'm going to push the attached in a few hours

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-05 Thread Joe Conway
On 04/04/2017 09:58 PM, Tom Lane wrote: > I doubt that works at all, TBH. What I'd expect to happen with a > typical compiler is a complaint about redefinition of typedef bool, > because c.h already declared it and here this fragment is doing > so again. It'd make sense to me to do > > + #ifdef

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-04 Thread Joe Conway
On 04/04/2017 10:02 AM, Joe Conway wrote: > On 04/04/2017 09:55 AM, Mike Palmiotto wrote: >> After some discussion off-list, I've rebased and udpated the patches. >> Please see attached for further review. > > Thanks -- will have another look and test on a machine with se

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-04 Thread Joe Conway
On 04/04/2017 09:55 AM, Mike Palmiotto wrote: > On Tue, Apr 4, 2017 at 10:19 AM, Joe Conway <m...@joeconway.com> wrote: >> On 04/04/2017 06:45 AM, Robert Haas wrote: >>> On Mon, Apr 3, 2017 at 12:02 PM, Joe Conway <m...@joeconway.com> wrote: >>>>> 0002

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-04 Thread Joe Conway
On 04/04/2017 06:45 AM, Robert Haas wrote: > On Mon, Apr 3, 2017 at 12:02 PM, Joe Conway <m...@joeconway.com> wrote: >>> 0002 looks extremely straightforward, but I wonder if we could get one >>> of the people on this list who knows about sepgsql to have a look? >

Re: [HACKERS] bumping HASH_VERSION to 3

2017-04-03 Thread Joe Conway
On 03/31/2017 11:19 AM, Magnus Hagander wrote: > On Fri, Mar 31, 2017 at 8:17 PM, Robert Haas > wrote: > > Starting a new thread about this to get more visibility. > > Despite the extensive work that has been done on hash indexes

Re: [HACKERS] partitioned tables and contrib/sepgsql

2017-04-03 Thread Joe Conway
t; up before, though, and I fear we're going to need to do something > about it. > > 0002 looks extremely straightforward, but I wonder if we could get one > of the people on this list who knows about sepgsql to have a look? > (Stephen Frost, Joe Conway, KaiGai Kohei...) Will

Re: [HACKERS] Schedule and Release Management Team for PG10

2017-03-30 Thread Joe Conway
On 03/30/2017 10:59 AM, Magnus Hagander wrote: > On Thu, Mar 30, 2017 at 4:40 PM, Tom Lane > wrote: > > Robert Haas > > writes: > > On Thu, Mar 30, 2017 at 9:41 AM, Bruce Momjian

Re: [HACKERS] Re: [COMMITTERS] pgsql: Faster expression evaluation and targetlist projection.

2017-03-26 Thread Joe Conway
On 03/25/2017 09:52 PM, Andres Freund wrote: > On 2017-03-25 20:40:23 -0700, Andres Freund wrote: >> I blindly tried to fix these, let's hope that works. > > In a second attempt (yes, reading diffs correctly is helpful), this > resolved the selinux issue. Yeha. +1! Joe -- Crunchy Data -

Re: [HACKERS] Re: [COMMITTERS] pgsql: Faster expression evaluation and targetlist projection.

2017-03-25 Thread Joe Conway
On 03/25/2017 05:21 PM, Andres Freund wrote: > On March 25, 2017 4:54:08 PM PDT, Joe Conway <m...@joeconway.com> wrote: >>On 03/25/2017 04:45 PM, Andres Freund wrote: >>> I think, for starters, seeing regression.diffs from sepgsql would be >>> useful. Might

[HACKERS] Re: [COMMITTERS] pgsql: Faster expression evaluation and targetlist projection.

2017-03-25 Thread Joe Conway
On 03/25/2017 04:45 PM, Andres Freund wrote: > On 2017-03-25 16:36:03 -0700, Joe Conway wrote: >> On 03/25/2017 04:03 PM, Andres Freund wrote: >> > Hi Joe, >> > >> > >> > On 2017-03-25 22:11:37 +, Andres Freund wrote: >> >&g

[HACKERS] Re: [COMMITTERS] pgsql: Faster expression evaluation and targetlist projection.

2017-03-25 Thread Joe Conway
On 03/25/2017 04:03 PM, Andres Freund wrote: > Hi Joe, > > > On 2017-03-25 22:11:37 +, Andres Freund wrote: >> Faster expression evaluation and targetlist projection. > > Apparently this broke the selinux integration somehow: >

Re: [HACKERS] scram and \password

2017-03-16 Thread Joe Conway
On 03/16/2017 06:52 AM, Heikki Linnakangas wrote: > On 03/14/2017 11:14 PM, Tom Lane wrote: >> In short, I don't think that argument refutes my position that "md5" >> in pg_hba.conf should be understood as allowing SCRAM passwords too. > > Yeah, let's do that. Here's a patch. > > I had some

Re: [HACKERS] Changing references of password encryption to hashing

2017-03-16 Thread Joe Conway
On 03/16/2017 06:19 AM, Robert Haas wrote: > On Mon, Mar 13, 2017 at 4:48 AM, Craig Ringer wrote: >> So I'm in favour of fixing the docs but I'm not keen on changing the >> SQL syntax in a way that just kind of papers over part of the >> problems. > > I agree. I think

Re: [HACKERS] scram and \password

2017-03-15 Thread Joe Conway
On 03/15/2017 08:48 AM, Michael Paquier wrote: > I have been hacking my way through this thing, and making > scram_build_verifier is requiring a bit more refactoring than I > thought first: > - stored and server keys are hex-encoded using a backend-only routine. > I think that those should be

Re: [HACKERS] scram and \password

2017-03-14 Thread Joe Conway
On 03/14/2017 08:40 AM, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: >> On 03/14/2017 03:15 AM, Heikki Linnakangas wrote: >>> It would be a lot more sensible, if there was a way to specify in >>> pg_hba.conf, "scram-or-md5". We punted on

Re: [HACKERS] scram and \password

2017-03-14 Thread Joe Conway
On 03/14/2017 03:15 AM, Heikki Linnakangas wrote: > On 03/14/2017 04:47 AM, Tom Lane wrote: >> Robert Haas writes: >>> I'm not talking about changing the default, just having it be possible >>> to use \password with the new system as it was with the old, whatever >>>

Re: [HACKERS] scram and \password

2017-03-13 Thread Joe Conway
On 03/12/2017 08:10 PM, Michael Paquier wrote: > OK, so what about doing the following then: > 1) Create pg_role_password_type(oid), taking a role OID in input and > returning the type. That version would make sense for administrative use. I still think we might want a version of this that takes

Re: [HACKERS] scram and \password

2017-03-12 Thread Joe Conway
On 03/11/2017 11:07 PM, Michael Paquier wrote: > Having a RLS on pg_authid to allow a user to look at its own password > type is an idea. Given that that is not likely at this stage of the dev cycle, what about a special purpose SQL function that returns the password type for the current user? Or

Re: [HACKERS] scram and \password

2017-03-11 Thread Joe Conway
On 03/11/2017 03:15 PM, Michael Paquier wrote: > Yeah but it can be called as well while the application is calling > PQgetResult() and still looping until it gets a NULL result. Not sure > if this is a use-case to worry about, but sending a query to the > server in PQencryptPassword() could as

Re: [HACKERS] scram and \password

2017-03-11 Thread Joe Conway
On 03/11/2017 02:21 PM, Michael Paquier wrote: > On Sun, Mar 12, 2017 at 5:35 AM, Joe Conway <m...@joeconway.com> wrote: >> So if the password is not already set, \password uses >> password_encryption to determine which format to use, and if the >> password is already s

Re: [HACKERS] Changing references of password encryption to hashing

2017-03-11 Thread Joe Conway
On 03/09/2017 06:16 PM, Michael Paquier wrote: > As discussed here: > https://www.postgresql.org/message-id/98cafcd0-5557-0bdf-4837-0f2b7782d...@joeconway.com > We are using in documentation and code comments "encryption" to define > what actually is hashing, which is confusing. > > Attached is a

Re: [HACKERS] [bug fix] dblink leaks unnamed connections

2017-03-11 Thread Joe Conway
On 03/09/2017 08:31 AM, Joe Conway wrote: > On 03/09/2017 07:54 AM, Tom Lane wrote: >> Fujii Masao <masao.fu...@gmail.com> writes: >>> On Wed, Mar 8, 2017 at 3:52 PM, Tsunakawa, Takayuki >>> <tsunakawa.ta...@jp.fujitsu.com> wrote: >>>> dblink fa

Re: [HACKERS] scram and \password

2017-03-11 Thread Joe Conway
On 03/10/2017 02:43 PM, Michael Paquier wrote: > On Sat, Mar 11, 2017 at 2:53 AM, Jeff Janes wrote: >> Should the \password tool in psql inspect password_encryption and act on it >> being 'scram'? > > Not sure if it is wise to change the default fot this release. > >> I

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

2017-03-09 Thread Joe Conway
On 03/09/2017 12:27 PM, Tom Lane wrote: > Over in > https://www.postgresql.org/message-id/flat/201703072317.01345.john.iliffe%40iliffe.ca > we spent quite a lot of effort to diagnose what turned out to be a simple > networking misconfiguration. It would probably have taken a lot less > effort if

Re: [HACKERS] [bug fix] dblink leaks unnamed connections

2017-03-09 Thread Joe Conway
On 03/09/2017 07:54 AM, Tom Lane wrote: > Fujii Masao writes: >> On Wed, Mar 8, 2017 at 3:52 PM, Tsunakawa, Takayuki >> wrote: >>> dblink fails to close the unnamed connection as follows when a new unnamed >>> connection is requested. The

Re: [HACKERS] CREATE/ALTER ROLE PASSWORD ('value' USING 'method')

2017-03-09 Thread Joe Conway
On 03/09/2017 06:34 AM, Robert Haas wrote: > On Thu, Mar 9, 2017 at 7:59 AM, Michael Paquier > wrote: >> Yes, I agree with that for MD5, and after looking around I can see >> (like here http://prosody.im/doc/plain_or_hashed) as well that >> SCRAM-hashed is used. Now,

Re: [HACKERS] CREATE/ALTER ROLE PASSWORD ('value' USING 'method')

2017-03-08 Thread Joe Conway
On 03/07/2017 08:29 PM, Tom Lane wrote: > Michael Paquier writes: >> here is a separate thread dedicated to the following extension for >> CREATE/ALTER ROLE: PASSWORD ('value' USING 'method'). > > The parentheses seem weird ... do we really need those? +1 > +

Re: [HACKERS] New Committer - Andrew Gierth

2017-03-01 Thread Joe Conway
On 02/28/2017 10:22 AM, Stephen Frost wrote: > Greetings! > > The PostgreSQL committers would like to welcome Andrew Gierth as a new > committer for the PostgreSQL project. > > Andrew - welcome! Congratulations! Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure

Re: [HACKERS] Retiring from the Core Team

2017-01-11 Thread Joe Conway
On 01/11/2017 04:29 PM, Josh Berkus wrote: > For that reason, as of today, I am stepping down from the PostgreSQL > Core Team. > It's been a long, fun ride, and I'm proud of the PostgreSQL we have > today: both the database, and the community. Thank you for sharing it > with me. End of an

Re: [HACKERS] ALTER SYSTEM for pg_hba.conf

2017-01-05 Thread Joe Conway
On 01/05/2017 08:27 AM, Robert Haas wrote: > There's also the question of whether opening up the ability to do > this sort of thing from the SQL level is a security hazard, It unquestionably is. > but we've already gone fairly far down the path of assuming that > there's not a tremendous amount

Re: [HACKERS] proposal: session server side variables

2017-01-04 Thread Joe Conway
On 01/04/2017 04:36 PM, Craig Ringer wrote: > On 5 January 2017 at 08:35, Craig Ringer wrote: >> On 5 January 2017 at 01:49, Fabien COELHO wrote: >>> Good. So we seem to agree that GUCS are transactional? >> >> No. We don't agree. They aren't. > >

Re: [HACKERS] Compiler warnings

2017-01-02 Thread Joe Conway
On 01/02/2017 10:55 AM, Joe Conway wrote: > On the 9.2 and 9.3 branches I see two warnings: > This one once: > --- > plancache.c:1197:9: warning: ‘plan’ may be used uninitialized in this > function [-Wmaybe-uninitialized] > > And this on

Re: [HACKERS] Compiler warnings

2017-01-02 Thread Joe Conway
On 01/02/2017 11:09 AM, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: >> If there is agreement on fixing these warnings, other than the bison >> generated warning, I would be happy to do it. I'd also be happy to look >> for a fix the bison warning as well

Re: [HACKERS] Compiler warnings

2017-01-02 Thread Joe Conway
On 01/02/2017 10:18 AM, Robert Haas wrote: > On Thu, Dec 29, 2016 at 10:47 AM, Joe Conway <m...@joeconway.com> wrote: >> Shouldn't this be back-patched? The plancache warning goes back through >> 9.2 (at least) and the lwlocks warning through 9.5 (or maybe it was 9.4). &g

Re: [HACKERS] Compiler warnings

2016-12-29 Thread Joe Conway
On 12/06/2016 01:59 PM, Robert Haas wrote: > On Tue, Dec 6, 2016 at 3:46 PM, Stephen Frost wrote: >> Good thought, thanks! >> >> Updated patch attached with that change and I also added an Assert() to >> GetCachedPlan(), in case that code gets whacked around later and somehow

Re: [HACKERS] proposal: session server side variables

2016-12-28 Thread Joe Conway
On 12/28/2016 10:17 AM, Jim Nasby wrote: > Then IMHO what needs to happen is to have a discussion on actual syntax > instead of calling into question the value of the feature. Following > this thread has been very painful because the communications have not > been very clear. Focus on grammar

Re: [HACKERS] Incautious handling of overlength identifiers

2016-12-23 Thread Joe Conway
On 12/23/2016 12:44 PM, Tom Lane wrote: > I wrote: >> So what to do? We could run around and fix these individual cases >> and call it good, but if we do, I will bet a very fine dinner that >> more such errors will sneak in before long. Seems like we need a >> coding convention that discourages

Re: [HACKERS] proposal: session server side variables

2016-12-23 Thread Joe Conway
On 12/23/2016 08:20 AM, Pavel Stehule wrote: > 2016-12-23 16:27 GMT+01:00 Fabien COELHO: >> I have often wished I had such a feature, psql client side :-variables are >> just awful raw text things. Agreed. >> A few comments, mostly about the design: >> >> 1. persistent objects with temporal

Re: [HACKERS] RLS related docs

2016-12-22 Thread Joe Conway
On 09/15/2016 02:34 PM, Joe Conway wrote: > On 09/15/2016 01:33 PM, Robert Haas wrote: >> On Sun, Aug 28, 2016 at 4:23 PM, Joe Conway <m...@joeconway.com> wrote: >>>>> For COPY, I think perhaps it would be more logical to put the new note >>>>> imm

Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw

2016-12-22 Thread Joe Conway
On 12/22/2016 06:55 AM, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: >> On 12/21/2016 09:20 PM, Tom Lane wrote: >>> I see that you need to pass the PGconn into dblink_res_error() now, but >>> what's the point of the new "bool fail" param

Re: [HACKERS] dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.

2016-12-22 Thread Joe Conway
On 12/18/2016 02:47 PM, Corey Huinker wrote: > On Sun, Dec 18, 2016 at 4:57 PM, Michael Paquier wrote: >> On Mon, Dec 19, 2016 at 6:48 AM, Joe Conway wrote: >>> Maybe if "CREATE FOREIGN DATA WRAPPER" had a way to specify that the FDW >>> supports a libpq con

Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw

2016-12-21 Thread Joe Conway
On 12/21/2016 09:20 PM, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: >> On 12/21/2016 04:22 PM, Tom Lane wrote: >>> In short, yes, please copy that bit into dblink. > >> The attached should do the trick I think. > > I see that you need to pass

Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw

2016-12-21 Thread Joe Conway
On 12/21/2016 04:22 PM, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: >> I did notice that postgres_fdw has the following stanza that I don't see >> in dblink: > >> 8<-- >> /* >> * If we don't get a message from the PG

  1   2   3   4   5   6   7   8   9   10   >