Re: [HACKERS] factor out encoding dependent json/jsonb regression tests

Andrew Dunstan writes: > I'm rather tired of having to update two sets of output files every time > we change the json and jsonb regression tests. Also, other committers > occasionally fall over this trap and fail to update json_1.out and > jsonb_1.out, as do almost all

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

On Mon, Oct 5, 2015 at 8:50 AM, Tom Lane wrote: > That's certainly something worth looking at, but I think it's probably > more complicated than that. If you just write "WHERE x IN (1,2,3,4)", > that gets folded to a ScalarArrayOp with a single array constant, which > the

Re: [HACKERS] factor out encoding dependent json/jsonb regression tests

On Mon, Oct 5, 2015 at 10:32 AM, Andrew Dunstan wrote: > I'm rather tired of having to update two sets of output files every time we > change the json and jsonb regression tests. Also, other committers > occasionally fall over this trap and fail to update json_1.out and >

Re: [HACKERS] factor out encoding dependent json/jsonb regression tests

On 10/05/2015 01:53 PM, Tom Lane wrote: Andrew Dunstan writes: I'm rather tired of having to update two sets of output files every time we change the json and jsonb regression tests. Also, other committers occasionally fall over this trap and fail to update json_1.out

Re: [HACKERS] factor out encoding dependent json/jsonb regression tests

Andrew Dunstan wrote: > I'm rather tired of having to update two sets of output files every time we > change the json and jsonb regression tests. Also, other committers > occasionally fall over this trap and fail to update json_1.out and > jsonb_1.out, as do almost all other patch authors. I

Re: [HACKERS] run pg_rewind on an uncleanly shut down cluster.

> On 05 Oct 2015, at 18:04, Bruce Momjian wrote: > > On Mon, Oct 5, 2015 at 05:41:07PM +0200, Oleksii Kliukin wrote: >> Hello, >> >> I'm trying to find out how to rewind a cluster that was not shut down >> cleanly, in order to implement pg_rewind support in patroni (an >>

[HACKERS] factor out encoding dependent json/jsonb regression tests

I'm rather tired of having to update two sets of output files every time we change the json and jsonb regression tests. Also, other committers occasionally fall over this trap and fail to update json_1.out and jsonb_1.out, as do almost all other patch authors. I propose that we remove those

[HACKERS] Tsvector editing functions

Hello. There is patch that adds some editing routines for tsvector type. tsvector delete(tsvector, text) removes entry from tsvector by lexeme name set unnest(tsvector) expands a tsvector to a set of rows. Each row has following columns: lexeme, postings, weights. text[]

[HACKERS] Obsolete comment in tidpath.c

I think "best_inner_indexscan()" in the following comment in tidpath.c is obsolete. * There is currently no special support for joins involving CTID; in * particular nothing corresponding to best_inner_indexscan(). Since it's * not very useful to store TIDs of one table in another table,

Re: [HACKERS] No Issue Tracker - Say it Ain't So!]

On Mon, Oct 5, 2015 at 3:08 AM, Nathan Wagner wrote: > On Sun, Oct 04, 2015 at 04:30:49PM -0700, Josh Berkus wrote: > > That would be the key part, wouldn't it? Nice that you have [code to > > store and parse email messages]. > > Yeah. It actually made most of the work

Re: [HACKERS] No Issue Tracker - Say it Ain't So!]

On Mon, Oct 5, 2015 at 2:08 AM, Nathan Wagner wrote: > On Sun, Oct 04, 2015 at 04:30:49PM -0700, Josh Berkus wrote: > > That would be the key part, wouldn't it? Nice that you have [code to > > store and parse email messages]. > > Yeah. It actually made most of the work

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/09/29 16:36, Etsuro Fujita wrote: For the foreign table case (scanrelid>0), I imagined an approach different than yours. In that case, I thought the issue would be probably addressed by just modifying the remote query performed in RefetchForeignRow, which would be of the form "SELECT

Re: [HACKERS] Shouldn't CREATE TABLE LIKE copy the relhasoids property?

On Wed, Apr 29, 2015 at 03:48:04PM -0400, Bruce Momjian wrote: > On Tue, Apr 28, 2015 at 09:15:49AM -0400, Bruce Momjian wrote: > > > It seems to me that waiting for 9.6 for what's arguably a bug fix is too > > > much. It's not like this is a new feature. Why don't we just make sure > > > it is

