Re: [HACKERS] Row security violation error is misleading

On 8 April 2015 at 16:27, Stephen Frost wrote: > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> I actually re-used the sql status code 42501 - >> ERRCODE_INSUFFICIENT_PRIVILEGE for a RLS check failure because of the >> parallel with permissions checks, but I quite like Craig's idea of >> inve

Re: [HACKERS] Row security violation error is misleading

On 9 April 2015 at 01:30, Dean Rasheed wrote: > > That doesn't match what the code currently does: > > * Also, allow extensions to add their own policies. > * > * Note that, as with the internal policies, if multiple policies are > * returned then they will be combined into a

Re: [HACKERS] Row security violation error is misleading

On 8 April 2015 at 19:52, Dean Rasheed wrote: > 2). In prepend_row_security_policies(), I think it is better to have > any table RLS policies applied before any hook policies, so that a > hook cannot be used to bypass built-in RLS. > A hook really has to be able to ensure that built-in RLS cann

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Wed, Apr 8, 2015 at 10:53 PM, Sawada Masahiko wrote: > On Wed, Apr 8, 2015 at 1:09 PM, Fujii Masao wrote: >> On Wed, Apr 8, 2015 at 1:57 AM, Sawada Masahiko >> wrote: >>> On Wed, Apr 8, 2015 at 1:11 AM, Fabrízio de Royes Mello >>> wrote: On Tue, Apr 7, 2015 at 1:04 PM, Sawada Masa

Re: [HACKERS] EvalPlanQual behaves oddly for FDW queries involving system columns

On 2015/04/08 7:44, Tom Lane wrote: > Etsuro Fujita writes: >> To support ROW_MARK_REFERENCE on (postgres_fdw) foreign tables, I'd like >> to propose the following FDW APIs: > >> RowMarkType >> GetForeignRowMarkType(Oid relid, >> LockClauseStrength strength); > >> Decide

Re: [HACKERS] Removal of FORCE option in REINDEX

On Thu, Apr 9, 2015 at 12:33 AM, Jim Nasby wrote: > On 4/8/15 7:04 AM, Fujii Masao wrote: >> >> I'm thinking to apply the attached patch. >> But does anyone want to keep supporting the option? Why? > > > Nuke it. There seem no objections, so just pushed. Regards, -- Fujii Masao -- Sent via

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

Hanada-san, > In addition to your comments, I removed useless code that retrieves > ForeignPath > from outer/inner RelOptInfo and store them into ForeignPath#fdw_private. Now > postgres_fdw’s join pushd-down is free from existence of ForeignPath under the > join relation. This means that we can

Re: [HACKERS] "rejected" vs "returned with feedback" in new CF app

On Thu, Apr 9, 2015 at 9:20 AM, Robert Haas wrote: > On Apr 9, 2015, at 1:08 AM, Andres Freund wrote: >> I'm not convinced we really need a version that closes and moves a entry. >> But if we indeed want it we can just name it "moved". > > +1. +1. Sounds like a good idea. It would be good to ge

Re: [HACKERS] "rejected" vs "returned with feedback" in new CF app

On Apr 9, 2015, at 1:08 AM, Andres Freund wrote: > I'm not convinced we really need a version that closes and moves a entry. But > if we indeed want it we can just name it "moved". +1. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subs

Re: [HACKERS] New error code to track unsupported contexts

2015-04-09 3:45 GMT+09:00 Alvaro Herrera : > Pushed this. Thanks! -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Gracefully Reload SSL Certificates

On Wed, Apr 8, 2015 at 11:48:11AM -0400, Donald Stufft wrote: > Currently replacing the SSL certificates for PostgreSQL requires a full server > restart. However in the infrastructure for www.python.org (and in the future, > pypi.python.org as well) we use short lived certificates (1 day) that > a

[HACKERS] Gracefully Reload SSL Certificates

Currently replacing the SSL certificates for PostgreSQL requires a full server restart. However in the infrastructure for www.python.org (and in the future, pypi.python.org as well) we use short lived certificates (1 day) that automatically get rotated when 75% of their lifetime is used up. This me

