Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun13, 2011, at 05:12 , Robert Haas wrote: > On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug wrote: >> So I the end, I had to wrap the sub-query in a SQL-language >> function and use that in the check constraint. While this >> solved my immediate problem, the necessity of doing that >> highlight

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Sun, Jun 12, 2011 at 6:46 AM, Florian Pflug wrote: > (B) There should be a way to use ANY()/ALL() with the > array elements becoming the left arguments of the operator. FWIW, in case people were unaware, this is getting close to Perl 6 junctions/superpositions. See:

[HACKERS] PATCH: CreateComments: use explicit indexing for ``values''

Hello, I'm new to PostgreSQL and git, but having read through the wiki entries such as http://wiki.postgresql.org/wiki/Submitting_a_Patch, I think I have a patch worthy of submission. It's a readability improvement in src/backend/commands/comment.c (CreateComments function), which changes the e

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Jun13, 2011, at 05:44 , Tom Lane wrote: > Robert Haas writes: >> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug wrote: >>> (C) Why do we forbid sub-queries in CHECK constraints? > >> Dunno. Maybe it's just an implementation restriction? > > (1) We don't want to invoke the planner in the pla

Re: [HACKERS] DOMAINs and CASTs

On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut wrote: > On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote: >> On Tue, May 17, 2011 at 12:19 PM, Robert Haas wrote: >> > >> > The more controversial question is what to do if someone tries to >> > create such a cast anyway.  We could just ign

Re: [HACKERS] pgbench--new transaction type

On 13/06/11 06:38, Greg Smith wrote: > On 06/11/2011 03:21 PM, Jeff Janes wrote: >> I wouldn't expect IPC chatter to show up in profiling, because it >> costs wall time, but not CPU time. The time spent might be attributed >> to the kernel, or to pgbench, or to nothing at all. >> > > Profiler

Re: [HACKERS] lazy vxid locks, v1

On 06/12/2011 11:39 PM, Robert Haas wrote: > Here is a patch that applies over the "reducing the overhead of > frequent table locks" (fastlock-v3) patch and allows heavyweight VXID > locks to spring into existence only when someone wants to wait on > them. I believe there is a large benefit to be

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