Re: [HACKERS] Multi-tenancy with RLS

On Fri, Sep 11, 2015 at 7:50 AM, Joe Conway wrote: > On 09/01/2015 11:25 PM, Haribabu Kommi wrote: >> If any user is granted any permissions on that object then that user >> can view it's meta data of that object from the catalog tables. >> To check the permissions of the user

Re: [HACKERS] CREATE POLICY and RETURNING

Stephen, I just tried a little bit your patch for applying SELECT policies to DELETE/UPDATE. It is consistent with the GRANT system so it looks really good. I'll test it more thoroughly later. Also, I guess we don't need to worry about the syntax of "restrictive policies" you mentioned in the

Re: [HACKERS] CREATE POLICY and RETURNING

Zhaomo, * Zhaomo Yang (zmp...@gmail.com) wrote: > I just tried a little bit your patch for applying SELECT policies to > DELETE/UPDATE. It is consistent with the GRANT system so it looks > really good. I'll test it more thoroughly later. Great! Glad to hear it. > Also, I guess we don't need to

Re: [HACKERS] [Proposal] Table partition + join pushdown

Hello, KaiGai-san. Thank you for your comment, and sorry for late response. > If inner-scan of the join under the append node has param_info, its qualifier > shall be implicitly attached to the scan node. So, if it is legal, I'd like > to have this approach because it is less invasive than

Re: [HACKERS] Rename withCheckOptions to insertedCheckClauses

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > >> Also, these were added in 9.4, so introducing this many differences > >> between 9.4 and 9.5+ will make back-patching harder. > > > That's certainly true,

[HACKERS] Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older

pgcrypto uses the old, deprecated, "low-level" functions for symmetric encryption, with algorithm-specific functions like AES_ecb_encrypt(), DES_ecb3_encrypt() and so forth. The recommended new API is the so-called EVP API, which has functions for initializing a "context" using a specific

Re: [HACKERS] Connection string parameter 'replication' in documentation

Hello, At Fri, 2 Oct 2015 23:13:24 +0900, Takashi Ohnishi wrote in

Re: [HACKERS] No Issue Tracker - Say it Ain't So!]

On Mon, Oct 5, 2015 at 12:42 AM, Nathan Wagner wrote: > I don't have the original message for this thread, so I arbitrarily picked > a > message to reply to. > > Since what has been asked for is a bug *tracker*, and we already have a > bugs > mailing list, I put together

Re: [HACKERS] Freeze avoidance of very large table.

On Sat, Oct 3, 2015 at 3:41 AM, Robert Haas wrote: > On Fri, Oct 2, 2015 at 11:23 AM, Alvaro Herrera > wrote: >>> + /* all-frozen information is also cleared at the same time */ >>> PageClearAllVisible(page); >>> +

Re: [HACKERS] Parallel Seq Scan

On Sun, Oct 4, 2015 at 10:21 AM, Amit Kapila wrote: > > On Sat, Oct 3, 2015 at 11:35 PM, Robert Haas wrote: > > > > On Fri, Oct 2, 2015 at 11:44 PM, Amit Kapila wrote: > > > On Thu, Oct 1, 2015 at 7:41 PM, Robert Haas