Re: [HACKERS] "rejected" vs "returned with feedback" in new CF app

On Tue, Apr 7, 2015 at 12:33 PM, Tom Lane wrote: > I tried to mark the "UPDATE SET (*)" patch as "returned with feedback", > but the CF app informed me that if I did that the patch would > automatically be moved to the next commitfest. That seems completely > stupid. There is no need to reconsi

Re: [HACKERS] "rejected" vs "returned with feedback" in new CF app

On 04/08/2015 03:28 PM, Magnus Hagander wrote: On Wed, Apr 8, 2015 at 4:57 AM, Robert Haas > wrote: On Tue, Apr 7, 2015 at 3:35 PM, Peter Eisentraut mailto:pete...@gmx.net>> wrote: > On 4/7/15 3:33 PM, Tom Lane wrote: >> I tried to mark the "UPDATE SET

Re: [HACKERS] "rejected" vs "returned with feedback" in new CF app

On April 8, 2015 9:28:50 PM GMT+02:00, Magnus Hagander wrote: >On Wed, Apr 8, 2015 at 4:57 AM, Robert Haas >wrote: > >> On Tue, Apr 7, 2015 at 3:35 PM, Peter Eisentraut >wrote: >> > On 4/7/15 3:33 PM, Tom Lane wrote: >> >> I tried to mark the "UPDATE SET (*)" patch as "returned with >feedback",

Re: [HACKERS] TABLESAMPLE patch

On Mon, Apr 6, 2015 at 11:02 AM, Petr Jelinek wrote: > On 06/04/15 14:30, Petr Jelinek wrote: > >> On 06/04/15 11:02, Simon Riggs wrote: >> >> Are we ready for a final detailed review and commit? >>> >>> >> I plan to send v12 in the evening with some additional changes that came >> up from Amit'

Re: [HACKERS] deparsing utility commands

On 4/7/15 4:32 PM, Alvaro Herrera wrote: > Executive summary: > > There is now a CommandDeparse_hook; > deparse_utility_command is provided as an extension, intended for 9.6; > rest of patch would be pushed to 9.5. > > > Long version: > > I've made command deparsing hookable. Attached there ar

Re: [HACKERS] "rejected" vs "returned with feedback" in new CF app

On Wed, Apr 8, 2015 at 4:57 AM, Robert Haas wrote: > On Tue, Apr 7, 2015 at 3:35 PM, Peter Eisentraut wrote: > > On 4/7/15 3:33 PM, Tom Lane wrote: > >> I tried to mark the "UPDATE SET (*)" patch as "returned with feedback", > >> but the CF app informed me that if I did that the patch would > >>

Re: [HACKERS] New error code to track unsupported contexts

Pushed this. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-h

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

I'm not sure what the best way to handle the hand-off from patch contribution to reviewer/committer. If I start tweaking things then you send in a new version it's actually more work to resolve the conflicts. I think at this point it's easiest if I just take it from here. I'm puzzled about the cha

Re: [HACKERS] Row security violation error is misleading

On 8 April 2015 at 16:27, Stephen Frost wrote: >> 2). In prepend_row_security_policies(), I think it is better to have >> any table RLS policies applied before any hook policies, so that a >> hook cannot be used to bypass built-in RLS. > > While I agree that we want to include the RLS policies def

Re: [HACKERS] INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0

On Tue, Apr 7, 2015 at 10:59 PM, Peter Geoghegan wrote: > The documentation has been updated to reflect all of this. By the way, for the convenience of reviewers I continue to maintain a mirror of pre-built documentation as outlined here: https://wiki.postgresql.org/wiki/UPSERT#Documentation --

Re: [HACKERS] Precedence of NOT LIKE, NOT BETWEEN, etc