On Mon, Jun 13, 2011 at 7:51 AM, Kohei KaiGai wrote: > For syscache, length of a typical security label in selinux is > less than 64 bytes. If we assume an entry consume 128bytes > including Oid pairs or pointers, its consumption is 128KBytes > per 1,000 of tables or others. > (Do we have a way to

Re: [HACKERS] PATCH: CreateComments: use explicit indexing for ``values''

On Sun, Jun 12, 2011 at 7:26 AM, wrote: > Hello, > I'm new to PostgreSQL and git, but having read through the wiki entries such > as http://wiki.postgresql.org/wiki/Submitting_a_Patch, I think I have a patch > worthy of submission. > > It's a readability improvement in src/backend/commands/comm

Re: [HACKERS] Make relation_openrv atomic wrt DDL

On Mon, Jun 13, 2011 at 1:12 AM, Noah Misch wrote: > That might be a start, but it's not a complete replacement for the global > counter.  AcceptInvalidationMessages() is actually called in > LockRelationOid(), > but the comparison needs to happen a level up in RangeVarLockRelid().  So, we > woul

Re: [HACKERS] wrong message on REASSIGN OWNED

On Mon, Jun 13, 2011 at 2:41 AM, Jaime Casanova wrote: > On Sat, Jun 11, 2011 at 8:01 PM, Robert Haas wrote: >> >> "can't reassign objects owned by %s because this user is internal to >> the database system" ? >> > > that message is not that clear... it seems to imply i can't reassign > any objec

Re: [HACKERS] lazy vxid locks, v1

Stefan Kaltenbrunner wrote: > on that particular 40cores/80 threads box: > unpatched: > c40:tps = 107689.945323 (including connections establishing) > c80:tps = 101885.549081 (including connections establishing) > fast locks: > c40:tps = 215807.263233 (including connections e

Re: [HACKERS] FOREIGN TABLE doc fix

2011/6/13 Shigeru Hanada : > Thanks for the review. > > (2011/06/12 13:21), Robert Haas wrote: >> 2011/6/9 Shigeru Hanada: >>> Attached patch includes fixes for FOREIGN TABLE documents: >> >> I committed the changes to ALTER FOREIGN TABLE, but I think the >> changes to CREATE FOREIGN TABLE need mor

Re: [HACKERS] lazy vxid locks, v1

On 06/13/2011 02:29 PM, Kevin Grittner wrote: > Stefan Kaltenbrunner wrote: > >> on that particular 40cores/80 threads box: > >> unpatched: > >> c40:tps = 107689.945323 (including connections establishing) >> c80:tps = 101885.549081 (including connections establishing) > >> fast lo

Re: [HACKERS] FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 12:30 PM, Robert Haas wrote: > Incidentally, are you planning to revive the PostgreSQL FDW for 9.2? > That would be a killer feature. Even more killer would be that it could be built/packaged as an extension, and use for 9.1 too ;-) a. -- Aidan Van Dyk              

Re: [HACKERS] FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 9:03 AM, Aidan Van Dyk wrote: > On Mon, Jun 13, 2011 at 12:30 PM, Robert Haas wrote: >> Incidentally, are you planning to revive the PostgreSQL FDW for 9.2? >> That would be a killer feature. > > Even more killer would be that it could be built/packaged as an > extension,

Re: [HACKERS] DOMAINs and CASTs

On Mon, Jun 13, 2011 at 4:39 AM, Jaime Casanova wrote: > On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut wrote: >> On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote: >>> On Tue, May 17, 2011 at 12:19 PM, Robert Haas wrote: >>> > >>> > The more controversial question is what to do if someo

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

Robert Haas writes: > On Sun, Jun 12, 2011 at 11:44 PM, Tom Lane wrote: >> There are syntactic reasons not to do that. It'd be a lot easier just >> to provide a commutator operator for ~. > Details? Well, for one, it becomes unobvious what A op ANY (B) op C means. This has come up b

Re: [HACKERS] lazy vxid locks, v1

On 06/12/2011 11:39 PM, Robert Haas wrote: > Here is a patch that applies over the "reducing the overhead of > frequent table locks" (fastlock-v3) patch and allows heavyweight VXID > locks to spring into existence only when someone wants to wait on > them. I believe there is a large benefit to be

Re: [HACKERS] wrong message on REASSIGN OWNED

Robert Haas writes: > On Mon, Jun 13, 2011 at 2:41 AM, Jaime Casanova wrote: >> btw, i'm allowed to use ALTER TABLE to assign a new owner (even an >> unprivileged one) to a system catalog, probably that's a bug. > +1 for tightening that up in 9.2. Nonsense. You won't like the results of "DELET

Re: [HACKERS] wrong message on REASSIGN OWNED

Jaime Casanova writes: > On Sat, Jun 11, 2011 at 8:01 PM, Robert Haas wrote: >> "can't reassign objects owned by %s because this user is internal to >> the database system" ? > that message is not that clear... it seems to imply i can't reassign > any object from that user... I think s/drop/rea

Re: [HACKERS] wrong message on REASSIGN OWNED

On Mon, Jun 13, 2011 at 9:55 AM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jun 13, 2011 at 2:41 AM, Jaime Casanova >> wrote: >>> btw, i'm allowed to use ALTER TABLE to assign a new owner (even an >>> unprivileged one) to a system catalog, probably that's a bug. > >> +1 for tightening tha

pgbench cpu overhead (was Re: [HACKERS] lazy vxid locks, v1)

On 06/13/2011 01:55 PM, Stefan Kaltenbrunner wrote: [...] > all those tests are done with pgbench running on the same box - which > has a noticable impact on the results because pgbench is using ~1 core > per 8 cores of the backend tested in cpu resoures - though I don't think > it causes any cha

Re: [HACKERS] PATCH: CreateComments: use explicit indexing for ``values''

Robert Haas writes: > On Sun, Jun 12, 2011 at 7:26 AM, wrote: >> It's a readability improvement in src/backend/commands/comment.c >> (CreateComments function), which changes the existing code from incrementing >> a variable for use as the array index, to use explicit ``values'' instead. > Wow

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Mon, Jun 13, 2011 at 3:01 AM, Florian Pflug wrote: > On Jun13, 2011, at 05:12 , Robert Haas wrote: >> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug wrote: >>> So I the end, I had to wrap the sub-query in a SQL-language >>> function and use that in the check constraint. While this >>> solved m

Re: [HACKERS] wrong message on REASSIGN OWNED

On 06/13/2011 09:55 AM, Tom Lane wrote: Robert Haas writes: On Mon, Jun 13, 2011 at 2:41 AM, Jaime Casanova wrote: btw, i'm allowed to use ALTER TABLE to assign a new owner (even an unprivileged one) to a system catalog, probably that's a bug. +1 for tightening that up in 9.2. Nonsense.

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On 06/13/2011 10:07 AM, Robert Haas wrote: Some languages use =~ and some use just ~... I was just wondering if anyone thought the commutator of =~ was ~=... My feeling is it's a bit dangerous. It's too easy to fat-finger the reverse op, and get something quite unintended. cheers andrew (

Re: [HACKERS] FOREIGN TABLE doc fix

Robert Haas writes: > On Mon, Jun 13, 2011 at 9:03 AM, Aidan Van Dyk wrote: >> On Mon, Jun 13, 2011 at 12:30 PM, Robert Haas wrote: >>> Incidentally, are you planning to revive the PostgreSQL FDW for 9.2? >>> That would be a killer feature. >> Even more killer would be that it could be built/pa

Re: [HACKERS] FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 3:20 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jun 13, 2011 at 9:03 AM, Aidan Van Dyk wrote: >>> On Mon, Jun 13, 2011 at 12:30 PM, Robert Haas wrote: Incidentally, are you planning to revive the PostgreSQL FDW for 9.2? That would be a killer feature.

Re: [HACKERS] lazy vxid locks, v1

Stefan Kaltenbrunner writes: > On 06/12/2011 11:39 PM, Robert Haas wrote: >> Profiling reveals that the system spends enormous amounts of CPU time >> in s_lock. > just to reiterate that with numbers - at 160 threads with both patches > applied the profile looks like: > samples %image

Re: [HACKERS] FOREIGN TABLE doc fix

Dave Page writes: > On Mon, Jun 13, 2011 at 3:20 PM, Tom Lane wrote: >> Don't hold your breath. We'll probably be making enough changes in the >> FDW infrastructure (particularly planner support) that making an FDW >> work on both 9.1 and 9.2 would be an exercise in frustration, if it's >> even

Re: [HACKERS] wrong message on REASSIGN OWNED

On Mon, Jun 13, 2011 at 8:55 AM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jun 13, 2011 at 2:41 AM, Jaime Casanova >> wrote: >>> btw, i'm allowed to use ALTER TABLE to assign a new owner (even an >>> unprivileged one) to a system catalog, probably that's a bug. > >> +1 for tightening tha

Re: [HACKERS] FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 3:36 PM, Tom Lane wrote: > Dave Page writes: >> On Mon, Jun 13, 2011 at 3:20 PM, Tom Lane wrote: >>> Don't hold your breath.  We'll probably be making enough changes in the >>> FDW infrastructure (particularly planner support) that making an FDW >>> work on both 9.1 and 9

Re: [HACKERS] lazy vxid locks, v1

On Mon, Jun 13, 2011 at 10:29 AM, Tom Lane wrote: > Stefan Kaltenbrunner writes: >> On 06/12/2011 11:39 PM, Robert Haas wrote: >>> Profiling reveals that the system spends enormous amounts of CPU time >>> in s_lock. > >> just to reiterate that with numbers - at 160 threads with both patches >> ap

Re: [HACKERS] PATCH: CreateComments: use explicit indexing for ``values''

I wrote: >> Historically this i++ approach has been used in a lot of places that >> fill in system catalog tuples. We've fixed some of them over >> time, but I doubt this is the only one remaining. If we're going >> to try to remove it here, maybe we ought to try to fix them all >> rather than ju

Re: [HACKERS] On-the-fly index tuple deletion vs. hot_standby

On Mon, Jun 13, 2011 at 3:11 AM, Robert Haas wrote: > On Sun, Jun 12, 2011 at 3:01 PM, Noah Misch wrote: >> I fully agree.  That said, if this works on the standby, we may as well also >> use >> it opportunistically on the master, to throttle bloat. > > As long as the performance cost is de mini

Re: [HACKERS] procpid?

On Jun 11, 2011, at 9:36 PM, Robert Haas wrote: >> This is at least a use-case for something^Wfeature like 'create >> synonym', allowing smooth end-user's application upgrade on schema >> update. I am not claiming that we need that, it just seems a good >> usecase for column alias/synonym. > > I h

Re: [HACKERS] FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 10:20 AM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jun 13, 2011 at 9:03 AM, Aidan Van Dyk wrote: >>> On Mon, Jun 13, 2011 at 12:30 PM, Robert Haas wrote: Incidentally, are you planning to revive the PostgreSQL FDW for 9.2? That would be a killer feature

Re: [HACKERS] procpid?

On Mon, Jun 13, 2011 at 11:20 AM, Jim Nasby wrote: > On Jun 11, 2011, at 9:36 PM, Robert Haas wrote: >>> This is at least a use-case for something^Wfeature like 'create >>> synonym', allowing smooth end-user's application upgrade on schema >>> update. I am not claiming that we need that, it just s

Re: [HACKERS] FOREIGN TABLE doc fix

Dave Page writes: > On Mon, Jun 13, 2011 at 3:36 PM, Tom Lane wrote: >> Oh, that's by no means a waste of time --- we need some examples to help >> us figure out where the pain points are. I'm just saying that the best >> ways to do things will probably change quite a bit as we introduce >> solu

Re: [HACKERS] DOMAINs and CASTs

On Mon, Jun 13, 2011 at 03:39:39AM -0500, Jaime Casanova wrote: > On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut wrote: > > On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote: > >> On Tue, May 17, 2011 at 12:19 PM, Robert Haas > >> wrote: > >> > > >> > The more controversial question is w

Re: [HACKERS] wrong message on REASSIGN OWNED

Excerpts from Robert Haas's message of sáb jun 11 21:01:55 -0400 2011: > On Thu, Jun 9, 2011 at 1:26 PM, Jaime Casanova wrote: > > on shdepReassignOwned() we have this message, which is obviously wrong > > we are not dropping objects just reassigning them... > > """ > >                       erepo

Re: [HACKERS] FOREIGN TABLE doc fix

On 06/13/2011 10:25 AM, Dave Page wrote: Don't hold your breath. We'll probably be making enough changes in the FDW infrastructure (particularly planner support) that making an FDW work on both 9.1 and 9.2 would be an exercise in frustration, if it's even possible. Oh joy. There's a GSoC st

Re: [HACKERS] procpid?

On Jun 13, 2011, at 10:22 AM, Robert Haas wrote: >> A synonym feature would definitely be useful for cases like this. We have a >> poorly named database at work; it's been that way for years and the only >> reason it's never been cleaned up is because it would require simultaneously >> changing

Re: [HACKERS] On-the-fly index tuple deletion vs. hot_standby

On Thu, Jun 9, 2011 at 10:38 PM, Noah Misch wrote: > On Fri, Apr 22, 2011 at 11:10:34AM -0400, Noah Misch wrote: >> On Tue, Mar 15, 2011 at 10:22:59PM -0400, Noah Misch wrote: >> > On Mon, Mar 14, 2011 at 01:56:22PM +0200, Heikki Linnakangas wrote: >> > > On 12.03.2011 12:40, Noah Misch wrote: >>

Re: [HACKERS] Boolean operators without commutators vs. ALL/ANY

On Mon, Jun 13, 2011 at 09:01:45AM +0200, Florian Pflug wrote: > Hm, that's less bulky but more kludgy, I'd say. But wait a minute... > > If ANY and ALL are reserved anyway, should it be possible to > make "(ANY(..) )" and "(ALL(...) )" > work grammar-wise? (Note the enclosing parens) This woul

Re: [HACKERS] FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 4:38 PM, Andrew Dunstan wrote: > > > On 06/13/2011 10:25 AM, Dave Page wrote: >> >>> Don't hold your breath.  We'll probably be making enough changes in the >>> FDW infrastructure (particularly planner support) that making an FDW >>> work on both 9.1 and 9.2 would be an exe

Re: [HACKERS] procpid?

On Sun, Jun 12, 2011 at 2:23 AM, Robert Haas wrote: > On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake > wrote: >> On 6/11/2011 1:23 PM, Bruce Momjian wrote: >>> There is a difference between a project name and something that directly affects usability. +1 on fixing this. IMO, we don't

Re: [HACKERS] FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 3:54 PM, Dave Page wrote: > Yeah - MySQL is one of the ones I've been hacking on. It's hard to be > motivated if its going to need a complete rewrite within a year > though. I'll still have to work on it, as I've committed to giving > talks on it, but others might not both

Re: [HACKERS] wrong message on REASSIGN OWNED

On Mon, Jun 13, 2011 at 10:37 AM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of sáb jun 11 21:01:55 -0400 2011: >> On Thu, Jun 9, 2011 at 1:26 PM, Jaime Casanova wrote: >> > on shdepReassignOwned() we have this message, which is obviously wrong >> > we are not dropping objects ju

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

2011/6/13 Robert Haas : > On Mon, Jun 13, 2011 at 7:51 AM, Kohei KaiGai wrote: >> For syscache, length of a typical security label in selinux is >> less than 64 bytes. If we assume an entry consume 128bytes >> including Oid pairs or pointers, its consumption is 128KBytes >> per 1,000 of tables or

Re: [HACKERS] PATCH: CreateComments: use explicit indexing for ``values''

On Mon, Jun 13, 2011 at 11:09 AM, Tom Lane wrote: > I wrote: >>> Historically this i++ approach has been used in a lot of places that >>> fill in system catalog tuples.  We've fixed some of them over >>> time, but I doubt this is the only one remaining.  If we're going >>> to try to remove it here

Re: [HACKERS] procpid?

On Mon, Jun 13, 2011 at 11:56 AM, Simon Riggs wrote: > +1 > > If we were going to make changes like this, I'd suggest we save them > up in a big bag for when we change major version number. Everybody in > the world thinks that PostgreSQL v8 is compatible across all versions > (8.0, 8.1, 8.2, 8.3,

Re: [HACKERS] postgresql 9.0.4 source compilation issue on OSX

Thanks Bob for your lead. I was finally able to solve my issue. I had earlier installed the binary version of postgresql. As I had to compile certain contrib/modules sometime back, I had chosen to set USE PGXS=1 in my .zshrc file. This was causing these errors. It was silly mistake from my end. Tha

Re: [HACKERS] FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 4:08 PM, Aidan Van Dyk wrote: > On Mon, Jun 13, 2011 at 3:54 PM, Dave Page wrote: > >> Yeah - MySQL is one of the ones I've been hacking on. It's hard to be >> motivated if its going to need a complete rewrite within a year >> though. I'll still have to work on it, as I've

Re: [HACKERS] FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 5:29 PM, Christopher Browne wrote: > On Mon, Jun 13, 2011 at 4:08 PM, Aidan Van Dyk wrote: >> On Mon, Jun 13, 2011 at 3:54 PM, Dave Page wrote: >> >>> Yeah - MySQL is one of the ones I've been hacking on. It's hard to be >>> motivated if its going to need a complete rewri

Re: [HACKERS] FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 12:38 PM, Dave Page wrote: > On Mon, Jun 13, 2011 at 5:29 PM, Christopher Browne > wrote: >> On Mon, Jun 13, 2011 at 4:08 PM, Aidan Van Dyk wrote: >>> On Mon, Jun 13, 2011 at 3:54 PM, Dave Page wrote: >>> Yeah - MySQL is one of the ones I've been hacking on. It's h

[HACKERS] Participation Requested: Survey about Open-Source Software Development

Hi, Drs. Jeffrey Carver, Rosanna Guadagno, Debra McCallum, and Mr. Amiangshu Bosu, University of Alabama, and Dr. Lorin Hochstein, University of Southern California, are conducting a survey of open-source software developers. This survey seeks to understand how developers on distributed, virtual

Re: [HACKERS] [v9.2] SECURITY LABEL on shared database object

On Mon, Jun 13, 2011 at 12:24 PM, Kohei KaiGai wrote: > The attached patch is an update revision of security label support > for shared database objects. I'm kind of unexcited about this whole idea. Adding a shared catalog for a feature that's only of interest to a small percentage of our user p

Re: [HACKERS] procpid?

Simon Riggs wrote: > On Sun, Jun 12, 2011 at 2:23 AM, Robert Haas wrote: > > On Sat, Jun 11, 2011 at 9:15 PM, Joshua D. Drake > > wrote: > >> On 6/11/2011 1:23 PM, Bruce Momjian wrote: > >>> > There is a difference between a project name and something that directly > affects usability.

Re: [HACKERS] [v9.2] SECURITY LABEL on shared database object

2011/6/13 Robert Haas : > On Mon, Jun 13, 2011 at 12:24 PM, Kohei KaiGai wrote: >> The attached patch is an update revision of security label support >> for shared database objects. > > I'm kind of unexcited about this whole idea.  Adding a shared catalog > for a feature that's only of interest to

Re: [HACKERS] FOREIGN TABLE doc fix

Robert Haas writes: > On Mon, Jun 13, 2011 at 12:38 PM, Dave Page wrote: >> BTW; it seems to me this should be documented, as it could really hack >> off developers. I can't see anything in the docs to imply the API >> might be radically redesigned. > And I'm still unconvinced that it's needed.

Re: [HACKERS] FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 6:56 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jun 13, 2011 at 12:38 PM, Dave Page wrote: >>> BTW; it seems to me this should be documented, as it could really hack >>> off developers. I can't see anything in the docs to imply the API >>> might be radically red

Re: [HACKERS] FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 1:56 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jun 13, 2011 at 12:38 PM, Dave Page wrote: >>> BTW; it seems to me this should be documented, as it could really hack >>> off developers. I can't see anything in the docs to imply the API >>> might be radically red

Re: [HACKERS] [v9.2] SECURITY LABEL on shared database object

On Mon, Jun 13, 2011 at 1:40 PM, Kohei KaiGai wrote: > 2011/6/13 Robert Haas : >> On Mon, Jun 13, 2011 at 12:24 PM, Kohei KaiGai wrote: >>> The attached patch is an update revision of security label support >>> for shared database objects. >> >> I'm kind of unexcited about this whole idea.  Addin

Re: [HACKERS] FOREIGN TABLE doc fix

Dave Page writes: > On Mon, Jun 13, 2011 at 6:56 PM, Tom Lane wrote: >> I think we're talking past each other. > Hmm, I wonder if you're correct (as usual :-p). I thought you were > talking about the API as defined here: > http://www.postgresql.org/docs/9.1/static/fdw-routines.html, not > intern

Re: [HACKERS] FOREIGN TABLE doc fix

Robert Haas writes: > But my point is: any FDW code Dave rights now is not going to have > major dependencies on the planner that will potentially require > extensive reworking in the future because it won't have any real > dependencies on the planner at all. It's not like we have an API and > we

[HACKERS] Reminder: 1.5 days to 9.2 CF1

Hackers, As a reminder, CommitFest 1 for PostgreSQL 9.2 development starts in less than two days. If you have a patch for 9.2 which is ready for review, please add it to the commitfest application right now. Thanks! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsq

Re: [HACKERS] Creating new remote branch in git?

Robert Haas wrote: > On Sun, Jun 12, 2011 at 7:59 PM, Bruce Momjian wrote: > > Tom Lane wrote: > >> Bruce Momjian writes: > >> > Did the system create the .git/config '[branch "REL9_1_STABLE"]' section > >> > for you or did you create it manually? > >> > >> git created them for me. ?I did no conf

Re: [HACKERS] Reminder: 1.5 days to 9.2 CF1

On Mon, Jun 13, 2011 at 2:25 PM, Josh Berkus wrote: > As a reminder, CommitFest 1 for PostgreSQL 9.2 development starts in > less than two days. > > If you have a patch for 9.2 which is ready for review, please add it to > the commitfest application right now. You forgot part #2: please also volu

[HACKERS] SSI patch renumbered existing 2PC resource managers??

So I finally started actually reading the SSI changes, and I am a tad distressed by this: diff --git a/src/include/access/twophase_rmgr.h b/src/include/access/twophase_rmgr.h index a541d0f..1c7d8bb 100644 --- a/src/include/access/twophase_rmgr.h +++ b/src/include/access/twophase_rmgr.h @@ -23,8 +

Re: [HACKERS] [v9.2] SECURITY LABEL on shared database object

2011/6/13 Robert Haas : > On Mon, Jun 13, 2011 at 1:40 PM, Kohei KaiGai wrote: >> 2011/6/13 Robert Haas : >>> On Mon, Jun 13, 2011 at 12:24 PM, Kohei KaiGai wrote: The attached patch is an update revision of security label support for shared database objects. >>> >>> I'm kind of unexcit

Re: [HACKERS] FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 7:08 PM, Robert Haas wrote: > But my point is: any FDW code Dave rights now is not going to have > major dependencies on the planner that will potentially require > extensive reworking in the future because it won't have any real > dependencies on the planner at all.  It's

Re: [HACKERS] WIP: collect frequency statistics for arrays

On Mon, Jun 13, 2011 at 8:16 AM, Robert Haas wrote: > If the data type is hashable, you could consider building a hash table > on the MCVs and then do a probe for each element in the array. I > think that's better than the other way around because there can't be > more than 10k MCVs, whereas the

Re: [HACKERS] SSI patch renumbered existing 2PC resource managers??

Tom Lane wrote: > What was the rationale for changing the assignments of existing > 2PC IDs? So far as I can tell, that breaks pg_upgrade (if there > are any open prepared transactions) for no redeeming social > benefit. Is there a reason why TWOPHASE_RM_PREDICATELOCK_ID has > to be 2 and not

Re: [HACKERS] SSI patch renumbered existing 2PC resource managers??

On 13.06.2011 21:31, Tom Lane wrote: So I finally started actually reading the SSI changes, and I am a tad distressed by this: diff --git a/src/include/access/twophase_rmgr.h b/src/include/access/twophase_rmgr.h index a541d0f..1c7d8bb 100644 --- a/src/include/access/twophase_rmgr.h +++ b/src/in

Re: [HACKERS] [PATCH] Bug in XPATH() if expression returns a scalar value

On ons, 2011-06-08 at 10:14 +0200, Florian Pflug wrote: > But then you lose the ability to evaluate user-supplied > XPath expressions, because there's no way of telling which of these > function to use. Perhaps having both variants, one type-safe and one not, would work. I don't agree with doing

Re: [HACKERS] SSI patch renumbered existing 2PC resource managers??

On Mon, Jun 13, 2011 at 10:22:19PM +0300, Heikki Linnakangas wrote: > As far as I can tell it was for purely cosmetic reasons, to have lock > and predicate lock lines together. Yes, that is the only reason. Dan -- Dan R. K. Ports MIT CSAILhttp://drkp.net/ -- Sent

Re: [HACKERS] SSI patch renumbered existing 2PC resource managers??

Heikki Linnakangas writes: > On 13.06.2011 21:31, Tom Lane wrote: >> So far as I can tell, that breaks pg_upgrade (if there are any open >> prepared transactions) for no redeeming social benefit. > Surely pg_upgrade can't work anyway if there's any open prepared > transactions in the database. W

Re: [HACKERS] FOREIGN TABLE doc fix

Dave Page writes: > I've already implemented some simple qual pushdown in the redis FDW, > and am planning to do something similar for MySQL - however I won't be > surprised if I have to rewrite redisGetQual in > https://github.com/dpage/redis_fdw/blob/master/redis_fdw.c for > example. OK, *now*

[HACKERS] ECPG parse.pl and parse2.pl

Surely we don't need parse.pl and parse2.pl? parse.pl, the one that's not used, it already showing signs of semi-bit-rot: Use of assignment to $[ is deprecated at ./parse.pl line 21. I propose that we move parse2.pl to parse.pl and only keep the one. -- Sent via pgsql-hackers mailing list (p

Re: [HACKERS] Reminder: 1.5 days to 9.2 CF1

On 6/13/11 11:29 AM, Robert Haas wrote: > On Mon, Jun 13, 2011 at 2:25 PM, Josh Berkus wrote: >> As a reminder, CommitFest 1 for PostgreSQL 9.2 development starts in >> less than two days. >> >> If you have a patch for 9.2 which is ready for review, please add it to >> the commitfest application r

Re: [HACKERS] Make relation_openrv atomic wrt DDL

On Mon, Jun 13, 2011 at 08:21:05AM -0400, Robert Haas wrote: > On Mon, Jun 13, 2011 at 1:12 AM, Noah Misch wrote: > > This probably would not replace a backend-local counter of processed > > messages > > for RangeVarLockRelid()'s purposes. ?It's quite possibly a good way to > > reduce > > SInval

Re: [HACKERS] Creating new remote branch in git?

On 06/13/2011 02:26 PM, Bruce Momjian wrote: I found the cause. When I added 'github' to ~/.gitconfig a few months ago, I copied this line from .git/config: fetch = +refs/heads/*:refs/remotes/origin/* If this line is in ~/.gitconfig for both 'origin' and 'github', git cannot create .g

Re: [HACKERS] ECPG parse.pl and parse2.pl

Peter Eisentraut writes: > Surely we don't need parse.pl and parse2.pl? parse.pl, the one that's > not used, it already showing signs of semi-bit-rot: > Use of assignment to $[ is deprecated at ./parse.pl line 21. > I propose that we move parse2.pl to parse.pl and only keep the one. Yes. This

Re: [HACKERS] SSI patch renumbered existing 2PC resource managers??

On Mon, Jun 13, 2011 at 03:33:24PM -0400, Tom Lane wrote: > We can either change that now, or undo the > unnecessary change in existing RM IDs. I vote for the latter. Sounds good to me. I'd offer a patch, but it'd probably take you longer to apply than to make the change yourself. Dan -- Dan R

[HACKERS] ITYM DROP TABLE

I was reading the partitioning docs when I spotted this. I think it means to highlight the advantages of DROP TABLE over DELETE rather than ALTER TABLE. Best, David diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 4c9fc5d..0cdb800 100644 *** a/doc/src/sgml/ddl.sgml --- b/doc/src

Re: [HACKERS] wrong message on REASSIGN OWNED

Excerpts from Tom Lane's message of lun jun 13 09:57:50 -0400 2011: > Jaime Casanova writes: > > On Sat, Jun 11, 2011 at 8:01 PM, Robert Haas wrote: > >> "can't reassign objects owned by %s because this user is internal to > >> the database system" ? > > > that message is not that clear... it se

Re: [HACKERS] creating CHECK constraints as NOT VALID

Excerpts from Dean Rasheed's message of sáb jun 11 09:32:15 -0400 2011: > On 1 June 2011 23:47, Alvaro Herrera wrote: > > > > Here's a complete patch with all this stuff, plus doc additions and > > simple regression tests for the new ALTER DOMAIN commands. > > > >    Enable CHECK constraints to be

Re: [HACKERS] creating CHECK constraints as NOT VALID

Alvaro, Dean, >> I think that you also need to update the constraint exclusion code >> > (get_relation_constraints() or nearby), otherwise the planner might >> > exclude a relation on the basis of a CHECK constraint that is not >> > currently VALID. > Ouch, yeah, thanks for pointing that out. Fo

Re: [HACKERS] Creating new remote branch in git?

Andrew Dunstan wrote: > > > On 06/13/2011 02:26 PM, Bruce Momjian wrote: > > I found the cause. When I added 'github' to ~/.gitconfig a few months > > ago, I copied this line from .git/config: > > > > fetch = +refs/heads/*:refs/remotes/origin/* > > > > If this line is in ~/.gitconfig for both

Re: [HACKERS] Creating new remote branch in git?

On 06/13/2011 06:38 PM, Bruce Momjian wrote: Andrew Dunstan wrote: On 06/13/2011 02:26 PM, Bruce Momjian wrote: I found the cause. When I added 'github' to ~/.gitconfig a few months ago, I copied this line from .git/config: fetch = +refs/heads/*:refs/remotes/origin/* If this line i

Re: [HACKERS] creating CHECK constraints as NOT VALID

> I can see why you would want that, but I'd say that's a separate feature > you need to explicitly request when creating the constraint. Consider > what happens in the "old data is garbage, but I want the new data to be > validated" use case if we allow constraint exclusion on NOT VALID > constr

Re: [HACKERS] creating CHECK constraints as NOT VALID

On 14/06/2011 01:11, Josh Berkus wrote: Hmmm. Is this the behavior we want with NOT VALID constraints though? I know that if I'm pouring 100m rows into a new partition as part of a repartitioning scheme, I don't want to *ever* check them if I know they're correct because of how I created the tab

Re: [HACKERS] pg_trgm: unicode string not working

Robert Haas wrote: > On Sun, Jun 12, 2011 at 8:40 AM, Florian Pflug wrote: > > Note that this restriction was removed in postgres 9.1 which > > is currently in beta. However, GIT indices must be re-created > > with REINDEX after upgrading from 9.0 to leverage that > > improvement. > > Does pg_upg

[HACKERS] Why polecat and colugos are failing to build back branches

I looked into $SUBJECT. There appear to be two distinct issues: 1. On colugos (OS X with LLVM), the plperl link step is spitting up because Apple's ExtUtils::Embed puts some -arch switches into perl_embed_ldflags. We found out about that some time ago, and fixed it for 9.0 and up here: http://gi

Re: [HACKERS] lazy vxid locks, v1

On Sun, Jun 12, 2011 at 2:39 PM, Robert Haas wrote: ... > > Profiling reveals that the system spends enormous amounts of CPU time > in s_lock.  LWLOCK_STATS reveals that the only lwlock with significant > amounts of blocking is the BufFreelistLock; This is curious. Clearly the entire working set

Re: [HACKERS] Why polecat and colugos are failing to build back branches

On 06/13/2011 08:05 PM, Tom Lane wrote: I looked into $SUBJECT. There appear to be two distinct issues: 1. On colugos (OS X with LLVM), the plperl link step is spitting up because Apple's ExtUtils::Embed puts some -arch switches into perl_embed_ldflags. We found out about that some time ago,

Re: pgbench cpu overhead (was Re: [HACKERS] lazy vxid locks, v1)

On Mon, Jun 13, 2011 at 7:03 AM, Stefan Kaltenbrunner wrote: ... > > > so it seems that sysbench is actually significantly less overhead than > pgbench and the lower throughput at the higher conncurency seems to be > cause by sysbench being able to stress the backend even more than > pgbench can.

Re: [HACKERS] SSI patch renumbered existing 2PC resource managers??

Tom Lane wrote: > Heikki Linnakangas writes: > > On 13.06.2011 21:31, Tom Lane wrote: > >> So far as I can tell, that breaks pg_upgrade (if there are any open > >> prepared transactions) for no redeeming social benefit. > > > Surely pg_upgrade can't work anyway if there's any open prepared > > t

  1   2   >