Hi,
On Wed, Jun 17, 2009 at 12:22 AM, Czichy, Thoralf (NSN -
FI/Helsinki)thoralf.czi...@nsn.com wrote:
[STONITH is not always best strategy if failures can be declared as
user-space software problem only, limit STONITH to HW/OS failures]
The isolation of the failing Postgres instance does not
So, here is the first version of the patch.
It includes functionality itself, simple regression test and also very
simple documentation.
The patch allows GRANT ON ALL TABLES/VIEWS/FUNCTIONS/SEQUENCES IN
schemaname, schemaname2 TO username and same thing for REVOKE.
Words TABLES, VIEWS,
Hi all,
Speaking of which, what about some performance numbers?
OK, benchmarks done:
http://ozlabs.org/~jk/projects/db/data/postgres.bcTruelen/
Summary: small increase in performance (~1-2% on my machine), at about
1.5 standard deviations from the mean. Profiles show a decent drop in
hits
On Wed, Jun 17, 2009 at 3:01 PM, Jeremy Kerr j...@ozlabs.org wrote:
Will re-send the patch once I work out how to get git to create a
context diff...
http://wiki.postgresql.org/wiki/Working_with_Git#Context_diffs_with_Git
--
Lets call it Postgres
EnterpriseDB
Jeremy Kerr wrote:
Speaking of which, what about some performance numbers?
OK, benchmarks done:
http://ozlabs.org/~jk/projects/db/data/postgres.bcTruelen/
Summary: small increase in performance (~1-2% on my machine), at about
1.5 standard deviations from the mean. Profiles show a decent
Hello, pgsql-hackers.
Is there any possibility that Postgres will have named transaction
ever, like Firebird?
Now for each transaction client should open separate connection. But
CONNECTION LIMIT option for database make this a little bit harder
--
With best wishes,
Pavel
Heikki Linnakangas wrote:
Jeremy Kerr wrote:
Speaking of which, what about some performance numbers?
OK, benchmarks done:
http://ozlabs.org/~jk/projects/db/data/postgres.bcTruelen/
Summary: small increase in performance (~1-2% on my machine), at about
1.5 standard deviations from the
On Wed, Jun 17, 2009 at 3:26 PM, Jeremy Kerr j...@ozlabs.org wrote:
Hurjeet,
http://wiki.postgresql.org/wiki/Working_with_Git#Context_diffs_with_G
it
Awesome, thanks.
I'm going to wait for a decision before reformatting and sending the
diff.
You might want to submit the patch (if
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically to match the client's locale? We have
pg_get_encoding_from_locale() function that we can use to extract the
encoding from
Jeremy Kerr wrote:
Hi all,
Speaking of which, what about some performance numbers?
OK, benchmarks done:
http://ozlabs.org/~jk/projects/db/data/postgres.bcTruelen/
Summary: small increase in performance (~1-2% on my machine), at about
1.5 standard deviations from the mean. Profiles show a
Heikki Linnakangas wrote:
client_encoding defaults to server_encoding, which is correct in the
typical environment where the client and the server have identical
locale settings, which I believe is why we don't see more confused
users on mailing lists. However, a partner of ours was
On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically to match the client's locale? We have
In plpgsql, if you write
OPEN var BLAH
you can an error message like this:
ERROR: syntax error ...
DETAIL: Expected FOR, to open a reference cursor.
But what is a reference cursor? Isn't this rather saying ... to open a
cursor, a reference to which will be stored in your variable? Anyone
On Wednesday 17 June 2009 11:29:10 Petr Jelinek wrote:
The patch allows GRANT ON ALL TABLES/VIEWS/FUNCTIONS/SEQUENCES IN
schemaname, schemaname2 TO username and same thing for REVOKE.
Words TABLES, VIEWS, FUNCTIONS and SEQUENCES were added as unreserved
keywords. Unfortunately I was unable to
Peter,
* Peter Eisentraut (pete...@gmx.net) wrote:
Also since this patch introduces VIEWS as object with grantable
privileges, I added GRANT ON VIEW foo syntax which is more or less
synonymous to GRANT ON TABLE foo syntax. It felt weird to have GRANT ON
ALL VIEWS but not GRANT ON VIEW.
Peter Eisentraut pete...@gmx.net writes:
I think you should design this with a bit wider scope. Instead of just all
tables in this schema, think all tables satisfying some condition. It has
been requested, for example, to be able to grant on all tables that match a
pattern.
I'm against
On Tuesday 16 June 2009 16:22:27 Robert Haas wrote:
1. It didn't seem very wise to go with the approach of trying to do
EVERYTHING with attributes. If I did that, then I'd either get really
long lines that were not easily readable, or I'd have to write some
kind of complicated line wrapping
On Wed, Jun 17, 2009 at 10:27 AM, Peter Eisentrautpete...@gmx.net wrote:
On Tuesday 16 June 2009 16:22:27 Robert Haas wrote:
1. It didn't seem very wise to go with the approach of trying to do
EVERYTHING with attributes. If I did that, then I'd either get really
long lines that were not
On 06/17/2009 04:27 PM, Peter Eisentraut wrote:
On Tuesday 16 June 2009 16:22:27 Robert Haas wrote:
1. It didn't seem very wise to go with the approach of trying to do
EVERYTHING with attributes. If I did that, then I'd either get really
long lines that were not easily readable, or I'd have to
Petr,
* Petr Jelinek (pjmo...@pjmodos.net) wrote:
So, here is the first version of the patch.
Neat, thanks! Some initial comments:
You should read through this:
http://wiki.postgresql.org/wiki/Submitting_a_Patch
First big thing is that the patch should be a context diff. I would
also
On Tuesday 16 June 2009 22:51:37 Robert Haas wrote:
I agree. I'm just not seeing the need for an *explicit*
categorization contained within the data itself. For one thing, AIUI,
that's the job of things like an XML Schema, which Andres Freund has
already agreed to write, and I would expect
Stephen Frost wrote:
I don't like the idea that a 'GRANT ALL' would actually change default
ACLs for a schema though. These are two separate and distinct things-
one is implementing a change to existing objects, the other is setting a
default for new objects. Mixing them would lead to
Stephen Frost wrote:
http://wiki.postgresql.org/wiki/Submitting_a_Patch
First big thing is that the patch should be a context diff. I would
It is context diff, at least I think so, I followed the instructions on
wiki on how to make context patch from git repo.
also recommend you put it
* Petr Jelinek (pjmo...@pjmodos.net) wrote:
Stephen Frost wrote:
I don't like the idea that a 'GRANT ALL' would actually change default
ACLs for a schema though. These are two separate and distinct things-
one is implementing a change to existing objects, the other is setting a
default for
On Wednesday 17 June 2009 17:15:04 Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I think you should design this with a bit wider scope. Instead of just
all tables in this schema, think all tables satisfying some
condition. It has been requested, for example, to be able to grant
Peter Eisentraut pete...@gmx.net writes:
Why don't we tell people to write a plpgsql loop for the schema.* case as
well?
Indeed, why not? This all seems much more like gilding the lily than
delivering useful new capability. The default-ACL stuff that Stephen
is working on seems far more
* Petr Jelinek (pjmo...@pjmodos.net) wrote:
It is context diff, at least I think so, I followed the instructions on
wiki on how to make context patch from git repo.
err, sorry, tbh I just looked at the 'diff --git' line and didn't see
any '-c'.. Trying to do too much at one time, I'm afraid.
On Tuesday 16 June 2009 20:21:21 Tom Lane wrote:
As a concrete example of what I'm thinking about, I'd hope that PgAdmin
would be able to display a graphical summary of a plan tree, and then
pop up measurements associated with one of the nodes when you
right-click on that node. To do this, it
Peter Eisentraut wrote:
I think you should design this with a bit wider scope. Instead of just all
tables in this schema, think all tables satisfying some condition. It has
been requested, for example, to be able to grant on all tables that match a
pattern.
Well, that's certainly possible
Tom Lane erote:
Peter Eisentraut pete...@gmx.net writes:
Why don't we tell people to write a plpgsql loop for the schema.* case as
well?
Indeed, why not? This all seems much more like gilding the lily than
delivering useful new capability. The default-ACL stuff that Stephen
is
On Wed, Jun 17, 2009 at 10:40 AM, Peter Eisentrautpete...@gmx.net wrote:
On Tuesday 16 June 2009 20:21:21 Tom Lane wrote:
As a concrete example of what I'm thinking about, I'd hope that PgAdmin
would be able to display a graphical summary of a plan tree, and then
pop up measurements associated
Pavel Golub pa...@microolap.com writes:
Is there any possibility that Postgres will have named transaction
ever, like Firebird?
What in heck is a named transaction, and why should we care?
regards, tom lane
--
Sent via pgsql-hackers mailing list
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically to match the client's
Peter Eisentraut pete...@gmx.net writes:
In plpgsql, if you write
OPEN var BLAH
you can an error message like this:
ERROR: syntax error ...
DETAIL: Expected FOR, to open a reference cursor.
But what is a reference cursor? Isn't this rather saying ... to open a
cursor, a reference to
Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically to match the client's locale? We have
pg_get_encoding_from_locale() function that we can use
2009/6/17 Petr Jelinek pjmo...@pjmodos.net:
I agree that Default ACLs are more important and I already offered Stephen
help on that. But I've seen countless requests for granting on all tables to
a user and I already got some positive feedback outside of the list, so I
believe there is demand
On Jun 17, 2009, at 8:08 AM, Tom Lane wrote:
Pavel Golub pa...@microolap.com writes:
Is there any possibility that Postgres will have named transaction
ever, like Firebird?
What in heck is a named transaction, and why should we care?
That Tom Lane, so warm and cuddly!
David
--
Sent via
I'm curious what they ate too
--
Greg
On 17 Jun 2009, at 17:37, David E. Wheeler da...@kineticode.com
wrote:
On Jun 17, 2009, at 8:08 AM, Tom Lane wrote:
Pavel Golub pa...@microolap.com writes:
Is there any possibility that Postgres will have named transaction
ever, like Firebird?
Isn't the answer to grant permissions to a role and then just put
people in that role?
--
Greg
On 17 Jun 2009, at 17:25, Guillaume Smet guillaume.s...@gmail.com
wrote:
2009/6/17 Petr Jelinek pjmo...@pjmodos.net:
I agree that Default ACLs are more important and I already offered
Greg Stark greg.st...@enterprisedb.com wrote:
On Jun 17, 2009, at 8:08 AM, Tom Lane wrote:
Pavel Golub pa...@microolap.com writes:
Is there any possibility that Postgres will have named
transaction ever, like Firebird?
What in heck is a named transaction, and why should we care?
I'm
Greg Stark wrote:
Isn't the answer to grant permissions to a role and then just put
people in that role?
Still have to give permissions at least to that role.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Wed, Jun 17, 2009 at 12:41 PM, Greg Starkgreg.st...@enterprisedb.com wrote:
On 17 Jun 2009, at 17:37, David E. Wheeler da...@kineticode.com wrote:
On Jun 17, 2009, at 8:08 AM, Tom Lane wrote:
Pavel Golub pa...@microolap.com writes:
Is there any possibility that Postgres will have named
On Wed, Jun 17, 2009 at 12:25 PM, Guillaume
Smetguillaume.s...@gmail.com wrote:
2009/6/17 Petr Jelinek pjmo...@pjmodos.net:
I agree that Default ACLs are more important and I already offered Stephen
help on that. But I've seen countless requests for granting on all tables to
a user and I
Tom Lane wrote:
Pavel Golub pa...@microolap.com writes:
Is there any possibility that Postgres will have named transaction
ever, like Firebird?
What in heck is a named transaction, and why should we care?
Isn't this just another name for a
Andrew Dunstan wrote:
Tom Lane wrote:
What in heck is a named transaction, and why should we care?
Isn't this just another name for a subtransaction or inner transaction
that can be separately committed?
AFAIK that's an autonomous transaction, at least to some other RDBMSs.
--
Alvaro
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
What in heck is a named transaction, and why should we care?
Isn't this just another name for a subtransaction or inner transaction
that can be separately committed?
AFAIK that's an autonomous transaction,
Andrew Dunstan and...@dunslane.net writes:
Alvaro Herrera wrote:
AFAIK that's an autonomous transaction, at least to some other RDBMSs.
Right, but since I had to ask what that was recently I though I'd use a
bit more description :-)
Yes, but some other followups suggest that maybe a named
On Wed, Jun 17, 2009 at 6:40 PM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
What in heck is a named transaction, and why should we care?
Isn't this just another name for a subtransaction or inner transaction
that can be separately committed?
On Wed, Jun 17, 2009 at 3:04 PM, Greg Starkst...@enterprisedb.com wrote:
On Wed, Jun 17, 2009 at 6:40 PM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
What in heck is a named transaction, and why should we care?
Isn't this just another name for a
Greg Stark wrote:
On Wed, Jun 17, 2009 at 6:40 PM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
AFAIK that's an autonomous transaction, at least to some other RDBMSs.
I have no idea what they are in Firebird but the name conjured up a
different (interesting) idea for me. I had the
Tom Lane t...@sss.pgh.pa.us wrote:
Yes, but some other followups suggest that maybe a named
transaction does something else entirely. Thus my request for a
definition of what the OP is actually asking for.
Well, a quick google search suggests that all three guesses here were
off base.
On Wed, 2009-06-17 at 14:38 -0500, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Yes, but some other followups suggest that maybe a named
transaction does something else entirely. Thus my request for a
definition of what the OP is actually asking for.
Well, a quick
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Alvaro Herrera wrote:
AFAIK that's an autonomous transaction, at least to some other RDBMSs.
Right, but since I had to ask what that was recently I though I'd use a
bit more description :-)
Yes, but some
Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Yes, but some other followups suggest that maybe a named
transaction does something else entirely. Thus my request for a
definition of what the OP is actually asking for.
Well, a quick google search suggests that all three
This was failing:
CREATE TRIGGER foo
AFTER INSERT OR UPDATE OR DELETE OR TRUNCATE
ON foobar
FOR EACH STATEMENT EXECUTE PROCEDURE baz();
Turns out the parser wasn't set up to handle four different trigger
event types. Patch attached.
--
Greg Sabino Mullane g...@endpoint.com g...@turnstep.com
On Wed, Jun 17, 2009 at 8:09 PM, Robert Haasrobertmh...@gmail.com wrote:
I have no idea what they are in Firebird but the name conjured up a
different (interesting) idea for me. I had the image of naming a
transaction and then being able to have other sessions join that same
transaction.
On Wed, Jun 17, 2009 at 4:54 PM, Alvaro
Herreraalvhe...@commandprompt.com wrote:
Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically to match the
Greg Sabino Mullane g...@turnstep.com writes:
This was failing:
CREATE TRIGGER foo
AFTER INSERT OR UPDATE OR DELETE OR TRUNCATE
ON foobar
FOR EACH STATEMENT EXECUTE PROCEDURE baz();
Turns out the parser wasn't set up to handle four different trigger
event types.
Hmm, that's a problem ...
Andrew Dunstan and...@dunslane.net writes:
According to the (hard to find) Firebird docs (or rather, the old
Interbase docs, which is all they have):
A single application can start simultaneous transactions. InterBase
extends transaction
management and data manipulation
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
NotDashEscaped: You need GnuPG to verify this message
... but this patch doesn't come close to fixing it. struct CreateTrigStmt
needs changes. I kinda think the
Peter Eisentraut pete...@gmx.net wrote:
On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically to match the
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Peter Eisentraut pete...@gmx.net wrote:
On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
Here is an updated version of my generic options for explain patch.
Previous version here:
http://archives.postgresql.org/pgsql-hackers/2009-06/msg00866.php
This patch requires the explain refactoring v4 patch, which you can
find here, to be applied first:
Greg Sabino Mullane g...@turnstep.com writes:
Thanks. I'll leave the [5] restriction call to someone else, seems it
does no harm to me though (not as if we'd change it that often anyway).
Revised patch below. I looked through other places that might be affected,
but did not see anything else
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jun 17, 2009 at 04:32:51PM +0200, Andres Freund wrote:
On 06/17/2009 04:27 PM, Peter Eisentraut wrote:
On Tuesday 16 June 2009 16:22:27 Robert Haas wrote:
1. It didn't seem very wise to go with the approach of trying to do
EVERYTHING with
65 matches
Mail list logo