Greg Stark writes: > On Tue, Feb 24, 2015 at 5:04 PM, Tom Lane wrote: >> Also, it strikes me that we could significantly reduce, maybe even fully >> eliminate, the funny behaviors around the existing base_yylex() >> substitutions if we made them use the same idea, ie replace the leading >> token

Re: [HACKERS] Precedence of NOT LIKE, NOT BETWEEN, etc

On Tue, Feb 24, 2015 at 5:04 PM, Tom Lane wrote: > Also, it strikes me that we could significantly reduce, maybe even fully > eliminate, the funny behaviors around the existing base_yylex() > substitutions if we made them use the same idea, ie replace the leading > token with something special but

Re: [HACKERS] Support UPDATE table SET(*)=...

Alvaro Herrera writes: > Andrew Gierth wrote: > "Tom" == Tom Lane writes: >>> Tom> Right, but we should be trying to move in that direction. I see >>> Tom> your point though that (*) is more notationally consistent with >>> Tom> that case. Maybe we should be looking at trying to implement T641

Re: [HACKERS] Support UPDATE table SET(*)=...

Andrew Gierth wrote: > > "Tom" == Tom Lane writes: > Tom> Right, but we should be trying to move in that direction. I see > Tom> your point though that (*) is more notationally consistent with > Tom> that case. Maybe we should be looking at trying to implement T641 > Tom> in full and th

Re: [HACKERS] Support UPDATE table SET(*)=...

> "Tom" == Tom Lane writes: >> Now this I think is wrong; I think it's just as robust against >> schema changes as using the composite value directly would >> be. Consider the case where foo and reference_foo match with the >> exception of dropped columns; the code as it is should just wo

Re: [HACKERS] Support UPDATE table SET(*)=...

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> and not at all robust against schema changes (the same problem as > Tom> with the patch's approach to UPDATE). > Now this I think is wrong; I think it's just as robust against schema > changes as using the composite value directly would

Re: [HACKERS] Support UPDATE table SET(*)=...

> "Tom" == Tom Lane writes: >> One example that comes up occasionally (and that I've had to do >> myself more than once) is this: given a table "foo" and another with >> identical schema "reference_foo", apply appropriate inserts, updates >> and deletes to table "foo" to make the content

Re: [HACKERS] Removal of FORCE option in REINDEX

On 4/8/15 7:04 AM, Fujii Masao wrote: I'm thinking to apply the attached patch. But does anyone want to keep supporting the option? Why? Nuke it. -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-hackers mailing lis

Re: [HACKERS] Row security violation error is misleading

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 7 April 2015 at 16:21, Stephen Frost wrote: > > Agreed and we actually have a patch from Dean already to address this, > > it's just been waiting on me (with a couple of other ones). It'd > > certainly be great if you have time to take

Re: [HACKERS] Row security violation error is misleading

* Kevin Grittner (kgri...@ymail.com) wrote: > Dean Rasheed wrote: > > >> Re-using the SQLSTATE 44000 is a bit iffy too. We should > >> probably define something to differentiate this, like: > >> > >>44P01 ROW SECURITY WRITE POLICY VIOLATION > > > > Yes, that sounds sensible. > > I would be m

Re: [HACKERS] Support UPDATE table SET(*)=...

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> I spent a fair amount of time cleaning this patch up to get it > Tom> into committable shape, but as I was working on the documentation > Tom> I started to lose enthusiasm for it, because I was having a hard > Tom> time coming up with c

Re: [HACKERS] Sloppy SSPI error reporting code

On Fri, Apr 3, 2015 at 08:32:08PM -0400, Noah Misch wrote: > On Thu, Apr 02, 2015 at 07:31:52AM -0400, Bruce Momjian wrote: > > On Thu, Apr 2, 2015 at 01:44:59AM -0400, Noah Misch wrote: > > > On Wed, Apr 01, 2015 at 10:49:01PM -0400, Bruce Momjian wrote: > > > > On Sat, Jan 10, 2015 at 02:53:13P

Re: [HACKERS] Row security violation error is misleading

Dean Rasheed wrote: >> Re-using the SQLSTATE 44000 is a bit iffy too. We should >> probably define something to differentiate this, like: >> >>44P01 ROW SECURITY WRITE POLICY VIOLATION > > Yes, that sounds sensible. I would be more inclined to use: 42501 ERRCODE_INSUFFICIENT_PRIVILEGE I k

Re: [HACKERS] Tuple visibility within a single XID

Qingqing Zhou writes: > Not sure if I understand correctly: in uniqueness check, we see all > possible tuples with a dirty snapshot. For a tuple version inserted > and updated by myself, it is surely dead no matter how the transaction > ends. So I interpret that we can safely pruning the version.

Re: [HACKERS] Proposal : REINDEX xxx VERBOSE

On Wed, Apr 8, 2015 at 1:09 PM, Fujii Masao wrote: > On Wed, Apr 8, 2015 at 1:57 AM, Sawada Masahiko wrote: >> On Wed, Apr 8, 2015 at 1:11 AM, Fabrízio de Royes Mello >> wrote: >>> >>> On Tue, Apr 7, 2015 at 1:04 PM, Sawada Masahiko >>> wrote: On Tue, Apr 7, 2015 at 10:12 PM, Fabrízio

[HACKERS] Making src/test/ssl more robust

Hi all, I noticed two things while looking at the SSL test suite: 1) When running the tests, some logs are generated in client-log, but this log file has no entry in .gitignore... A patch is attached. 2) cp is used with a wildcard and system_or_bail in ServerSetup.pm: system_or_bail "cp ssl/serv

