2009/9/24 KaiGai Kohei kai...@ak.jp.nec.com:
Example)
postgres=# SET SESSION AUTHORIZATION ymj;
SET
postgres= SELECT loread(lo_open(16453, x'4'::int), 20);
ERROR: permission denied for largeobject 16453
postgres=# SET largeobject_compat_acl = on; enables
Jaime Casanova wrote:
2009/9/23 KaiGai Kohei kai...@ak.jp.nec.com:
Jaime,
KaiGai Kohei wrote:
| ALTER LARGE OBJECT is working, but now that we can change the owner of
| a LO we should be able to see who the actual owner is... i mean we
| should add an owner column in \dl for psql (maybe
Jaime Casanova wrote:
2009/9/24 KaiGai Kohei kai...@ak.jp.nec.com:
Example)
postgres=# SET SESSION AUTHORIZATION ymj;
SET
postgres= SELECT loread(lo_open(16453, x'4'::int), 20);
ERROR: permission denied for largeobject 16453
postgres=# SET largeobject_compat_acl = on;
Hi,
Sorry for the delay.
On Mon, Sep 21, 2009 at 4:51 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Having gone through the patch now in more detail, I think it's in pretty
good shape. I'm happy with the overall design, except that I haven't
been able to make up my mind if
Hi all,
I am using psqlodbc to connect to PostgreSQL8.2.4 server on Linux.
The manual says BEGIN TRANSACATION is equlvalent to START
TRANSACTION, but it turns out that they throw different error message
and have different effect to subsequent queries.
I have a table CREATE TEMPORARY TABLE ooid
Hi,
On Mon, Sep 21, 2009 at 1:55 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The startup process could capture stderr from walreceiver and forward it
with elog(LOG).
The startup process should obtain also the message level in some way
(pipe?), and control the messages
On Thu, 2009-09-24 at 17:51 +0900, ning wrote:
Hi all,
I am using psqlodbc to connect to PostgreSQL8.2.4 server on Linux.
The manual says BEGIN TRANSACATION is equlvalent to START
TRANSACTION, but it turns out that they throw different error message
and have different effect to subsequent
Petr Jelinek wrote:
I made some more small adjustments - mainly renaming stuff after Tom's
comment on anonymous code blocks patch and removed one unused shared
dependency.
Hi,
the patch still has some issues with dependency handling:
postgres=# create role test;
CREATE ROLE
postgres=# create
Hi,
On Mon, Sep 21, 2009 at 4:51 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I found the paging logic in walsender confusing, and didn't like the
idea that walsender needs to set the XLOGSTREAM_END_SEG flag. Surely
walreceiver knows how to split the WAL into files without
Heikki Linnakangas wrote:
The problem becomes a lot easier if we accept that it's OK to have a
lock included in the running-xacts snapshot and also appear in a
XLOG_RELATION_LOCK record later. The standby should handle that
gracefully already. If we just remove RecoveryInfoLock, that can
Fujii Masao wrote:
In the 'replication-orig' branch, walreceiver fsyncs the previous XLOG
file after receiving new XLOG records before writing them. This would
increase the backend's waiting time for replication in synchronous case.
The walreceiver should fsync the XLOG file after sending ACK
Hi,
On Thu, Sep 24, 2009 at 7:41 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
In the 'replication-orig' branch, walreceiver fsyncs the previous XLOG
file after receiving new XLOG records before writing them. This would
increase the backend's waiting
Fujii Masao wrote:
On Mon, Sep 21, 2009 at 4:51 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
- Can we replace read/write_conninfo with just a long-enough field in
shared mem? Would be simpler. (this is moot if we go with the
stand-alone walreceiver program and pass it as
Fujii Masao wrote:
On Thu, Sep 24, 2009 at 7:41 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
In the 'replication-orig' branch, walreceiver fsyncs the previous XLOG
file after receiving new XLOG records before writing them. This would
increase the
Jan Urbański napsal(a):
Petr Jelinek wrote:
I made some more small adjustments - mainly renaming stuff after Tom's
comment on anonymous code blocks patch and removed one unused shared
dependency.
Hi,
the patch still has some issues with dependency handling:
postgres=# create role
OK, the previous problem went away, but I can still do something like that:
postgres=# create role test;
CREATE ROLE
postgres=# create role test2;
CREATE ROLE
postgres=# create database db;
CREATE DATABASE
postgres=# \c db
psql (8.5devel)
You are now connected to database db.
db=# alter default
On Thu, Sep 24, 2009 at 12:16:43PM +0300, Hannu Krosing wrote:
I expect the transaction is aborted and rollback is executed
automatically. - this is not how postgreSQL behaves. PostgreSQL needs
an explicit end of transaction from client, either COMMIT; or ROLLBACK;
when run from psql, they
Jan Urbański napsal(a):
Dependencies suck, I know..
Cross-database dependencies do.
I had to make target role owner of the default acls which adds some side
effects like the fact that it blocks DROP ROLE so DROP OWNED BY has to
be used.
As for REASSIGN OWNED, it does not reassign
On Thu, Sep 24, 2009 at 6:16 PM, Hannu Krosing ha...@krosing.net wrote:
On Thu, 2009-09-24 at 17:51 +0900, ning wrote:
Hi all,
I am using psqlodbc to connect to PostgreSQL8.2.4 server on Linux.
The manual says BEGIN TRANSACATION is equlvalent to START
TRANSACTION, but it turns out that they
Petr Jelinek wrote:
Jan Urbański napsal(a):
Dependencies suck, I know..
Cross-database dependencies do.
I had to make target role owner of the default acls which adds some side
effects like the fact that it blocks DROP ROLE so DROP OWNED BY has to
be used.
As for REASSIGN OWNED, it
Robert Haas wrote:
However, that's not the whole problem, either. To your point about
documentation, it seems this path doesn't touch the README at all, and
it needs to, because some of the statements in that file would
certainly become false were this patch to be applied.
So I think we should
On Sep 24, 2009, at 6:24 AM, p...@thetdh.com wrote:
In a context using normalization, wouldn't you typically want to
store a normalized-text type that could perhaps (depending on
locale) take advantage of simpler, more-efficient comparison
functions?
That might be nice, but I'd be wary
David E. Wheeler wrote:
On Sep 24, 2009, at 6:24 AM, p...@thetdh.com wrote:
In a context using normalization, wouldn't you typically want to
store a normalized-text type that could perhaps (depending on locale)
take advantage of simpler, more-efficient comparison functions?
That might be
On Sep 24, 2009, at 8:59 AM, Andrew Dunstan wrote:
That might be nice, but I'd be wary of a geometric multiplication
of text types. We already have TEXT and CITEXT; what if we had your
NTEXT (normalized text) but I wanted it to also be case-insensitive?
Actually, I don't think it's
On Wed, 2009-09-23 at 22:46 +0300, Marko Kreen wrote:
I looked at your code for U and saw that you allow standalone
second half of the surrogate pair there, although you error
out on first half. Was that deliberate?
No.
Perhaps pg_verifymbstr() should be made to check for such values,
If it could be done with a emphasissmall/ amount of throwaway
code, maybe ...
Well, that's a reasonable goal ...
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, Sep 24, 2009 at 07:57:55PM +0100, Sam Mason wrote:
postg...@sussy:/root createuser -D -p ricky
I don't think you want to be passing -p here; it's saying to use
ricky as the port number, which fails (sounds like a bug if it doesn't
complain about this) giving a port number of zero
In a context using normalization, wouldn't you typically want to store a
normalized-text type that could perhaps (depending on locale) take advantage of
simpler, more-efficient comparison functions? Whether you're doing
INSERT/UPDATE, or importing a flat text file, if you canonicalize
Hi,
I recently saw a complaint that a simple PL/PgSQL code is slower than PL/SQL.
I did some benchmark and confirmed it is. I coded the same function
(function2) in C just to compare with something. According to OP [1], the
PL/SQL seems to run more than 15x faster than PL/PgSQL code.
euler=#
Tom Lane escribió:
Gurjeet Singh singh.gurj...@gmail.com writes:
ON instead of second ALTER looks better, and IMHO DATABASE dbname should
be optional too:
ALTER ROLE rolename [ON DATABASE dbname] SET config TO value;
IN, not ON.
This creates a parser conflict with
CREATE ROLE foo IN
Euler Taveira de Oliveira eu...@timbira.com writes:
I recently saw a complaint that a simple PL/PgSQL code is slower than PL/SQL.
I did some benchmark and confirmed it is. I coded the same function
(function2) in C just to compare with something. According to OP [1], the
PL/SQL seems to run
Hi,
the attached patch addresses the performance issues of the
authorization related views from information_schema (BUG #4596). It
implements what Tom suggests in
http://archives.postgresql.org/pgsql-bugs/2008-12/msg00144.php
In the cases that I have tested both the new and the old view return
The attached patch is revised from the previous revision at the following
points:
- The largeobject_compat_acl is renamed to largeobject_check_acl.
Its default is on, and turning it off means the largeobject stuff
performs in compatible mode for the v8.4.x or prior releases.
- Notification
Magnus Hagander wrote:
On Mon, Sep 21, 2009 at 20:12, Stef Walter stef-l...@memberwebs.com wrote:
This patch does not build on Windows, the error is:
ip.obj : error LNK2019: unresolved external symbol __imp__wsaio...@36
referenced
in function _pg_foreach_ifaddr
ip.obj : error LNK2019:
Sam Mason s...@samason.me.uk writes:
Hum, why is PG doing an (unchecked) atoi on the user specified port
rather than leaving it up to getaddrinfo to resolve the port? It would
seem to require changing UNIXSOCK_PATH to accept a string as the port
number, which is probably a bit much of a
On Thu, Sep 24, 2009 at 8:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, are port numbers still limited to 16 bits in IPv6?
Yes.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Sam Mason s...@samason.me.uk writes:
+ if (portnum 1 || portnum 65535)
BTW, it strikes me that we could tighten this even more by rejecting
target ports below 1024. This is guaranteed safe on all Unix systems
I know of, because privileged ports can only be listened to by
Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
+if (portnum 1 || portnum 65535)
BTW, it strikes me that we could tighten this even more by rejecting
target ports below 1024. This is guaranteed safe on all Unix systems
I know of, because privileged ports can only be
On Thu, 24 Sep 2009, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
+ if (portnum 1 || portnum 65535)
BTW, it strikes me that we could tighten this even more by rejecting
target ports below 1024.
Restricting the target port seems like a bad idea. What about a
On Thu, Sep 24, 2009 at 8:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Sam Mason s...@samason.me.uk writes:
+ if (portnum 1 || portnum 65535)
BTW, it strikes me that we could tighten this even more by rejecting
target ports below 1024. This is guaranteed safe on all Unix systems
On Tue, Sep 15, 2009 at 2:18 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Magnus Hagander wrote:
I'm not sure I like this as a GUC. We're going to end up with a lot of
different GUCs, and everytime we add a new log destination (admittedly
not often, of course), that increases even
On Fri, Sep 18, 2009 at 12:14 AM, Emmanuel Cecchet m...@asterdata.com wrote:
Here is a new version of error logging and autopartitioning in COPY based on
the latest COPY patch that provides the new syntax for copy options (this
patch also includes the COPY option patch).
New features compared
Yes, I have to update the patch following what Tom already integrated of
the COPY patch.
I will get a new version posted as soon as I can.
Emmanuel
Robert Haas wrote:
On Fri, Sep 18, 2009 at 12:14 AM, Emmanuel Cecchet m...@asterdata.com wrote:
Here is a new version of error logging and
On Mon, Sep 14, 2009 at 4:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
First, the patch removes the logging_collector parameter and basically
assumes that logging_collector is always on.
I don't find that to be a good idea, and you certainly have not
Tom Lane escreveu:
FWIW, the high showing of AllocSetReset in your profile suggests to me
that you're timing an assert-enabled build, which wouldn't exactly be
a fair comparison to an Oracle production build anyhow.
Ops... forgot to remove it from other test. It seems much better but far from
On Sep 23, 2009, at 5:27 PM, Andrew Gierth wrote:
I intentionally avoided hstore_to_array because it would be unclear
which one it meant (the 1-d or 2-d result).
Thanks Andrew.
Given these replies, unless anyone else wants to weigh in on the array
conversion operator and function names,
2009/9/24 Euler Taveira de Oliveira eu...@timbira.com:
Hi,
I recently saw a complaint that a simple PL/PgSQL code is slower than PL/SQL.
I did some benchmark and confirmed it is. I coded the same function
(function2) in C just to compare with something. According to OP [1], the
PL/SQL seems
Euler == Euler Taveira de Oliveira eu...@timbira.com writes:
Euler Ops... forgot to remove it from other test. It seems much
Euler better but far from the ideal. :( I've never taken a look at
Euler the pl/pgsql code but it could be nice if there would be two
Euler path codes: access-data and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Sep 24, 2009 at 09:42:32PM +0300, Peter Eisentraut wrote:
On Wed, 2009-09-23 at 22:46 +0300, Marko Kreen wrote:
[...]
Good idea. This could also check for other invalid things like
byte-order marks in UTF-8.
But watch out. Microsoft
49 matches
Mail list logo
