On Sun, Oct 4, 2009 at 7:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com writes:
I've played around a bit with hash indexes, and it seems to me that
making them generally worthwhile will take (at least) reducing or
entirely doing away with the heavy-wait locks.
On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
I am not sure where that view implemenation is, but I doubt its
stalled because of the rule system.
It is.
You can definitely create updatable views using rules.
Sure you can, but they won't work in various significant corner cases.
On Sun, 2009-10-04 at 20:54 -0400, Alvaro Herrera wrote:
While I don't agree with David Fetter's premise, I think rehashing how
we handle VIEWs would be a good step towards updatable views. Right
now, the implementation of that is stalled precisely because of the rule
system.
The way forward
On Mon, 2009-10-05 at 12:15 +0900, KaiGai Kohei wrote:
On the other hand, it also needs to check permission both of child
table and its parents when we select data from a table with its
parents,
You can't do that anyway.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Peter Eisentraut wrote:
On Mon, 2009-10-05 at 12:15 +0900, KaiGai Kohei wrote:
On the other hand, it also needs to check permission both of child
table and its parents when we select data from a table with its
parents,
You can't do that anyway.
Sorry, I'm not clear why it is impossible.
On Sat, 2009-10-03 at 09:45 +0300, Peter Eisentraut wrote:
We could use a GUC variable to ease the transition, perhaps like
sql_inheritance = no | yes_without_privileges | yes
The original way of doing things was quite useful if you wanted some
people to be able to see history and others just
On Mon, 2009-10-05 at 16:27 +0900, KaiGai Kohei wrote:
CREATE TABLE tbl_p (int a, int b);
CREATE TABLE tbl_c (int x) INHERITS(tbl_p);
SELECT a,b FROM tbl_p; -- It selects data from only tbl_p.
It is reasonable to bypass checks on tbl_c.
SELECT b,x FROM tbl_c;
--On 5. Oktober 2009 09:51:29 +0300 Peter Eisentraut pete...@gmx.net
wrote:
The way forward with updatable views is triggers on views. I was going
to write something about that in the future. I haven't worked out all
the details.
In the mentioned discussion there was already the notion
--On 4. Oktober 2009 21:37:45 -0400 Robert Haas robertmh...@gmail.com
wrote:
This is the last I remember hearing of it, which seems to suggest that
only a week's worth of work (maybe a bit more for those of us who are
not Tom Lane) is needed:
Peter Eisentraut wrote:
On Mon, 2009-10-05 at 16:27 +0900, KaiGai Kohei wrote:
CREATE TABLE tbl_p (int a, int b);
CREATE TABLE tbl_c (int x) INHERITS(tbl_p);
SELECT a,b FROM tbl_p; -- It selects data from only tbl_p.
It is reasonable to bypass checks on tbl_c.
On Mon, 2009-10-05 at 09:22 +0100, Simon Riggs wrote:
On Sat, 2009-10-03 at 09:45 +0300, Peter Eisentraut wrote:
We could use a GUC variable to ease the transition, perhaps like
sql_inheritance = no | yes_without_privileges | yes
The original way of doing things was quite useful if you
On Mon, 2009-10-05 at 12:30 +0300, Peter Eisentraut wrote:
On Mon, 2009-10-05 at 09:22 +0100, Simon Riggs wrote:
On Sat, 2009-10-03 at 09:45 +0300, Peter Eisentraut wrote:
We could use a GUC variable to ease the transition, perhaps like
sql_inheritance = no | yes_without_privileges |
On Mon, 2009-10-05 at 10:47 +0100, Simon Riggs wrote:
top level: data-template
main tables: data, data-recent both inherit from data-template
all partitions inherit from data
only recent partitions inherit from data-recent
grants are issued on data and data-recent
I don't see where the
Tom Lane t...@sss.pgh.pa.us writes:
In cases where you do have related functions, I suggest having
SQL-callable V1 functions that absorb their arguments in this
style, and then have them call a common subroutine that's a plain
C function.
Unless you have high performance requirements, IME.
On Mon, 2009-10-05 at 13:06 +0300, Peter Eisentraut wrote:
On Mon, 2009-10-05 at 10:47 +0100, Simon Riggs wrote:
top level: data-template
main tables: data, data-recent both inherit from data-template
all partitions inherit from data
only recent partitions inherit from data-recent
On Mon, 2009-09-28 at 11:25 +0300, Heikki Linnakangas wrote:
Heikki Linnakangas wrote:
Per Simon's request, for the benefit of the archive, here's all the
changes I've done on the patch since he posted the initial version for
review for this commitfest as incremental patches. This is
On Sun, 2009-09-27 at 13:57 +0300, Heikki Linnakangas wrote:
Per Simon's request, for the benefit of the archive, here's all the
changes I've done on the patch since he posted the initial version for
review for this commitfest as incremental patches. This is extracted
from my git repository
Hi,
thank you very much for the review.
Noah Misch írta:
I took a look at 2-pg85-sqlda-10-ctxdiff.patch. Starting from CVS HEAD of
roughly 2009-10-03 05:00 UTC, prerequisite patches 1a-1h applied cleanly.
2-pg85-sqlda hit a trivial whitespace reject in ecpg.trailer along with a more
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
At the moment, user-accessible RULEs have, as far as I know,
just two sane uses:
Greg Sabino Mullane wrote:
Could this be done with a trigger? Yes, but on the plus rules side:
* It's faster
* It's easier to write
* It's immediately viewable as to what is going on with a \d mytable
* Dropping it won't leave an unused function around
* We can still do ALTER TABLE DISABLE
By chance I noticed that the foreign_data regression test fails if run
in an installation where bob is a live user. It appears to be
assuming that half a dozen other fairly common names don't belong to
real users, either. Could we make this a little less fragile? Maybe
Attached is a patch
Andrew Dunstan and...@dunslane.net wrote:
We have this para in the CREATE TABLE docs, commented out
Surely we should either include it or remove it.
+1
If it's deleted, it'll still be in CVS history if someone wants it
-Kevin
--
Sent via pgsql-hackers mailing list
allow)
Requires initdb. Beware of bugs. Slippery when wet.
--
Andrew (irc:RhodiumToad)
aorder-20091005.patch.gz
Description: aggregate ordering patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Jeff Janes jeff.ja...@gmail.com writes:
Do you know why that should be? I've done some work with gprof, and
the results are pretty suspect, because the total gprof time adds up
to only about 1/3 of the total time the backend spends on CPU
(according to top), and I don't know where the
Greg == Greg Sabino Mullane g...@turnstep.com writes:
They're mostly a foot-gun.
Greg Lots of things in Postgres could be considered potential foot
Greg guns. Frankly, I don't think rules are even near the top of
Greg such a list. Can you give examples of rule foot guns?
There are so many
On Mon, Oct 05, 2009 at 02:53:56PM +0100, Andrew Gierth wrote:
Here are a couple of the more common ones:
1) any reference in an insert rule to NEW.col where col has a volatile
default, or the expression in the insert statement was volatile, or
the expression's value is changed by the
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-10-05 at 13:06 +0300, Peter Eisentraut wrote:
I don't see where the problem is here.
In your last post you said it was necessary to use ONLY to address the
required partitions and so setup would be weird. I am showing that this
is not
Simon Riggs si...@2ndquadrant.com writes:
I don't see how that helps at all. The objective of lock counters was to
know if we can skip acquiring an LWlock on all lock partitions. This
change keeps the lock counters yet acquires the locks we were trying to
avoid. This change needs some
On Mon, 2009-10-05 at 10:14 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-10-05 at 13:06 +0300, Peter Eisentraut wrote:
I don't see where the problem is here.
In your last post you said it was necessary to use ONLY to address the
required partitions and
Martijn van Oosterhout klep...@svana.org writes:
ISTM it may be possible to use the new WITH construct here. So the rule
evaluation for the following
create table t (a integer);
create table t_log (a integer);
create rule t_ins AS ON insert TO t do also insert into t_log values (NEW.a);
On Mon, Oct 05, 2009 at 10:32:53AM -0400, Tom Lane wrote:
Martijn van Oosterhout klep...@svana.org writes:
WITH NEW AS (
insert into t values (floor(random()*1000)::integer);
RETURNING *
)
insert into t_log values (NEW.a);
Would this not have the required semantics?
On Sun, Oct 4, 2009 at 10:28 PM, Fujii Masao masao.fu...@gmail.com wrote:
I think that xlogdump (http://xlogviewer.projects.postgresql.org/) is
the first step to address that TODO item. Though I'm not sure if the
xlogdump project is still active.
I believe it has been dead for quite awhile
On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
I am not sure where that view implemenation is, but I doubt its
stalled because of the rule system.
It is.
You can definitely create updatable views using rules.
Dan Colish wrote:
On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
You can definitely create updatable views using rules.
Sure you can, but they won't work in various significant corner cases.
Search the
Hi Selena,
This is my first pass at the error logging portion of this patch. I'm
going to take a break and try to go through the partitioning logic as
well later this afternoon.
caveat: I'm not familiar with most of the code paths that are being
touched by this patch.
Overall:
* I noticed
On Mon, Oct 05, 2009 at 11:28:13AM -0400, Alvaro Herrera wrote:
Dan Colish wrote:
On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
You can definitely create updatable views using rules.
Sure you can, but they
2009/10/5 Dan Colish d...@unencrypted.org:
On Mon, Oct 05, 2009 at 11:28:13AM -0400, Alvaro Herrera wrote:
Dan Colish wrote:
On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
You can definitely create updatable views
On Mon, Oct 05, 2009 at 11:28:13AM -0400, Alvaro Herrera wrote:
Dan Colish wrote:
On Mon, Oct 05, 2009 at 09:50:18AM +0300, Peter Eisentraut wrote:
On Sun, 2009-10-04 at 18:24 -0700, Dan Colish wrote:
You can definitely create updatable views using rules.
Sure you can, but they
Stephen Frost sfr...@snowman.net wrote:
Do we have a patch which implements the necessary mechanics to
replace RULEs, even for the specific situations you list? Until
then, I don't think there's much to discuss.
I thought that until we had discussion and consensus it was premature
to start
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
Stephen Frost sfr...@snowman.net wrote:
Do we have a patch which implements the necessary mechanics to
replace RULEs, even for the specific situations you list? Until
then, I don't think there's much to discuss.
I thought that until
Emmanuel,
I think that this was the original idea but we should probably rollback
the error logging if the command has been rolled back. It might be more
consistent to use the same hi_options as the copy command. Any idea what
would be best?
Well, if we're logging to a file, you wouldn't be
Andrew,
1) any reference in an insert rule to NEW.col where col has a volatile
default, or the expression in the insert statement was volatile, or
the expression's value is changed by the insert, will do the wrong
thing:
Is this different from triggers?
2) any rule with multiple
Simon,
We could use a GUC variable to ease the transition, perhaps like
sql_inheritance = no | yes_without_privileges | yes
The original way of doing things was quite useful if you wanted some
people to be able to see history and others just see recent data. I
don't think many people are
Tom Lane wrote:
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
I think PG_TRY blocks are not enough, too. PG_TRY requires a statement
block, but we need to return from dblink functions per tuple.
That bit will have to be undone. There is no reason for dblink not to
return a
On Mon, 2009-10-05 at 11:45 +0100, Simon Riggs wrote:
On Mon, 2009-10-05 at 13:06 +0300, Peter Eisentraut wrote:
On Mon, 2009-10-05 at 10:47 +0100, Simon Riggs wrote:
top level: data-template
main tables: data, data-recent both inherit from data-template
all partitions inherit from
On Mon, 2009-10-05 at 10:27 -0700, Josh Berkus wrote:
Simon,
We could use a GUC variable to ease the transition, perhaps like
sql_inheritance = no | yes_without_privileges | yes
The original way of doing things was quite useful if you wanted some
people to be able to see history and
On Mon, 2009-10-05 at 10:19 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
I don't see how that helps at all. The objective of lock counters was to
know if we can skip acquiring an LWlock on all lock partitions. This
change keeps the lock counters yet acquires the locks
Joe Conway m...@joeconway.com writes:
Given that change, is there even any leak to even worry about? As long
as the PGresult object is created in the correct memory context, it
ought to get cleaned up automatically, no?
No, because libpq knows nothing of backend memory contexts; it just
Simon,
A small addition though, please. This functionality has been available
since 8.1 and changing things could cause existing people's scripts to
fail when they upgrade. If we make this change then we should make sure
that explicitly GRANTing a permission on the child tables does not fail.
Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
Given that change, is there even any leak to even worry about? As long
as the PGresult object is created in the correct memory context, it
ought to get cleaned up automatically, no?
No, because libpq knows nothing of backend memory
Petr Jelinek pjmo...@pjmodos.net writes:
[ latest default-ACLs patch ]
Applied with a fair amount of editorial polishing. Notably I changed
the permissions requirements a bit:
* for IN SCHEMA, the *target* role has to have CREATE permission on the
target schema. Without this, the command is a
On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
I have a comment on this bit:
@@ -125,6 +128,17 @@ main(int argc, char *argv[])
/* We rely on unmentioned fields of pset.popt to start out
0/false/NULL */
pset.popt.topt.format = PRINT_ALIGNED;
+
+
Josh Berkus j...@agliodbs.com writes:
On 10/3/09 8:09 AM, Kevin Grittner wrote:
Robert Haas robertmh...@gmail.com wrote:
let's let the default, global default ACL contain the hard-wired
privileges, instead of making them hardwired.
Wow, that would be great. It would meant that DBAs could
Joe Conway m...@joeconway.com writes:
Tom Lane wrote:
No big hurry, I think, considering the leak has always been there.
Great. It seems like this is too invasive a change to backport. My
feeling is that not enough people have complained about this specific
scenario to warrant the risk.
On Mon, 2009-10-05 at 11:58 -0700, Josh Berkus wrote:
Simon,
A small addition though, please. This functionality has been available
since 8.1 and changing things could cause existing people's scripts to
fail when they upgrade. If we make this change then we should make sure
that
Roger Leigh rle...@codelibre.net writes:
On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
Elsewhere in the psql code, notably in mbprint.c, we make the decision
on whether to apply certain Unicode-aware processing based on whether
the client encoding is UTF8. The same should
On Wed, Sep 30, 2009 at 11:17 PM, Stephen Frost sfr...@snowman.net wrote:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Stephen Frost wrote:
Thanks. To make sure it gets picked up, you might respond to Tom's
message above with this same email. Just a thought.
The following message was my
2009/10/6 Tom Lane t...@sss.pgh.pa.us:
Applied with a fair amount of editorial polishing. Notably I changed
the permissions requirements a bit:
Thanks and congratulations! I'm really looking forward to this feature.
I pulled the latest sources and gave it a whirl. Things worked as
expected
* Robert Haas (robertmh...@gmail.com) wrote:
So what's the status of this patch currently?
I'll be reviewing the updates shortly. After that, I'd like a committer
to review it.
Thanks,
Stephen
signature.asc
Description: Digital signature
Simon Riggs wrote:
We discussed briefly your change
0011-Replace-per-proc-counters-of-loggable-locks-with-per.patch.
I don't see how that helps at all. The objective of lock counters was to
know if we can skip acquiring an LWlock on all lock partitions. This
change keeps the lock counters
Simon Riggs wrote:
On Mon, 2009-09-28 at 11:25 +0300, Heikki Linnakangas wrote:
Heikki Linnakangas wrote:
Per Simon's request, for the benefit of the archive, here's all the
changes I've done on the patch since he posted the initial version for
review for this commitfest as incremental
Tom Lane napsal(a):
Petr Jelinek pjmo...@pjmodos.net writes:
[ latest default-ACLs patch ]
Applied with a fair amount of editorial polishing. Notably I changed
the permissions requirements a bit:
Thank you very much Tom.
One thing that seems like it's likely to be an annoyance
shakahsha...@gmail.com wrote:
Can anyone elaborate (or point me to some additional info) on the 8.5
TODO item in the Point-In-Time Recover (PITR) section (1.4):
Create dump tool for write-ahead logs for use in determining
transaction id for point-in-time recovery
This is useful for
Petr Jelinek pjmo...@pjmodos.net writes:
Tom Lane napsal(a):
One thing that seems like it's likely to be an annoyance in practice
is the need to explicitly do DROP OWNED BY to get rid of pg_default_acl
entries for a role to be dropped.
Yeah I am not happy about this either but there is not
Brendan Jurd dire...@gmail.com writes:
I pulled the latest sources and gave it a whirl. Things worked as
expected in psql, but I was a little surprised when I headed into the
documentation. The first place I visited was Chapter 20 - Database
Roles and Privileges, but there was no mention of
Tom Lane napsal(a):
Petr Jelinek pjmo...@pjmodos.net writes:
Tom Lane napsal(a):
One thing that seems like it's likely to be an annoyance in practice
is the need to explicitly do DROP OWNED BY to get rid of pg_default_acl
entries for a role to be dropped.
Yeah I am not happy
Hi,
it seems like we can't do this. At least a get this error:
db=# alter table pg_largeobject set tablespace otro;
ERROR: permission denied: pg_largeobject is a system catalog
but pg_largeobject seems sensible to move to another table space for
space considerations, no? are there any reasons
Jaime Casanova jcasa...@systemguards.com.ec writes:
it seems like we can't do this. At least a get this error:
db=# alter table pg_largeobject set tablespace otro;
ERROR: permission denied: pg_largeobject is a system catalog
You can move *all* of the system catalogs with ALTER DATABASE SET
2009/10/6 Tom Lane t...@sss.pgh.pa.us:
Brendan Jurd dire...@gmail.com writes:
I pulled the latest sources and gave it a whirl. Things worked as
expected in psql, but I was a little surprised when I headed into the
documentation. The first place I visited was Chapter 20 - Database
Roles and
Jaime Casanova escreveu:
it seems like we can't do this. At least a get this error:
db=# alter table pg_largeobject set tablespace otro;
ERROR: permission denied: pg_largeobject is a system catalog
but pg_largeobject seems sensible to move to another table space for
space considerations,
On Mon, Oct 5, 2009 at 1:46 PM, Joe Conway m...@joeconway.com wrote:
Tom Lane wrote:
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
I think PG_TRY blocks are not enough, too. PG_TRY requires a statement
block, but we need to return from dblink functions per tuple.
That bit will have
On Sun, Oct 4, 2009 at 4:14 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Mon, Sep 28, 2009 at 12:14 AM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Sat, Aug 8, 2009 at 7:47 PM, Mark Kirkwood mar...@paradise.net.nz wrote:
Patch with max(wait time).
Still TODO
- amalgamate
Hi,
On Tue, Oct 6, 2009 at 7:47 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
That TODO item is a lot less important after we have Hot Standby. It
contains functions that allow you to pause and continue WAL replay, and
step through the WAL one transaction at a time.
I
Robert Haas wrote:
On Mon, Oct 5, 2009 at 1:46 PM, Joe Conway m...@joeconway.com wrote:
I can't promise to make this change before 15 October, but I will get to
it before the end of CF3.
Another possibility is that Itagaki Takahiro, who developed the
original patch, might be willing to
There are now 19 patches out of an original total of 48 to be dealt
with for this CommitFest. Of those, 10 are marked as Ready for
Committer, 1 is marked as Needs Review and the listed reviewer is a
committer, 7 are waiting for review or re-review by non-committers,
and 1 is waiting on the patch
Josh == Josh Berkus j...@agliodbs.com writes:
1) any reference in an insert rule to NEW.col where col has a volatile
default, or the expression in the insert statement was volatile, or
the expression's value is changed by the insert, will do the wrong
thing:
Josh Is this different from
I rebased the largeobject access controls patch to the CVS HEAD
because of the patch confliction to the default ACL patch.
The only difference was a switch-case statement was moved from
shdepDropOwned() to RemoveRoleFromObjectACL(), so we had to
change the point to be patched.
I don't think this
Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
So what's the status of this patch currently?
I'll be reviewing the updates shortly. After that, I'd like a committer
to review it.
Do you think this version also should rework an invocation of
pg_namespace_aclcheck() newly
Fujii Masao escreveu:
On Tue, Oct 6, 2009 at 7:47 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
That TODO item is a lot less important after we have Hot Standby. It
contains functions that allow you to pause and continue WAL replay, and
step through the WAL one transaction
On Mon, Oct 5, 2009 at 7:15 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
db=# alter table pg_largeobject set tablespace otro;
ERROR: permission denied: pg_largeobject is a system catalog
[1] http://archives.postgresql.org/pgsql-hackers/2004-06/msg00835.php
seems like the original
Jaime Casanova jcasa...@systemguards.com.ec writes:
seems like the original idea was to forbid this in all system catalogs
except pg_largeobject, what happen then?
Nothing ... nobody got around to doing anything about it.
regards, tom lane
--
Sent via pgsql-hackers
On Mon, Oct 5, 2009 at 10:17 AM, Josh Berkus j...@agliodbs.com wrote:
So while rules are hard to use and easy to mess up, so are triggers. So
while an (arguable) problem is being pointed out, no real solution is
being proposed.
If you want to implement updatable views I still stand by my
I tried to check the default ACL behavior.
postgres=# \c - ymj
psql (8.5devel)
You are now connected to database postgres as user ymj.
postgres= ALTER DEFAULT PRIVILEGES REVOKE INSERT ON TABLE FROM ymj;
ALTER DEFAULT PRIVILEGES
postgres= CREATE TABLE t2 (x int, y text);
CREATE TABLE
83 matches
Mail list logo