Re: [HACKERS] Re: File count restriction of directory limits number of relations inside a database.

On 2015-04-07 20:49:21 -0700, sudalai wrote: > Hi, > > Ya you are right, ext4 allows more directory entries(more than 32000) > but we limited the number of files insides the directory to 32000 to get > better performance. Sorry i'm not mentioned that in my post. There's actually a restricti

Re: [HACKERS] Re: File count restriction of directory limits number of relations inside a database.

On 04/08/15 07:09, Jim Nasby wrote: On 4/7/15 10:49 PM, sudalai wrote: Ya you are right, ext4 allows more directory entries(more than 32000) but we limited the number of files insides the directory to 32000 to get better performance. Sorry i'm not mentioned that in my post. That the rea

Re: [HACKERS] Replication identifiers, take 4

On 08/04/15 14:22, Andres Freund wrote: On 2015-04-08 14:17:04 +0200, Petr Jelinek wrote: And you guys are not getting my point. What I proposed was to not reuse the RI id immediately because that can make debugging issues with replication/conflict handling harder when something happens after cl

Re: [HACKERS] Replication identifiers, take 4

On 2015-04-08 14:17:04 +0200, Petr Jelinek wrote: > And you guys are not getting my point. What I proposed was to not reuse the > RI id immediately because that can make debugging issues with > replication/conflict handling harder when something happens after cluster > configuration has changed. I

Re: [HACKERS] Replication identifiers, take 4

On 08/04/15 06:59, Michael Paquier wrote: On Tue, Apr 7, 2015 at 11:37 PM, Andres Freund wrote: On 2015-04-07 16:30:25 +0200, Andres Freund wrote: And with temp tables (or much more extremely WITH OID tables) and such it's not that hard to reach that point. Oh, and obviously toast data. A co

Re: [HACKERS] Parallel Seq Scan

On Wed, Apr 8, 2015 at 3:30 PM, David Rowley wrote: > > On 8 April 2015 at 15:46, Amit Kapila wrote: >> >> I think there is always a chance that resources (like parallel-workers) >> won't be available at run-time even if we decide about them at >> executor-start phase unless we block it for that

Re: [HACKERS] Removal of FORCE option in REINDEX

On Wed, Apr 8, 2015 at 1:17 PM, Fabrízio de Royes Mello wrote: > > > Em quarta-feira, 8 de abril de 2015, Fujii Masao > escreveu: >> >> Hi, >> >> While reviewing the REINDEX VERBOSE patch, I felt inclined to remove FORCE >> option support from REINDEX command. It has been marked "obsolete" since

