Am Dienstag, 2. September 2003 17:24 schrieb Andrew Dunstan:
> *nod* but it would be nicer if all loopback interfaces worked by default
> - hence my localhost suggestion, which would match any of
>
> 127.0.0.1/32
>
> :::127.0.0.1/128 and
> ::1/128
>
> cheers
>
> andrew
>
...
That sounds g
Tom Lane wrote:
Weiping He <[EMAIL PROTECTED]> writes:
I've put the config.log on:
http://www.pgsqldb.org/config.log
configure:10847: cc -Ae -c +O2 -D_XOPEN_SOURCE_EXTENDED conftest.c >&5
(Bundled) cc: warning 480: The -A option is available only with the C/ANSI C product;
ignored.
Get a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hello
take a look at the HTML docs(found in postgres.tar.gz, in the source
tarball), and see functions-matching.html
Bye,
Gergely Czuczy
mailto: [EMAIL PROTECTED]
PGP pubkey: http://phoemix.harmless.hu/phoemix.pgp
iRCNet: #demoscene ICQ: 8067175
Hi guys,
Where can I find a list of all the 'special' characters in the ~* operator?
Thanks,
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Says that pg_get_triggerdef has no pretty print option. Is this actually
> true?
\df agrees. Right offhand I don't see much scope for prettyprinting in
CREATE TRIGGER ...
regards, tom lane
-
BTW, would it be possible to tweak configure's test for "minimum working
C compiler" to include a check that cc accepts ANSI-style function
prototypes? That would allow us to bounce HP's lame excuse for a free
compiler with a slightly useful message ...
regards, tom lane
Hi Guys,
This page:
http://developer.postgresql.org/docs/postgres/functions-misc.html
Says that pg_get_triggerdef has no pretty print option. Is this actually
true?
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Weiping He <[EMAIL PROTECTED]> writes:
> I've put the config.log on:
> http://www.pgsqldb.org/config.log
configure:10847: cc -Ae -c +O2 -D_XOPEN_SOURCE_EXTENDED conftest.c >&5
(Bundled) cc: warning 480: The -A option is available only with the C/ANSI C product;
ignored.
Get a real compiler :-(
Tom Lane wrote:
Weiping He <[EMAIL PROTECTED]> writes:
Check the config.log, it said that the configure script can't find the
argument types
fo 'accept()'.
Could you show us the relevant section of config.log, instead of giving
a summary with no details? I'd like to see the compiler er
> 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).
On FreeBSD, every one
I am seeing a slow but steady growth of the backend process on a Linux
box (RHL 8.0) --- top shows it growing a few K every few seconds.
But I see *zero* growth with the same test on HPUX 10.20.
A possible wild card is that the Postgres build I'm using on the Linux
box is compiled for profiling (-
This is the Pg backend line from top after about 90 minutes runtime :
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
16083 postgres 17 0 9172 9172 8524 R 94.7 2.4 84:59.68 postmaster
No sign of the shared growth stopping at this stage...
Pg built with --disable-debug --w
> In fact, I like the criterion that a warning should be raised rather than
> a notice if the effect of the command deviates from what the command
> actually says. That puts the messages for serials, primary keys, drop
> cascades clearly into notices, messages about missing, implicitly added,
> or
So far as I'm aware Joerg, we didn't have enough time to get all the Win32
stuff done for 7.4, and it was felt (rightly so) that it wasn't worth
holding off on 7.4 to get it in.
At the moment, the main developers are doing nothing but fixing bugs in 7.4
as we are now in feature freeze.
Once 7.4 f
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I found following mail in my mail archive and tried the same test with
> 7.4 current. Contrary to my expectation 7.4 showed some performance
> degration with continuous pgbench runs:
I did some profiling and found that with repeated runs, an increasing
a
Darko Prenosil wrote:
Current bcc32.mak produces :
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
Error: Unresolved external '_pqGethostbyname' referenced from
D:\POSTGRESQL-7.4BETA2\SRC\INTERFACES\LIBPQ\RELEASE\BLIBPQ.LIB|getaddrinfo
Error: Unresolved external '_pqStrerror' referen
--On Tuesday, September 02, 2003 18:32:03 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
>> >> Bruce Momjian writes:
>> >> > Right. We can't assume because a *_r function is missing that
>> >> > the normal function is thread-safe.
>> >
>> >> That's not our concern - if
Larry Rosenman wrote:
> >> >> Bruce Momjian writes:
> >> >> > Right. We can't assume because a *_r function is missing that the
> >> >> > normal function is thread-safe.
> >> >
> >> >> That's not our concern - if the OS isn't thread safe we can't do
> >> >> anything about it, and to worry about
Current bcc32.mak produces :
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
Error: Unresolved external '_pqGethostbyname' referenced from
D:\POSTGRESQL-7.4BETA2\SRC\INTERFACES\LIBPQ\RELEASE\BLIBPQ.LIB|getaddrinfo
Error: Unresolved external '_pqStrerror' referenced from
D:\POSTGRESQL-
Marc G. Fournier wrote:
'k ... quick and dirty summary .. Bruce will probably add to it, but I
know he's busy ... he's so busy that some of the stuff that we put in
place for the Win32 hasn't even been announced yet :)
First, there was a branch created a couple of weeks ago: WIN32_DEV tha
--On Tuesday, September 02, 2003 18:12:48 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
--On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
> Lee Kindness writes:
>
>> Bruce Momjian writes:
>> > Right. We can't assume because a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> In fact, I like the criterion that a warning should be raised rather than
> a notice if the effect of the command deviates from what the command
> actually says.
Um. If I construe that literally, then the notices about identifier
truncation need to b
'k ... quick and dirty summary .. Bruce will probably add to it, but I
know he's busy ... he's so busy that some of the stuff that we put in
place for the Win32 hasn't even been announced yet :)
First, there was a branch created a couple of weeks ago: WIN32_DEV that
you can access via anon cvs ..
Larry Rosenman wrote:
>
>
> --On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
> <[EMAIL PROTECTED]> wrote:
>
> > Lee Kindness writes:
> >
> >> Bruce Momjian writes:
> >> > Right. We can't assume because a *_r function is missing that the
> >> > normal function is thread-safe.
Tom Lane writes:
> I would say that NOTICEs are things that are routine in certain
> contexts. We would not bother with the NOTICE at all if we thought
> it held no interest, but often it doesn't have any.
>
> Ignored syntax clauses probably ought to be WARNINGs, since the message
> is telling yo
Lee Kindness wrote:
> Bruce Momjian writes:
> > Lee Kindness wrote:
> > > No, it's not. Using the _r functions on such systems is BETTER because
> > > the API is clean and the function can be implmented in a reentrant and
> > > thread-safe fashion wuithout the need for thread local storage or
>
Joerg Hessdoerfer kirjutas T, 02.09.2003 kell 13:30:
> Hi!
>
> After holding my breath for quite a while, it bursts out... I'd really like to
> get a status update on said port.
>
> The reason is, it's seemingly put on hold for me. After this port was talked
> over on the list, there seemed to
> I understand that ObjID of LOCKtag recognizes each individual row locked
by
> a row level lock. BUt i have noticed that if i lock 2 different rows of
the
> same table they have the same blkno. is this deduction ok?
If they happen to be stored in the same block, they'd have the same blkno
..
"Jenny -" <[EMAIL PROTECTED]> writes:
> I understand that ObjID of LOCKtag recognizes each individual row locked by
> a row level lock. BUt i have noticed that if i lock 2 different rows of the
> same table they have the same blkno. is this deduction ok?
If they happen to be stored in the same b
I understand that ObjID of LOCKtag recognizes each individual row locked by
a row level lock. BUt i have noticed that if i lock 2 different rows of the
same table they have the same blkno. is this deduction ok?
thanks
jenny
_
Get MS
--On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
Lee Kindness writes:
Bruce Momjian writes:
> Right. We can't assume because a *_r function is missing that the
> normal function is thread-safe.
That's not our concern - if the OS isn't thread safe
Lee Kindness writes:
> Bruce Momjian writes:
> > Right. We can't assume because a *_r function is missing that the
> > normal function is thread-safe.
> That's not our concern - if the OS isn't thread safe we can't do
> anything about it, and to worry about it is an enormous waste of
> develop
Samuel A Horwitz <[EMAIL PROTECTED]> writes:
> c/include -I/usr/local/ssl/include -c -o elog.o elog.c
> elog.c: In function `errcode_for_file_access':
> elog.c:546: duplicate case value
> elog.c:539: previously used here
> gmake[4]: *** [elog.o] Error 1
[ scratches head ... ] EEXIST and ENOTEMPT
Bruce Momjian writes:
> Lee Kindness wrote:
> > No, it's not. Using the _r functions on such systems is BETTER because
> > the API is clean and the function can be implmented in a reentrant and
> > thread-safe fashion wuithout the need for thread local storage or
> > mutex locking.
> I don't
Bruce Momjian writes:
> Right. We can't assume because a *_r function is missing that the
> normal function is thread-safe.
I recon i'll get blue in the face before long, and one of you guys
will fly over to Scotland to give me a good kicking!... But'll say it
again anyway...
That's not our co
I am still getting the duplicate case value problem trying to compile the
CVS head on AIX 4.2.1.
gmake[4]: Entering directory
`/usr/local/postgres/pgsql/src/backend/utils/error'
gcc -O2 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../../sr
c/include -I/usr/local/ssl/include -c
Czuczy Gergely <[EMAIL PROTECTED]> writes:
> the code is this:
> text *src;
> void *tmp;
> src = (text*)tmp;
> and the error message:
> error: parse error before `)' token
> (at (text*_)_)
The only thing that comes to mind is you've got "text" defined as a
macro, or some other meaning besid
--On Tuesday, September 02, 2003 11:35:25 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
--On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
> Peter Eisentraut wrote:
>> Lee Kindness writes:
>>
>> > You don't... and you simply shouldn
Larry Rosenman wrote:
>
>
> --On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> > 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 -
--On Tuesday, September 02, 2003 11:32:08 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
> Where does it say that you have to use getpwuid_r() to be thread safe?
> I don't see any mention in the docs. It does say about getpwuid:
>
> For getpwent, getpwuid, getpwnam,
Larry Rosenman wrote:
> > Where does it say that you have to use getpwuid_r() to be thread safe?
> > I don't see any mention in the docs. It does say about getpwuid:
> >
> > For getpwent, getpwuid, getpwnam, setpwent, endpwent, and
> > fgetpwent, all information is contained in a static
--On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
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
*nod* but it would be nicer if all loopback interfaces worked by default
- hence my localhost suggestion, which would match any of
127.0.0.1/32
:::127.0.0.1/128 and
::1/128
cheers
andrew
Andreas Pflug wrote:
Tommi Maekitalo wrote:
Hi,
I doublechecked, that the patch applied. And there
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 is that the automatic determination (in configure)
> whether there is a xxx
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hello
i only have to fetch the procedure's arguments and return the proper
value. this is the only part where i basically use the pgsql's functions,
the function's task is only some calculations, and to speed up things. in
C its _much_ faster than in
Lee Kindness wrote:
> Tom Lane 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
Forgot to mention an important thing: I set enable_seqscan = off in
postgresql.conf.
> I found following mail in my mail archive and tried the same test with
> 7.4 current. Contrary to my expectation 7.4 showed some performance
> degration with continuous pgbench runs:
>
> $ pgbench -c 5 -t 1000
On Tue, Sep 02, 2003 at 04:09:26PM +0200, Czuczy Gergely wrote:
>
> libpq++ is not gone, i just don't like it. I've written an other C++ API
> for databse systems, name SDBI, but i cannot use it for a stored procedure
> :)
I've never looked at writing native stored procedures, but do you think
th
I found following mail in my mail archive and tried the same test with
7.4 current. Contrary to my expectation 7.4 showed some performance
degration with continuous pgbench runs:
$ pgbench -c 5 -t 1000 -n test
tps = 57.444037 (including connections establishing)
tps = 57.455300 (excluding connect
Hi,
I think this would be interesting for many postgresql users.
The opensource database market is moving where quick at the moment, see
the sh*t with sapdb and mysql. So it would be very interesting if there
is a free alternative for windows and linux in the near future, because
some customers s
I've found a number of infelicities in the hash index code that can't be
fixed without an on-disk format change. The biggest one is that the
hashm_ntuples field in hash meta pages is only uint32, meaning that
hash index space management will become confused if the number of
entries exceeds 4G. I
In the LockTag if tupleId is represented by blkno and offnum then is blockId
mentioned below the same as blkno?
following is taken from postgresql-7.3.2/src/backend/storage/lmgr/readme:
"If we are setting a table level lock
both the blockId and tupleId (in an item pointer this is called
Tommi Maekitalo wrote:
Hi,
I doublechecked, that the patch applied. And there is a change. It workes for
connections from remote or to the ethernet-address, but not to localhost:
[EMAIL PROTECTED]:~ > export PGHOST=localhost
[EMAIL PROTECTED]:~ > psql -l
psql: FATAL: no pg_hba.conf entry for h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hello
once again :)
the code is this:
text *src;
void *tmp;
src = (text*)tmp;
and the error message:
error: parse error before `)' token
(at (text*_)_)
originally i've tried to use the macro PG_GETARG_TEXT_P(0), but when i've
got this message,
Weiping He <[EMAIL PROTECTED]> writes:
> Check the config.log, it said that the configure script can't find the
> argument types
> fo 'accept()'.
Could you show us the relevant section of config.log, instead of giving
a summary with no details? I'd like to see the compiler error messages
and fai
Hi,
I doublechecked, that the patch applied. And there is a change. It workes for
connections from remote or to the ethernet-address, but not to localhost:
[EMAIL PROTECTED]:~ > export PGHOST=localhost
[EMAIL PROTECTED]:~ > psql -l
psql: FATAL: no pg_hba.conf entry for host "::1", user "postgre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hello
thanks to Andreas Pflug's hint, it's now working, thank you.
libpq++ is not gone, i just don't like it. I've written an other C++ API
for databse systems, name SDBI, but i cannot use it for a stored procedure
:)
thanks
Bye,
Gergely Czuczy
ma
On Tue, 2 Sep 2003, Shridhar Daithankar wrote:
> On 2 Sep 2003 at 15:50, Czuczy Gergely wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > i'm using pgsql 7.3.4.
> > how can I fix it? i think so, i should modify the header files, i've tried
> > to put it into an ``extern "C" {...}'' block, but i
Czuczy Gergely wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hello
i've tried to write a stored function in C++, using the libpq library, but
the g++(3.3.1) was unable to pass through the headers. there are a lot's
of reserved words used in structs as member names, such as delete,using,
na
Tommi Maekitalo wrote:
Hi,
the patch did not help.
Strange. Do you get a client side message "hba.conf entry for
::.127.0.0.1 missing"?
On my system the usual 127.0.0.1 255.255.255.255 is correctly converted to
:::127.0.0.1 ::::::255.255.255.255 and works
fine.
hello
as i said, i've tried to put into into an extern "C" statement, but it
didn't solve anything
Bye,
Gergely Czuczy
mailto: [EMAIL PROTECTED]
PGP pubkey: http://phoemix.harmless.hu/phoemix.pgp
iRCNet: #demoscene ICQ: 8067175
The point is, that geeks are not necessarily the outcasts
society
On 2 Sep 2003 at 15:50, Czuczy Gergely wrote:
> -BEGIN PGP SIGNED MESSAGE-
> i'm using pgsql 7.3.4.
> how can I fix it? i think so, i should modify the header files, i've tried
> to put it into an ``extern "C" {...}'' block, but i didn't solve anything.
Try putting extern C, around includ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hello
i've tried to write a stored function in C++, using the libpq library, but
the g++(3.3.1) was unable to pass through the headers. there are a lot's
of reserved words used in structs as member names, such as delete,using,
namespace, and so on.
i
Hi,
the patch did not help.
Maybe it would help dumping all pg_hba.conf-etries after generation of
IPv6-adresses.
But there is another problem, which is related. I get a logentry:
LOG: could not bind IPv4 socket: Die Adresse wird bereits verwendet
Sorry - I have errormessages in german - I
I can
select foo('{}'::int4[]) -- ok
select foo('{}') -- ok too
but
select foo(array[]) -- syntax error,
my function can by like
Correct -- you cannot use the ARRAY constructor empty. If you need an
empty array, use '{}'. Search the archives for previous discussions on
this t
On Mon, 1 Sep 2003, jconway wrote:
>
> You haven't shown us your function or how you're trying to call it. In
> any case, works here:
>
> regression=# CREATE FUNCTION foo(INTEGER[], INTEGER) RETURNS INTEGER AS
> 'select ss.f[1] from (select $1 || $2 as f) as ss' language sql;
> CREATE FUNCTION
>
--On Tuesday, September 02, 2003 00:04:35 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
>> > Oh, interesting. So you are saying that if the OS supports threads,
>> > then we use the *_r if they have them, and assume the non *_r
>> > functions are already thread-safe if t
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Can we allow the IPv6 entries to be in pg_hba.conf but ignore them on
non-IPv6 machines, or allow the connection to fail?
I don't see a good way yet. The fly in the ointment is that HAVE_IPV6
is set by configure based on the capa
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
How about silently creating a IPV6 style host internally for every IPV4
pg_hba.conf entry? It won't make any sense to handle a real IPV4 address
different from an IPV4 address converted to IPV6 address space.
Hmm. I could go for
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I thought it was a case of Bruce not having time to work on them, because he
> was too busy doing patch application and stuff.
Bruce would probably be the right person to opine on this, but my
impression is that patch application is just a ti
> committing a major patch isn't to difficult ... its getting the major
> patch created that is ... PITR and Win32 don't exist in v7.4 because no
> patch was submit'd, not because Bruce didn't have time to commit them ...
I thought it was a case of Bruce not having time to work on them, because he
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can we allow the IPv6 entries to be in pg_hba.conf but ignore them on
> non-IPv6 machines, or allow the connection to fail?
I don't see a good way yet. The fly in the ointment is that HAVE_IPV6
is set by configure based on the capabilities of userland l
Larry Rosenman wrote:
> >> > Oh, interesting. So you are saying that if the OS supports threads,
> >> > then we use the *_r if they have them, and assume the non *_r functions
> >> > are already thread-safe if they don't. Interesting.
> >> >
> >> > That seems to be what we have on Unixware, and o
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Ouch --- everything is IPv6. Wow, that is unusual. I assumed that
> > folks who have OS's that do that will put IPv6 addresses in pg_hba.conf.
>
> I think that may be reasonable. What bothers me is that the default
> pg_hba.conf wi
Lee Kindness writes:
> Tom Lane 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 th
On Tue, 2 Sep 2003 03:06 am, Mendola Gaetano wrote:
> May be I'm wrong but I'd like know why thread safety was so
> necessary.
It bugged Lee enough that he went and wrote a patch for it. It bugged me
enough that I couldn't use it on our choice of platform (older Linux) that I
did some little fix
On Tue, 2 Sep 2003, postgresql wrote:
> Hi all
> Can anyone tell me the approximate pg 7.5 release date?
Summer of '04 ... approximate :)
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Ouch --- everything is IPv6. Wow, that is unusual. I assumed that
> folks who have OS's that do that will put IPv6 addresses in pg_hba.conf.
I think that may be reasonable. What bothers me is that the default
pg_hba.conf will fail to accept localhost
Hi!
After holding my breath for quite a while, it bursts out... I'd really like to
get a status update on said port.
The reason is, it's seemingly put on hold for me. After this port was talked
over on the list, there seemed to be an explosion of effort, with initial
success stories. I did re
Hi all
Can anyone tell me the approximate pg 7.5 release date?
Thanks
Josh
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Johan Henselmans wrote:
> 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
> =
Andreas Pflug wrote:
> 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
committing a major patch isn't to difficult ... its getting the major
patch created that is ... PITR and Win32 don't exist in v7.4 because no
patch was submit'd, not because Bruce didn't have time to commit them ...
On Tue, 2 Sep 2003, Christopher Kings-Lynne wrote:
> Maybe to free up Bruce for
Mendola Gaetano wrote:
> 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
Mendola Gaetano wrote:
> 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
Marc G. Fournier wrote:
>
>
> On Mon, 1 Sep 2003, Peter Eisentraut wrote:
>
> > 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 questio
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Frontends would not be forced to use something that triggered this -
> after all we have to stay backwards compatible and support the existing
> inline string, no?
Certainly. I didn't see anyone proposing to break backwards
compatibility.
Andreas Pflug <[EMAIL PROTECTED]> writes:
> How about silently creating a IPV6 style host internally for every IPV4
> pg_hba.conf entry? It won't make any sense to handle a real IPV4 address
> different from an IPV4 address converted to IPV6 address space.
Hmm. I could go for that, if it weren'
Andreas Pflug <[EMAIL PROTECTED]> writes:
> But we're not talking about psql only (and \beginlit and \endlit are
> quite ugly sql keywords), and this should be a backend thing only
I disagree with both of those assertions. psql is the issue because
other clients used for administrative work (pgA
Maybe to free up Bruce for major patches (eg. PITR, etc.), we should promote
someone else to 'minor patch' committer?
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's d
When trying to build the CVS source on a HP-UX 11.00 box:
HP-UX hpux B.11.00 A 9000/800
We got the configure error:
checking types of arguments for accept()... configure: error: could not
determine argument types
Check the config.log, it said that the configure script can't find the
argument t
Tom Lane 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 the platform sim
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
Kurt Roeckx knows more about this than I do, but I know when I turned
IPv6 on I had to do something similar to what is below - I
Tom Lane wrote:
Tommi =?iso-8859-15?q?M=E4kitalo?= <[EMAIL PROTECTED]> writes:
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
Tom Lane wrote:
psql may indeed work with no changes, because it's too stupid to know
when you're defining a function, and so it would not be surprised to get
a Start Copy In back from a CREATE FUNCTION command. This would not be
true of nearly any other client that one might use to define a fu
Tom Lane wrote:
Considering that someone earlier in this thread was specifically asking
to put LANGUAGE before the function body (apparently unaware that he
already could), I doubt we can get away with removing that flexibility.
That was me, and I'm glad to see you can do it. I guess I should
Tom Lane wrote:
Considering that someone earlier in this thread was specifically asking
to put LANGUAGE before the function body (apparently unaware that he
already could), I doubt we can get away with removing that flexibility.
I didn't consider *removing* flexibility, but *adding* flexibilit
Tommi =?iso-8859-15?q?M=E4kitalo?= <[EMAIL PROTECTED]> writes:
> 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 n
On Mon, 1 Sep 2003, Peter Eisentraut wrote:
> 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 w
99 matches
Mail list logo
