On Thu, 2009-09-24 at 20:36 -0400, Tom Lane wrote:
> BTW, are port numbers still limited to 16 bits in IPv6?
Port numbers are in TCP, not in IP.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-h
On Wed, 2009-09-23 at 10:58 -0700, Josh Berkus wrote:
> So, while some people have asserted that a lock_timeout GUC would
> allow
> users to retrofit older applications to time out on locks, I just
> don't
> see that being the case. You'd have to refactor regardless, and if
> you're going to, just
On 25 sep 2009, at 02.59, Tom Lane wrote:
Sam Mason 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 b
-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 a
> "Euler" == Euler Taveira de Oliveira 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 non-ac
2009/9/24 Euler Taveira de Oliveira :
> 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
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, thi
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 f
On Mon, Sep 14, 2009 at 4:14 PM, Tom Lane wrote:
> Magnus Hagander 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 made
> a case why we should chan
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 wrote:
Here is a new version of error logging and autopartitioning in C
On Fri, Sep 18, 2009 at 12:14 AM, Emmanuel Cecchet 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 to previous v
On Tue, Sep 15, 2009 at 2:18 PM, Alvaro Herrera
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 further. And GUCs real
On Thu, Sep 24, 2009 at 8:59 PM, Tom Lane wrote:
> Sam Mason 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 privilege
On Thu, 24 Sep 2009, Tom Lane wrote:
Sam Mason 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 firewall
(or ssh tunn
Tom Lane wrote:
> Sam Mason 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
Sam Mason 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 root-owned
processes and
On Thu, Sep 24, 2009 at 8:36 PM, Tom Lane 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:
http://www.postgresql.org/mailpref/pgsql-hackers
Sam Mason 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 change.
> The incl
Magnus Hagander wrote:
> On Mon, Sep 21, 2009 at 20:12, Stef Walter 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: unresolved external sym
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.
- Notificatio
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
t
Euler Taveira de Oliveira 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 more than 15x fa
Tom Lane escribió:
> Gurjeet Singh writes:
> > ON instead of second ALTER looks better, and IMHO DATABASE should
> > be optional too:
>
> > ALTER ROLE [ON DATABASE ] SET TO ;
>
> IN, not ON.
This creates a parser conflict with
CREATE ROLE foo IN ROLE bar
I think it can be solved by splittin
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=# sel
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 characters
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
> If it could be done with a small 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:
http://www.postgresq
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,
>
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 necessar
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 n
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 of
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
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
On Thu, Sep 24, 2009 at 6:16 PM, Hannu Krosing 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 thr
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 anything
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,
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
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 tes
Fujii Masao wrote:
> On Thu, Sep 24, 2009 at 7:41 PM, Heikki Linnakangas
> 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 time for r
Fujii Masao wrote:
> On Mon, Sep 21, 2009 at 4:51 PM, Heikki Linnakangas
> 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 a command-line argument)
>
Hi,
On Thu, Sep 24, 2009 at 7:41 PM, Heikki Linnakangas
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 time for replication in synchron
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 A
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 ha
Hi,
On Mon, Sep 21, 2009 at 4:51 PM, Heikki Linnakangas
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 such a flag. I
> reworked that l
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=# crea
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 sub
Hi,
On Mon, Sep 21, 2009 at 1:55 AM, Heikki Linnakangas
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 according to it. It's confusing that
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 oo
Hi,
Sorry for the delay.
On Mon, Sep 21, 2009 at 4:51 PM, Heikki Linnakangas
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 walreceiver should indeed be a
>
49 matches
Mail list logo
