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
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:
> > 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
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
> > ...
> >
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
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
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:
> 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
[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-
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
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
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
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
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).
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
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
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
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
=?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
[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
"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
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
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
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)
>
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
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 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
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
[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
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
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.
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
"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
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
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
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
--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
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?
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
--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
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,
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:
> 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
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 *
--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
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 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
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
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
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
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
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]>
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
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
[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
--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
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
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
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 ...
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
"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
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
"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
--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
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
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
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
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
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
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
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'
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.
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
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
"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
"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
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
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,
78 matches
Mail list logo
