Re: [HACKERS] trust authentication behavior

- Ursprüngliche Mail - Von: "Kohei KaiGai" An: "Robert Haas" CC: "David G. Johnston" , "Denis Kirjanov" , pgsql-hackers@postgresql.org, "Kohei KaiGai" Gesendet: Samstag, 16. Mai 2015 03:32:55 Betreff: Re: [HACKERS] trust authentication behavior 2015-05-16 5:13 GMT+09:00 Robert Haas

[HACKERS] Making the regression tests halt to attach a debugger

During the course of UPSERT's development, I found it tricky to debug regression tests failures on occasion. There are often non-obvious dependencies across and within regression tests. Creating a minimal test case having attached a debugger to a directly controlled backend is often tricky, or at l

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_audit, an auditing extension

On Sun, May 17, 2015 at 11:00 PM, Stephen Frost wrote: > Fujii, Michael, > > * Fujii Masao (masao.fu...@gmail.com) wrote: >> pg_audit uses 1.0.0 as its version number. But, is the third digit really >> required? Why? We usually uses the version number with two digits in >> contrib modules. > > [..

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Sat, May 16, 2015 at 6:34 PM, Shigeru Hanada wrote: > Attached is the v15 patch of foreign join support for postgres_fdw. > > This patch is based on current master, and having being removed some > hunks which are not essential. > > And I wrote description of changes done by the patch. It is l

Re: [HACKERS] 9.5 open items

GC=Garbage Collector On Mon, May 18, 2015 at 9:24 AM, Michael Paquier wrote: > On Mon, May 18, 2015 at 12:35 PM, Josh Berkus wrote: > > Did it ever occur to you, Bruce, that you've turned into the GC daemon > > for the project? > > GC = global coordinator? > -- > Michael > > > -- > Sent via pgs

Re: [HACKERS] 9.5 open items

On Mon, May 18, 2015 at 12:35 PM, Josh Berkus wrote: > Did it ever occur to you, Bruce, that you've turned into the GC daemon > for the project? GC = global coordinator? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Sun, May 17, 2015 at 8:41 PM, Josh Berkus wrote: > Is there a particular reason why "+" makes more sense as "shallow > concatination" and "||" makes more sense as "deep concatination"? Like, > something in JS or other client languages which would make that > preference make more sense to users

Re: [HACKERS] Disabling trust/ident authentication configure option

> On Wed, May 13, 2015 at 2:18 PM, Robert Haas > wrote: > All of this is fairly far afield from the original topic of this > thread, which was whether a configure option disabling trust + ident > authentication would be a good idea. I said no. Then we h

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/17/2015 05:46 PM, Robert Haas wrote: > On May 17, 2015, at 8:38 PM, Peter Geoghegan wrote: >> The current behavior does not seem acceptable for the concatenate >> operator ("operator || jsonb"). > > I don't agree. It seems pretty clear to me after reading the new posts that > the behavior

Re: [HACKERS] 9.5 open items

On 05/15/2015 05:58 AM, Bruce Momjian wrote: > I have processed all the open email items I can through mid-March, > though I do have two pg_upgrade fixes pending application today. I will > continue processing doc fixes and major bug fixes for 9.5, but > everything else I do will be for 9.6. > D

Re: [HACKERS] Parallel Seq Scan

On Mon, May 18, 2015 at 6:28 AM, Haribabu Kommi wrote: > > On Wed, Apr 22, 2015 at 10:48 PM, Amit Kapila wrote: > > parallel_seqscan_v14.patch (Attached with this mail) > > This patch is not applying/working with the latest head after parallel > mode patch got committed. > can you please rebase t

[HACKERS] dromedary is now using -DCOPY_PARSE_PLAN_TREES

Back in March we discussed the advisability of having a buildfarm critter or two running with -DCOPY_PARSE_PLAN_TREES: http://www.postgresql.org/message-id/14670.1427727...@sss.pgh.pa.us but evidently nobody acted on the idea. I've now turned on that option on dromedary. It will fail its next HEA

[HACKERS] DROP TRANSFORM parsetree representation is no good

Running the regression tests with -DCOPY_PARSE_PLAN_TREES reveals that DROP TRANSFORM parse trees fail to be copiable: regression=# DROP TRANSFORM IF EXISTS FOR fake_type LANGUAGE plperl; ERROR: unrecognized node type: 1701866608 I've not tracked down the exact reason, but it kinda looks like th

Re: [HACKERS] Bug in jsonb minus operator

On Sun, May 17, 2015 at 8:04 AM, Andrew Dunstan wrote: > Sure. I thought we'd covered this but it's possible that we didn't, or that > it got rebroken. There have been complaints about the limitation on values > containing jbvBinary, so let's just remove it if that can be done simply, as > it seem

Re: [HACKERS] Parallel Seq Scan

On Wed, Apr 22, 2015 at 10:48 PM, Amit Kapila wrote: > parallel_seqscan_v14.patch (Attached with this mail) This patch is not applying/working with the latest head after parallel mode patch got committed. can you please rebase the patch. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Sun, May 17, 2015 at 5:46 PM, Robert Haas wrote: > On May 17, 2015, at 8:38 PM, Peter Geoghegan wrote: >> The current behavior does not seem acceptable for the concatenate >> operator ("operator || jsonb"). > > I don't agree. It seems pretty clear to me after reading the new posts that > the

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On May 17, 2015, at 8:38 PM, Peter Geoghegan wrote: > The current behavior does not seem acceptable for the concatenate > operator ("operator || jsonb"). I don't agree. It seems pretty clear to me after reading the new posts that the behavior is not an oversight, and that's enough for me to say

Re: [HACKERS] WALWriteLock contention

On May 17, 2015, at 5:57 PM, Thomas Munro wrote: >> On Sun, May 17, 2015 at 2:15 PM, Robert Haas wrote: >> http://oldblog.antirez.com/post/fsync-different-thread-useless.html >> >> It suggests that an fsync in progress blocks out not only other >> fsyncs, but other writes to the same file, which

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Sun, May 17, 2015 at 3:22 PM, Andrew Dunstan wrote: > So what exactly do you want me or anybody else to do now, two days *after* > we declared (not without pain) feature freeze? As much as I'd like to just fix the concatenate operator, I really don't want to be the person that adds additional

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/17/2015 05:56 PM, Peter Geoghegan wrote: On Sun, May 17, 2015 at 8:37 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: And I agree with thoughts above, that both concatenation modes ("simple" and "deep") definitely can be useful. I can try to figure out how much work that would be to modi

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Sun, May 17, 2015 at 8:37 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: > And I agree with thoughts above, that both concatenation modes ("simple" and > "deep") definitely can be useful. I can try to figure out how much work that > would be to modify the IteratorConcat function (or adapt Ilya

Re: [HACKERS] WALWriteLock contention

On Sun, May 17, 2015 at 2:15 PM, Robert Haas wrote: > http://oldblog.antirez.com/post/fsync-different-thread-useless.html > > It suggests that an fsync in progress blocks out not only other > fsyncs, but other writes to the same file, which for our purposes is > just awful. More Googling around r

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On Sun, May 17, 2015 at 7:16 AM, Petr Jelinek wrote: > Agreed, if you look at jquery for example, the extend() method by default > behaves like our current || and you have to specify that you want deep merge > if you want the behavior described by Peter. So there is definitely point > for both, at

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

On Sun, May 17, 2015 at 9:15 AM, Greg Sabino Mullane wrote: > Dave Cramer wrote: > > Well our solution was to use ?? but that does mean we have to do some > > extra parsing which in a perfect world wouldn't be necessary. > > That's not a good solution as '??' is a perfectly valid operator. ISTR >

Re: [HACKERS] WALWriteLock contention

On May 17, 2015, at 11:04 AM, Amit Kapila wrote: > On Sun, May 17, 2015 at 7:45 AM, Robert Haas wrote: > > > > I wonder if we could write WAL to two different files in > > alternation, so that we could be writing to one file which fsync-ing > > the other. > > Won't the order of transactions repl

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On 05/17/2015 07:39 PM, Tom Lane wrote: =?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= writes: On the other hand, ISTM that what we all intend to achieve is some Postgres equivalent of the SUID bit... so why not just do something equivalent? --- LOGIN-- as user with the appropriate role

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

=?windows-1252?Q?Jos=E9_Luis_Tall=F3n?= writes: > On the other hand, ISTM that what we all intend to achieve is some > Postgres equivalent of the SUID bit... so why not just do something > equivalent? > --- > LOGIN-- as user with the appropriate role membership / privilege? > .

Re: [HACKERS] RFC: Non-user-resettable SET SESSION AUTHORISATION

On 05/13/2015 06:03 AM, Alvaro Herrera wrote: Craig Ringer wrote: For some time I've wanted a way to "SET SESSION AUTHORISATION" or "SET ROLE" in a way that cannot simply be RESET, so that a connection may be handed to a less-trusted service or application to do some work with. Some years back,

Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Andrew Dunstan wrote: > FTR, Perl's DBD::Pg lets you do this: > $dbh->{pg_placeholder_dollaronly} = 1; # disable ? placeholders You can also simply escape placeholders in DBD::Pg with a backslash: $dbh->prepare(q{SELECT * FROM mytable WHERE ls

Re: [HACKERS] upper planner path-ification

Robert Haas writes: > So, getting back to this part, what's the value of returning a list of > Paths rather than a list of Plans? (1) less work, since we don't have to fill in details not needed for costing purposes; (2) paths carry info that the planner wants but the executor doesn't, no

Re: [HACKERS] upper planner path-ification

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> So I'm all for refactoring, but I think it will happen as a natural > Tom> byproduct of path-ification, and otherwise would be rather forced. > Hrm, ok. So for the near future, we should leave it more or less as-is? > We don't have a tim

Re: [HACKERS] upper planner path-ification

> "Tom" == Tom Lane writes: >> If there's interest, we could do that specific task as part of >> adding hashagg support for grouping sets (which would otherwise make >> it even longer), or as preparatory work for that. Tom> I think that refactoring without changing anything about the way

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

> Historical note: I think it's based on the nested hstore work, not on current hstore, but Dmitry can answer on that. Yes, you're right. And I agree with thoughts above, that both concatenation modes ("simple" and "deep") definitely can be useful. I can try to figure out how much work that would

Re: [HACKERS] upper planner path-ification

Andrew Gierth writes: > "Robert" == Robert Haas writes: > Robert> I think grouping_planner() is badly in need of some refactoring > Robert> just to make it shorter. It's over 1000 lines of code, which > Robert> IMHO is a fairly ridiculous length for a single function. > If there's interest,

Re: [HACKERS] upper planner path-ification

> "Robert" == Robert Haas writes: Robert> I think grouping_planner() is badly in need of some refactoring Robert> just to make it shorter. It's over 1000 lines of code, which Robert> IMHO is a fairly ridiculous length for a single function. If there's interest, we could do that specific

Re: [HACKERS] Bug in jsonb minus operator

On 05/16/2015 08:04 PM, Peter Geoghegan wrote: I'm seeing the following problem on the master branch: postgres=# select '{"foo":5}'::jsonb - 'bar'; -- okay ?column? {"foo": 5} (1 row) postgres=# select '{"foo":{"bar":5}}'::jsonb - 'foo'; -- okay ?column? -- {} (1

Re: [HACKERS] WALWriteLock contention

On Sun, May 17, 2015 at 7:45 AM, Robert Haas wrote: > > I wonder if we could write WAL to two different files in > alternation, so that we could be writing to one file which fsync-ing > the other. > Won't the order of transactions replay during recovery can cause problems if we do alternation whi

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 17/05/15 16:04, Andrew Dunstan wrote: On 05/16/2015 10:56 PM, Peter Geoghegan wrote: Another thing that I noticed about the new jsonb stuff is that the concatenate operator is based on the hstore one. This works as expected: postgres=# select '{"a":1}'::jsonb || '{"a":2}'; ?column?

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

On 05/16/2015 10:56 PM, Peter Geoghegan wrote: Another thing that I noticed about the new jsonb stuff is that the concatenate operator is based on the hstore one. This works as expected: postgres=# select '{"a":1}'::jsonb || '{"a":2}'; ?column? -- {"a": 2} (1 row) However, the nestin

Re: [HACKERS] fix typos

On Sun, May 17, 2015 at 1:46 PM, Dmitriy Olshevskiy wrote: > Hello. Please, see this patch with typos. > Thank you. Thanks, applied! -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

[HACKERS] fix typos

Hello. Please, see this patch with typos. Thank you. -- Dmitriy Olshevskiy >From e9c463e50efdaa1fbdcabea92cd95cbffea3d3bd Mon Sep 17 00:00:00 2001 From: olshevskiy87 Date: Sun, 17 May 2015 15:40:40 +0400 Subject: [PATCH] fix typos --- contrib/tsm_system_time/tsm_system_time.c | 2 +- doc/s

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

On 7 April 2015 at 13:41, Tomas Vondra wrote: > > (1) The current patch only does the trick when the FK matches the > conditions perfectly - when there are no missing columns (present > in the FK, not covered by a condition). > > Hi Tomas, I did glance at this patch a while back, but jus

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

> On May 16, 2015, at 10:56 PM, Peter Geoghegan wrote: > > Another thing that I noticed about the new jsonb stuff is that the > concatenate operator is based on the hstore one. This works as > expected: > > postgres=# select '{"a":1}'::jsonb || '{"a":2}'; > ?column? > -- > {"a": 2} > (1

Re: [HACKERS] pg_audit documentation fixes

On Sun, May 17, 2015 at 6:30 AM, Peter Geoghegan wrote: > Attached patch makes minor tweaks to pg_audit docs. > Applied, thanks. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/