Re: [HACKERS] TABLESAMPLE patch

On Mon, Apr 6, 2015 at 11:32 PM, Petr Jelinek wrote: > > On 06/04/15 14:30, Petr Jelinek wrote: >> >> On 06/04/15 11:02, Simon Riggs wrote: >> >>> Are we ready for a final detailed review and commit? >>> >> >> I plan to send v12 in the evening with some additional changes that came >> up from Amit

Re: [HACKERS] Row security violation error is misleading

On 7 April 2015 at 16:21, Stephen Frost wrote: > Agreed and we actually have a patch from Dean already to address this, > it's just been waiting on me (with a couple of other ones). It'd > certainly be great if you have time to take a look at those, though, > generally speaking, I feel prety happ

Re: [HACKERS] Row security violation error is misleading

On 7 April 2015 at 13:11, Craig Ringer wrote: > When attempting to insert a row that violates a row security policy that > applies to writes, the error message emitted references WITH CHECK OPTION, > even though (as far as the user knows) there's no such thing involved. > If you understand the int

Re: [HACKERS] Parallel Seq Scan

On 8 April 2015 at 15:46, Amit Kapila wrote: > On Wed, Apr 8, 2015 at 1:53 AM, Kevin Grittner wrote: > > > > David Rowley wrote: > > > > > If we attempt to do this parallel stuff at plan time, and we > > > happen to plan at some quiet period, or perhaps worse, some > > > application's start-up

Re: [HACKERS] Support UPDATE table SET(*)=...

> "Tom" == Tom Lane writes: Tom> I spent a fair amount of time cleaning this patch up to get it Tom> into committable shape, but as I was working on the documentation Tom> I started to lose enthusiasm for it, because I was having a hard Tom> time coming up with compelling examples. The o

Re: [HACKERS] libpq's multi-threaded SSL callback handling is busted

Peter Eisentraut writes: > On 4/3/15 7:44 AM, Jan Urbański wrote: >> To reiterate: I recognise that not handling the callbacks is not the right >> answer. But not stomping on callbacks others might have set sounds like a >> minimal and safe improvement. > > I think your patch is okay in that it i

Re: [HACKERS] [PATCH] Add transforms feature

2015-04-08 4:55 GMT+02:00 Peter Eisentraut : > On 3/22/15 5:46 AM, Pavel Stehule wrote: > > Isn't better doesn't support "TRANSFORM ALL" clause? If somebody would > > to use transformations - then he have to explicitly enable it by > > "TRANSFORM FOR TYPE" ? It is safe and without possible user >

Re: [HACKERS] ConfigData in postgresql.conf

On Wed, Apr 8, 2015 at 4:32 PM, Dmitry Voronin wrote: > We have the samples of config files (postgresql.conf.sample, hba.conf.sample > and etc.). Some config options are replaced by initdb utility. What utility > replaces 'configDir' token in postgresql.conf and where? ConfigDir is not directly

Re: [HACKERS] Parallel Seq Scan

On 08-04-2015 PM 12:46, Amit Kapila wrote: > Going forward, I think we can improve the same if we decide not to shutdown > parallel workers till postmaster shutdown once they are started and > then just allocate them during executor-start phase. > I wonder if it makes sense to invent the notion o

Re: [HACKERS] Parallel Seq Scan

On 8 April 2015 at 14:24, Robert Haas wrote: > I think one of the philosophical questions that has to be answered > here is "what does it mean to talk about the cost of a parallel > plan?". For a non-parallel plan, the cost of the plan means both "the > amount of effort we will spend executing t

[HACKERS] ConfigData in postgresql.conf

Hello, We have the samples of config files (postgresql.conf.sample, hba.conf.sample and etc.). Some config options are replaced by initdb utility. What utility replaces 'configDir' token in postgresql.conf and where? Thank you. --  Best regards, Dmitry Voronin -- Sent via pgsql-hackers mail