Re: [HACKERS] [COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

On 2015-09-24 12:39:54 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > On 2015-09-24 10:37:33 -0400, Tom Lane wrote: > > > Andres Freund writes: > > > > Should this patch not have also touched the per-table limits in > > > reloptions.c? > > > > Hm. I guess that'd

Re: [HACKERS] ON CONFLICT issues around whole row vars,

Peter, all, * Peter Geoghegan (p...@heroku.com) wrote: > I see now that commit 4f3b2a8883 changed things for UPDATE and DELETE > statements, but not INSERT statements. I guess my unease is because > that isn't entirely consistent with INSERT + RETURNING and the GRANT > system. Logically, the only

Re: [HACKERS] ON CONFLICT issues around whole row vars,

On 2015-10-05 08:01:00 -0400, Stephen Frost wrote: > Peter, all, > I had intended to address with policies what is addressed through > permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only > done when ON CONFLICT was in use. > > I've fixed that by applying the SELECT policies

Re: [HACKERS] ON CONFLICT issues around whole row vars,

Andres, On Monday, October 5, 2015, Andres Freund wrote: > On 2015-10-05 08:01:00 -0400, Stephen Frost wrote: > > Peter, all, > > I had intended to address with policies what is addressed through > > permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only >

Re: [HACKERS] Odd query execution behavior with extended protocol

Thanks for the help Tom and the others, I'll modify my sequence and report if I encounter any further issues. On Sun, Oct 4, 2015 at 7:36 PM, Tom Lane wrote: > Shay Rojansky writes: > >> To my mind there is not a lot of value in performing Bind until you > >>

Re: [HACKERS] Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older

Heikki Linnakangas wrote: > In short, pgcrypto actually used to use the EVP functions, but was changed > to *not* use them, because in older versions of OpenSSL, some key lengths > and/or padding options that pgcrypto supports were not supported by the EVP > API. That was fixed in OpenSSL 0.9.7,

[HACKERS] Odd query execution behavior with extended protocol

Hi hackers, some odd behavior has been reported with Npgsql and I wanted to get your help. Npgsql supports sending multiple SQL statements in a single packet via the extended protocol. This works fine, but when the second query SELECTs a value modified by the first's UPDATE, I'm getting a result

Re: [HACKERS] [COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

Andres Freund writes: > On 2015-09-24 12:39:54 -0300, Alvaro Herrera wrote: >> I'm surprised the error has survived this long. Without checking I >> can't say what's the best solution either, but I would opt for >> documenting the limits we have -- if we want to change them

Re: [HACKERS] [COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

Andres Freund writes: > On 2015-10-05 09:39:58 -0400, Tom Lane wrote: >> How about "Setting autovacuum_freeze_max_age to very small values >> is unwise since it will force frequent vacuuming." > Well, you still can't really set it to a very small value - the lower > limits

Re: [HACKERS] ON CONFLICT issues around whole row vars,

* Andres Freund (and...@anarazel.de) wrote: > On 2015-10-05 08:01:00 -0400, Stephen Frost wrote: > > Peter, all, > > I had intended to address with policies what is addressed through > > permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only > > done when ON CONFLICT was in use.

Re: [HACKERS] No Issue Tracker - Say it Ain't So!]

On Mon, Oct 5, 2015 at 5:32 AM, Magnus Hagander wrote: > > > On Mon, Oct 5, 2015 at 12:42 AM, Nathan Wagner > wrote: >> >> I don't have the original message for this thread, so I arbitrarily picked >> a >> message to reply to. >> >> Since what has been

Re: [HACKERS] Connection string parameter 'replication' in documentation

Thanks for your answer:) >This is introduced by the commit 5a991ef, which allows logical >decoding via walsender interface. The paramter replication has >been there far from the commit intentionary as an 'undocumented >paramter'. This is, I suppose, because it is treated as a part of >the

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

I don't have the original message for this thread, so I arbitrarily picked a message to reply to. Since what has been asked for is a bug *tracker*, and we already have a bugs mailing list, I put together something. I downloaded the archives for pgsql-bugs, and fed them into a database. This

Re: [HACKERS] Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older

On 10/05/2015 06:02 AM, Heikki Linnakangas wrote: > There was prior discussion on the EVP API in this old thread from 2007: > http://www.postgresql.org/message-id/flat/46a5e284.7030...@sun.com#46a5e284.7030...@sun.com > > > In short, pgcrypto actually used to use the EVP functions, but was >

Re: [HACKERS] ON CONFLICT issues around whole row vars,

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > I had intended to address with policies what is addressed through > > permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only > > done when ON CONFLICT was in use. > > > I've fixed that by

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

Peter Geoghegan writes: > I'm annoyed and disappointed that the patch committed does not even > begin to address the underlying problem -- it just adds an escape > hatch, and fixes another theoretical issue that no one was affected > by. Honestly, next time I won't bother. The

Re: [HACKERS] ON CONFLICT issues around whole row vars,

Stephen Frost writes: > I had intended to address with policies what is addressed through > permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only > done when ON CONFLICT was in use. > I've fixed that by applying the SELECT policies as WCOs for both the >

Re: [HACKERS] [COMMITTERS] pgsql: Lower *_freeze_max_age minimum values.

On 2015-10-05 09:39:58 -0400, Tom Lane wrote: > Andres Freund writes: > > How about simply removing that sentence? I.e. something like > > autovacuum_freeze_max_age larger than the system-wide > > setting > > - (it can only be set smaller). Note that while you can

Re: [HACKERS] Freeze avoidance of very large table.

On 10 September 2015 at 01:58, Andres Freund wrote: > On 2015-09-04 23:35:42 +0100, Simon Riggs wrote: > > This looks OK. You saw that I was proposing to solve this problem a > > different way ("Summary of plans to avoid the annoyance of Freezing"), > > suggesting that we

Re: [HACKERS] Freeze avoidance of very large table.

On Fri, Oct 2, 2015 at 8:14 PM, Masahiko Sawada wrote: >> +#define Anum_pg_class_relallfrozen12 >> Why is pg_class.relallfrozen necessary? ISTM that there is no user of it now. > > The relallfrozen would be useful for user to estimate time to vacuum > freeze or

Re: [HACKERS] Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older

Andres Freund wrote: > But more seriously: Given the upstream support policies from > https://www.openssl.org/policies/releasestrat.html : > " > Support for version 0.9.8 will cease on 2015-12-31. No further releases of > 0.9.8 will be made after that date. Security fixes only will be applied to

Re: [HACKERS] No Issue Tracker - Say it Ain't So!]

Nathan Wagner wrote: > 1: Can a bug be more than "open" or "closed"? > > I think yes. At least we probably want to know why a bug is closed. Is it > not > a bug at all, not our bug, a duplicate submission, a duplicate of another bug, > something we won't fix for some reason (e.g. a bug

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

Andrew Dunstan wrote: > > On 10/05/2015 11:15 AM, Tom Lane wrote: > >Peter Geoghegan writes: > >>I'm annoyed and disappointed that the patch committed does not even > >>begin to address the underlying problem -- it just adds an escape > >>hatch, and fixes another theoretical

Re: [HACKERS] [COMMITTERS] pgsql: Apply SELECT policies in INSERT/UPDATE+RETURNING

Peter, On Monday, October 5, 2015, Peter Geoghegan wrote: > On Mon, Oct 5, 2015 at 4:55 AM, Stephen Frost > wrote: > > Apply SELECT policies in INSERT/UPDATE+RETURNING > > If we've changed this now, where does that leave the excluded.* >

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

On 10/05/2015 11:15 AM, Tom Lane wrote: Peter Geoghegan writes: I'm annoyed and disappointed that the patch committed does not even begin to address the underlying problem -- it just adds an escape hatch, and fixes another theoretical issue that no one was affected by.

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

Alvaro Herrera writes: > Andrew Dunstan wrote: >> FWIW, (a) and (b) but not (c) is probably the right description for my >> client who has been seeing problems here. > I think the fact that long IN lists are fingerprinted differently > according to the number of

Re: [HACKERS] Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older

On 2015-10-05 12:16:05 -0300, Alvaro Herrera wrote: > Heikki Linnakangas wrote: > > > In short, pgcrypto actually used to use the EVP functions, but was changed > > to *not* use them, because in older versions of OpenSSL, some key lengths > > and/or padding options that pgcrypto supports were not

[HACKERS] run pg_rewind on an uncleanly shut down cluster.

Hello, I'm trying to find out how to rewind a cluster that was not shut down cleanly, in order to implement pg_rewind support in patroni (an automated failover system, https://github.com/zalando/patroni). At the moment, pg_rewind limits itself to only cleanly shut down clusters. This works

Re: [HACKERS] run pg_rewind on an uncleanly shut down cluster.

On Mon, Oct 5, 2015 at 05:41:07PM +0200, Oleksii Kliukin wrote: > Hello, > > I'm trying to find out how to rewind a cluster that was not shut down > cleanly, in order to implement pg_rewind support in patroni (an > automated failover system, https://github.com/zalando/patroni). > > At the

Re: [HACKERS] Freeze avoidance of very large table.

On Mon, Oct 5, 2015 at 11:03 PM, Fujii Masao wrote: > On Fri, Oct 2, 2015 at 8:14 PM, Masahiko Sawada wrote: >>> +#define Anum_pg_class_relallfrozen12 >>> Why is pg_class.relallfrozen necessary? ISTM that there is no user of it >>> now. >>

Re: [HACKERS] Odd query execution behavior with extended protocol

> > > So you would suggest changing my message chain to send Bind right after > > Execute, right? This would yield the following messages: > > > P1/P2/D1/B1/E1/D2/B2/E2/S (rather than the current > > P1/D1/B1/P2/D2/B2/E1/C1/E2/C2/S) > > > This would mean that I would switch to using named