Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Another problem is that the CREATE FUNCTION syntax doesn't insist on any
>> particular ordering of the attributes;
>>
> This is so at the moment, while all samples use AS LANGUAGE. This
> could stay free format if quoted as usual
"Peter Eisentraut" <[EMAIL PROTECTED]> wrote:
> Reentrancy is (usually) a property of the interface (hence *_r functions
> with differing interfaces), thread-safety is a feature of the
> implementation;
May I not agree with this definition ?
Reentrancy is a property of the implemention that
assu
Am Dienstag, 2. September 2003 02:30 schrieb Andrew Dunstan:
> Quick fix is probably to turn IPv6 off in the kernel unless it's needed
> - on my RH box that is as simple as removing a line from
> /etc/sysconfig/network and rebooting
>
Quick fix is to put the right IPv6-adresses into pg_hba.conf,
"Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> Mendola Gaetano wrote:
> > "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> > > Gaetano Mendola wrote:
> > > > "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> > > > > I see other strdup() calls that don't check on a return. Should
we
> > deal
> > > > > with th
Tommi Mäkitalo wrote:
Hi,
that worked for localhost. For remote connections I added:
host all all :::192.168.41.0/120trust
and it worked also (I guessed it - I don't know much about IPv6). Is there any
chance to get it work like 7.3? It is no nice experienc
Hi,
that worked for localhost. For remote connections I added:
host all all :::192.168.41.0/120trust
and it worked also (I guessed it - I don't know much about IPv6). Is there any
chance to get it work like 7.3? It is no nice experience for new users.
Tomm
Tom Lane writes:
> This statement is simply false. A platform can build thread-safe
> versions of those "unsafe" APIs if it makes the return values point
> to thread-local storage. Some BSDs do it that way. Accordingly, any
> simplistic "we must have _r to be thread-safe" approach is incorrect.
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Why not regard anything between "AS" and LANGUAGE as source?
That seems quite impractical, considering that the function body may be
in a language that has little in common with SQL even at the lexical
level. The SQL parser couldn'
Greg Stark writes:
> Um. I don't think that's true. I mean, in theory it's true, but in practice
> why would an OS have some *_r but have only non-thread-safe versions of
> others?
The question is whether configure can reliably identify whether various
*_r functions exist. I think it can't. For
Tommi =?iso-8859-15?q?M=E4kitalo?= <[EMAIL PROTECTED]> writes:
> It's a SuSE Linux 8.2-box with the original 2.4.20-kernel.
> I get the same error when setting PGHOST to localhost, the real hostname or
> the IP-adress of the box. It has nothing to do with the resolver I think.
Hm. I assume thing
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
> > APIs. They can never be made thread-safe. The *_r versions of these functions
> > are standardized and required. If they don't exist then
Pavel Stehule <[EMAIL PROTECTED]> writes:
> Array and array's functions works fine, but I need call this function
> with empty array. I can't use array constructor for empty array.
Yeah. We have not figured out how to assign a type to "ARRAY[]".
You can do something like '{}'::integer[], however
Greg Stark <[EMAIL PROTECTED]> writes:
> On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
> APIs. They can never be made thread-safe. The *_r versions of these functions
> are standardized and required. If they don't exist then the platform simply
> does not support thread
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> If multiple inserters failed to split, the index might still be overfull,
>> but eventually, the index will not be overfull and split attempts will stop.
> If one backend is executing a query but the client has paused
--On Monday, September 01, 2003 22:02:00 +0100 Lee Kindness
<[EMAIL PROTECTED]> wrote:
"Larry Rosenman" <[EMAIL PROTECTED]> writes:
then how do we *PROVE* thread-safety on a particular platform?
You're not going to be able to prove it anyway!
which is my point.
L.
--
Larry Rosenman
"Larry Rosenman" <[EMAIL PROTECTED]> writes:
> then how do we *PROVE* thread-safety on a particular platform?
You're not going to be able to prove it anyway!
L.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
htt
It's a SuSE Linux 8.2-box with the original 2.4.20-kernel.
I get the same error when setting PGHOST to localhost, the real hostname or
the IP-adress of the box. It has nothing to do with the resolver I think.
Tommi Mäkitalo
Am Montag, 1. September 2003 22:49 schrieb Tom Lane:
> Tommi =?iso-8859
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > Guys, too much thought is being spent on this...
> > 1. For the _r functions we "need" we should ALWAYS use them if the
> > system we are building on has them - they WILL be thread-safe.
>
> > 2. If the system is
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Why not regard anything between "AS" and LANGUAGE as source?
That seems quite impractical, considering that the function body may be
in a language that has little in common with SQL even at the lexical
level. The SQL parser couldn't even tell what was a
Tommi =?iso-8859-15?q?M=E4kitalo?= <[EMAIL PROTECTED]> writes:
> psql: FATAL: no pg_hba.conf entry for host ":::127.0.0.1", user
> "postgres", database "template1"
What platform is this?
It sounds to me like your system is resolving "localhost" as an IPv6
address ...
Johan Henselmans <[EMAIL PROTECTED]> writes:
> [ odd problems with gcc 3.3 ]
That seems strange. We've not heard other reports of trouble with
gcc 3.3.
> I did however, encounter a problem with the supplied initdb. It seems
> that the test of the of shared memory segment is not used in the res
Hi, I have just subscribed to the hackers mailinglist to telll what my
adventures are with 7.4.b2 and OS X so far.
I have encountered some problems, and have some solutions, off which I
do not know if they break the port, or do something wrong.
gcc3.3
=
First, gcc3.3 on 10.2.x and 10.3.x
--On Monday, September 01, 2003 16:01:16 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Lee Kindness <[EMAIL PROTECTED]> writes:
Guys, too much thought is being spent on this...
1. For the _r functions we "need" we should ALWAYS use them if the
system we are building on has them - they WILL be threa
[EMAIL PROTECTED] writes:
> I've made some tests with your qsort and it DEFINITIVLY help
> ~3 mn instead of 69.
> However this is for 7.3.4 I've got no probs with 7.4b.
> Did something change in btree creation?
Hmm, I wouldn't have thought so, but perhaps we did change something
that would affect
Lee Kindness <[EMAIL PROTECTED]> writes:
> Guys, too much thought is being spent on this...
> 1. For the _r functions we "need" we should ALWAYS use them if the
> system we are building on has them - they WILL be thread-safe.
> 2. If the system is missing a _r function then we implement a wrapper
Hi,
I tried 7.4 beta2 and had difficulties setting up TCP/IP with it. It complains
about mising pg_hba.conf-entry.
After installing and initdb I edited my postgres.conf to enable tcpip
(tcpip_socket = true) and added a pg_hba.conf-entry like this:
local all all
Hi Tom,
I've made some tests with your qsort and it DEFINITIVLY help
~3 mn instead of 69.
However this is for 7.3.4 I've got no probs with 7.4b.
Did something change in btree creation?
On Mon, 1 Sep 2003, Tom Lane wrote:
> Date: Mon, 01 Sep 2003 08:46:09 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
Tom Lane kirjutas E, 01.09.2003 kell 15:41:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I know someone reported a problem with the hash indexes (data loss,
> > serious)--- was that a new 7.4 but or something that has existed for a
> > long time?
>
> AFAICT the bug's been there since Berkeley d
Tom Lane writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Given that rbt is the owner of the object, I'm not sure that it is
> >> sensible to interpret the above as revoking his ability to grant
> >> privileges to others.
> >>
> >> Peter, any thoughts?
>
> > Has this be
Pavel Stehule wrote:
CREATE FUNCTION foo(date, date, INTEGER[]) RETURNS INTEGER
Array and array's functions works fine, but I need call this function
with empty array. I can't use array constructor for empty array. When
I call function foo with e.a. ,I get syntax error. I can call with '{}'.
Ar
On Mon, Sep 01, 2003 at 18:16:25 +0100,
Lee Kindness <[EMAIL PROTECTED]> wrote:
>
> Was Bruce planning to do the PITR work? If so I guess a lot of his
> time's been spent on integrating patches and the like - leaving less
> time for other developments.
Bruce was working on the WIN32 port. That
On Mon, 1 Sep 2003, Bruce Momjian wrote:
> Pavel Stehule wrote:
> > Hello
> >
> > I have function
> >
> > CREATE FUNCTION foo(date, date, INTEGER[]) RETURNS INTEGER
> >
> > Array and array's functions works fine, but I need call this function
> > with empty array. I can't use array construc
Guys, too much thought is being spent on this...
1. For the _r functions we "need" we should ALWAYS use them if the
system we are building on has them - they WILL be thread-safe.
2. If the system is missing a _r function then we implement a wrapper
to call the normal non-_r version. However we do
--On Monday, September 01, 2003 14:24:14 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
On Mon, 1 Sep 2003, Bruce Momjian wrote:
Larry Rosenman wrote:
>
>
> --On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> >
> >> Um. I don't think that's true
On Mon, 1 Sep 2003, Bruce Momjian wrote:
> Larry Rosenman wrote:
> >
> >
> > --On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
> > <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >> Um. I don't think that's true. I mean, in theory it's true, but in
> > >> practice why would an OS have some *
Bruce Momjian <[EMAIL PROTECTED]> writes:
> If all the code changes are only in the
> hash indexes, and they are known to be buggy, maybe we should just give
> it a shot for 7.4 knowing it probably can't get worse than it already
> is (but it could).
That's basically my opinion. It's unlikely to
Probably because I worked on thread safety and produced a patch. If
someone done the same for PITR and produced a patch i'm sure it would
have generated much more interest. I couldn't have done PITR, so no
loss of resource there.
Was Bruce planning to do the PITR work? If so I guess a lot of his
t
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> What I don't like about this scheme is that it requires mods on both the
>> backend and client sides, to solve a problem that could be solved as
>> well or better (and definitely more simply) on the client side alone.
> backend returns something saying,
--On Monday, September 01, 2003 13:11:25 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
--On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>
>> Um. I don't think that's true. I mean, in theory it's true, but in
>> practice why would a
I seen on this list a lot of energy ( also little flames involving SCO
& Co. ) spent on thread safety;
was really necessary spent so much energy in this direction?
I was at Fosdem in Bruxelles ( I spoke there about the use
of postgres in my project ) and I seen al people there
was really exicited
Larry Rosenman wrote:
>
>
> --On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> >
> >> Um. I don't think that's true. I mean, in theory it's true, but in
> >> practice why would an OS have some *_r but have only non-thread-safe
> >> versions of others?
--On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Um. I don't think that's true. I mean, in theory it's true, but in
practice why would an OS have some *_r but have only non-thread-safe
versions of others?
Oh, interesting. So you are saying that if the OS
Greg Stark wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > We could go down that road. The only other OS that needs *_r functions
> > is Linux, and it uses all *_r functions. How do we configure to throw
> > an error in that OS if we don't fined all of them? Maybe we need a
> > three-v
Mendola Gaetano wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> > Gaetano Mendola wrote:
> > > "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> > > > I see other strdup() calls that don't check on a return. Should we
> deal
> > > > with those too?
> > >
> > > Well strdup obtain the memory for th
Pavel Stehule wrote:
> Hello
>
> I have function
>
> CREATE FUNCTION foo(date, date, INTEGER[]) RETURNS INTEGER
>
> Array and array's functions works fine, but I need call this function
> with empty array. I can't use array constructor for empty array. When
> I call function foo with e.a. ,I
"Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> Gaetano Mendola wrote:
> > "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> > > I see other strdup() calls that don't check on a return. Should we
deal
> > > with those too?
> >
> > Well strdup obtain the memory for the new string using a malloc
> > and nor
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We could go down that road. The only other OS that needs *_r functions
> is Linux, and it uses all *_r functions. How do we configure to throw
> an error in that OS if we don't fined all of them? Maybe we need a
> three-valued variable instead of bool
Julian Mehnle wrote:
> Hi all,
>
> I found the item mentioned in the subject on the PostgreSQL TODO list[1],
> but it isn't marked for implementation for 7.4, so I'm wondering whether
> there is any somewhat concrete plan on when this will be implemented? 7.4?
> 7.5? 8.0?
>
> Thanks in advance.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I've been looking at fixing the problem reported a few days ago whereby
> >> a bucket split in a hash index messes up the state of concurrent scans
> >> of the index, possibly causing some tuples to be missed by th
[EMAIL PROTECTED] wrote:
> On Sun, 31 Aug 2003, Bruce Momjian wrote:
>
> > Date: Sun, 31 Aug 2003 21:51:02 -0400 (EDT)
> > From: Bruce Momjian <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Cc: pgsql-hackers list <[EMAIL PROTECTED]>
> > Subject: Re: [HACKERS] pg_dump bug?
> >
> > [EMAIL PROTECT
Greg Stark wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>
> > Lee Kindness writes:
> >
> > > You don't... and you simply shouldn't care. If there is a_r version
> > > available then we should use it - even if the plain version is "safe".
> >
> > The problem with this is that the automat
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Let me jump in --- there is the issue of how to prevent the backend from
> > running the query through the lexer/parser. The cleanest idea presented
> > was:
> > [snip]
>
> That's the same idea that was being discussed in this thread
Hello
I have function
CREATE FUNCTION foo(date, date, INTEGER[]) RETURNS INTEGER
Array and array's functions works fine, but I need call this function
with empty array. I can't use array constructor for empty array. When
I call function foo with e.a. ,I get syntax error. I can call with '{}'
Tom Lane <[EMAIL PROTECTED]> writes:
> If multiple inserters failed to split, the index might still be overfull,
> but eventually, the index will not be overfull and split attempts will stop.
> (We could make a successful splitter loop to see if the index is still
> overfull, but I think I prefer
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Lee Kindness writes:
>
> > You don't... and you simply shouldn't care. If there is a_r version
> > available then we should use it - even if the plain version is "safe".
>
> The problem with this is that the automatic determination (in configure)
>
These approaches are to some extent orthogonal, ISTM. Maybe the best
solution would be to do as Tom suggests and just change psql (and, I
would add, pg_dump) to act nicely here, and if other interface
users/authors need/want something along these lines re-examine the
issue. I use JDBC for my
Tom Lane wrote:
What I don't like about this scheme is that it requires mods on both the
backend and client sides, to solve a problem that could be solved as
well or better (and definitely more simply) on the client side alone.
People are being misled by considering only psql, which is so stupid
t
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> > I can hardly imagine that the backend started working with 9mb of
> > memory. what did you do that PostgreSQL needed so much memory from the
> > beginning???
>
> On some platforms, "t
[EMAIL PROTECTED] writes:
> it took 69 minutes to finish, 75% of this time was devoted to create 2
> indexes on varchar(2) with value being 'O', 'N' or null;
> I wonder if it's a configuration matter.
I still say it's either strcoll or qsort's fault. Try swapping in our
own version of qsort to se
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> I can hardly imagine that the backend started working with 9mb of
> memory. what did you do that PostgreSQL needed so much memory from the
> beginning???
On some platforms, "top" seems to count the Postgres shared memory bloc
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I've been looking at fixing the problem reported a few days ago whereby
>> a bucket split in a hash index messes up the state of concurrent scans
>> of the index, possibly causing some tuples to be missed by the scans.
> Seems you are
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Let me jump in --- there is the issue of how to prevent the backend from
> running the query through the lexer/parser. The cleanest idea presented
> was:
> [snip]
That's the same idea that was being discussed in this thread. I was
trying to remind peop
On Sun, 31 Aug 2003, Bruce Momjian wrote:
> Date: Sun, 31 Aug 2003 21:51:02 -0400 (EDT)
> From: Bruce Momjian <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] pg_dump bug?
>
> [EMAIL PROTECTED] wrote:
> > Hi all,
> >
> > This is on 7
Tom,
Let me come back on this one:
I initdb --locale=C and reloaded all bases including this one. Index
creation wassn't too bad. So I thought that was it.
Yesturday evening I decided to make a test so I pg_dump'd that database,
created a test db and reloaded evrything from the pg_dump.
it took 6
Hans-Jürgen Schönig wrote:
I can hardly imagine that the backend started working with 9mb of
memory. what did you do that PostgreSQL needed so much memory from the
beginning??? are you using the default settings? usually the
postmaster does not need more than 3mb at startup (in this scenario).
Hi all,
I found the item mentioned in the subject on the PostgreSQL TODO list[1],
but it isn't marked for implementation for 7.4, so I'm wondering whether
there is any somewhat concrete plan on when this will be implemented? 7.4?
7.5? 8.0?
Thanks in advance.
[1] http://developer.postgresql.org
Andrew Dunstan wrote:
> It sends a SIGKILL (9) unless the process is doing raw io, in which case
> it sends SIGTERM (15). It can't really wait - at this stage the kernel
> is in trouble - it can either kill processes or panic. The whole idea of
> strict accounting is not to let it get to this st
Tom Lane wrote:
> I've been looking at fixing the problem reported a few days ago whereby
> a bucket split in a hash index messes up the state of concurrent scans
> of the index, possibly causing some tuples to be missed by the scans.
> AFAICS the only way to fix this is to prevent such a concurren
Bruce Momjian wrote:
Andrew Dunstan wrote:
I believe that the swap slot can be subsequently freed, though. In
theory your available virtual memory should be (almost) RAM+swap. In
practice, Linux can run too close to that limit, (or way over it if you
turn the checks off). But restricting t
[EMAIL PROTECTED] wrote:
> Hi all,
>
> This is on 7.3.4
> I had altered a user like this:
> alter user set search_path = shema1,public
>
> Then I had to pgdumpall, re-initdb and restore every thing.
>
> The alter user did'nt get through. and broke my app.
Yes, it seems pg_dump doesn't dump per-
Andrew Dunstan wrote:
> I believe that the swap slot can be subsequently freed, though. In
> theory your available virtual memory should be (almost) RAM+swap. In
> practice, Linux can run too close to that limit, (or way over it if you
> turn the checks off). But restricting the maximum possible
Kaare Rasmussen wrote:
> > It would be nice if we could configure a function to run on connection
> > start. We have the ability to SET values per db or user, but not to
>
> If my memory serves me well, Oracle has a number of system triggers. On
> database startup and shutdown and perhaps also o
Andrew Dunstan wrote:
> Bruce Momjian said:
> > Let me jump in --- there is the issue of how to prevent the backend
> > from running the query through the lexer/parser. The cleanest idea
> > presented was:
> >
> > >CREATE FUNCTION bob() RETURNS INTEGER AS stdin LANGUAGE 'plpgsql';
> > >BEG
Kurt Roeckx wrote:
> On Sun, Aug 31, 2003 at 12:04:58PM +0200, Peter Eisentraut wrote:
> > Lee Kindness writes:
> >
> > > You don't... and you simply shouldn't care. If there is a_r version
> > > available then we should use it - even if the plain version is "safe".
> >
> > The problem with this
Bruce Momjian said:
> Let me jump in --- there is the issue of how to prevent the backend
> from running the query through the lexer/parser. The cleanest idea
> presented was:
>
> >CREATE FUNCTION bob() RETURNS INTEGER AS stdin LANGUAGE 'plpgsql';
> >BEGIN
> > ...
> >
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > In that case, though, the solution will presumably look at least a bit
> > different from those discussed so far in this thread. Or would you have
> > psql detect that in place of a string there was "stdin" or whatever and
> > then
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> In that case, though, the solution will presumably look at least a bit
> different from those discussed so far in this thread. Or would you have
> psql detect that in place of a string there was "stdin" or whatever and
> then replace it with the inlin
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I'm also wondering why the backend need have anything at all to do with
an improved function-definition mode. If you look in the archives you
will see speculation about inventing psql backslash commands that woul
78 matches
Mail list logo
