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 good. Is it
Dear Sirs and Friends,
I would like to know about cube implementation and materialization
of views in postgresql database. Is it developed already or is it in
process? If it is in process, could u inform me the mail ids please? So
kindly, I request u to inform me regarding this
Tommi Maekitalo wrote:
*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 good. Is it possible to extend lookup that way?
I'd feel
Tommi Maekitalo said:
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
...
Andreas Pflug said:
Tommi Maekitalo wrote:
*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
...
That sounds good. Is it possible to extend lookup that way?
YES it seems.
On Tue, 2 Sep 2003, Tom Lane wrote:
Date: Tue, 02 Sep 2003 13:34:09 -0400
From: Tom Lane [EMAIL PROTECTED]
To: Samuel A Horwitz [EMAIL PROTECTED]
Cc: PostgreSQL-development [EMAIL PROTECTED]
Subject: Re: [HACKERS] elog.c comiple problem on AIX 4.2.1
Samuel A Horwitz [EMAIL
On Wednesday 03 September 2003 00:55, Andreas Pflug wrote:
Darko Prenosil wrote:
Current bcc32.mak produces :
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
Error: Unresolved external '_pqGethostbyname' referenced from
On Wed, Sep 03, 2003 at 01:28:16PM +0800, Christopher Kings-Lynne wrote:
Hi guys,
Where can I find a list of all the 'special' characters in the ~* operator?
They are the same for the ~ operator, and should be listed at the reference page
for regular expressions...
Samuel A Horwitz [EMAIL PROTECTED] writes:
On Tue, 2 Sep 2003, Tom Lane wrote:
[ scratches head ... ] EEXIST and ENOTEMPTY are the same code on your
machine?
YES it seems.
Okay, I've applied a workaround.
regards, tom lane
---(end of
-Original Message-
From: Marc G. Fournier [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 02, 2003 6:13 PM
To: Joerg Hessdoerfer; Alexander Schulz; Hannu Krosing
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Win32 native port
First, there was a branch created a couple of weeks ago:
Larry Rosenman wrote:
--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
Darko Prenosil wrote:
On Wednesday 03 September 2003 00:55, Andreas Pflug wrote:
Darko Prenosil wrote:
Current bcc32.mak produces :
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
Error: Unresolved external '_pqGethostbyname' referenced from
Andrew Dunstan wrote:
Andreas Pflug said:
Tommi Maekitalo wrote:
*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
...
That sounds good. Is it possible
On Mon, Sep 01, 2003 at 09:59:17PM +0200, Tommi Mäkitalo wrote:
psql: FATAL: no pg_hba.conf entry for host :::127.0.0.1, user
postgres, database template1
This is a Linux system that does not have the IPV6_V6ONLY
setsockopt() option. Linux only has this option since 2.4.21
(pre3).
Tom Lane writes:
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 ...
Yes, unfortunately
Andreas Pflug wrote:
Andrew Dunstan wrote:
Andreas Pflug said:
Tommi Maekitalo wrote:
*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
...
That sounds
Olivier PRENANT wrote:
Larry Rosenman wrote:
SNIP
I am inclined to think yes. It would prevent uglification of the code
by not having to special-case Unixware.
However, I was able to read the libc sources to confirm thread-safety.
Because you can not see the source, would you try a threaded
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
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
Olivier PRENANT wrote:
It's ok to assume thread-safety, as the SCO developer (Kean Johnston)
asked the threads guys, and he said that the libc stuff is
thread-safe so they don't have to have 2 different versions in libc.
LER
If any one can write a program that can prove
Larry Rosenman wrote:
Woh, I thought we just agreed that getpwuid_r() isn't required for
thread-safety on your platform.
it's CLEANER to use it.
Our API Signature is the _r version, why not use it when it's available?
My new patch will optionally use it if it exists, but we still
Andrew Dunstan wrote:
This doesn't look consistent to me. Local addresses can be all
addresses that the host's interfaces are currently configured with,
loopback is nothing special in this sense. The admin can easily do
'ifconfig' to see all addresses configured and enter them into
On Wed, Sep 03, 2003 at 06:18:40PM +1000, Gavin Sherry wrote:
As for materialised views, I cannot recall any discussion of this in the
recent past.
Sorry, what is a materialized view? Is it something that you can do
with CREATE TABLE AS, or it is more involved than that?
--
Alvaro Herrera
It's rumoured that Andreas Pflug once said:
for pgadmin3 use we have
http://snake.pgadmin.org/snapshots/postgresql/libs-win32-20030829.zip
which includes a static libpq and the openssl libs.
Dave, maybe we should mirror this also to postgresql.org?
Yes, I'm not happy with the way things are
Bruce Momjian wrote:
Andrew Dunstan wrote:
We currently have this in the default pg_hba.conf file:
host all all 127.0.0.1 255.255.255.255 trust
The idea was to have something which would perform equivalently on IP4
only, IP4 over IP6 and pure IP6 connections, without breaking the
Bruce Momjian wrote:
We have avoided doing dns lookups from pg_hba.conf, and hence the use of
127.0.0.1 instead of localhost. Now that we cache pg_hba.conf, we could
consider allowing hostnames in pg_hba.conf. Is that a TODO?
Hm. DNS lookup would make postmaster startup last much longer, to
Thanks - past that problem.
On Wed, 3 Sep 2003, Tom Lane wrote:
Date: Wed, 03 Sep 2003 12:03:58 -0400
From: Tom Lane [EMAIL PROTECTED]
To: Samuel A Horwitz [EMAIL PROTECTED]
Cc: PostgreSQL-development [EMAIL PROTECTED]
Subject: Re: [HACKERS] elog.c comiple problem on AIX 4.2.1
Samuel A
[EMAIL PROTECTED] wrote:
Olivier PRENANT wrote:
It's ok to assume thread-safety, as the SCO developer (Kean Johnston)
asked the threads guys, and he said that the libc stuff is
thread-safe so they don't have to have 2 different versions in libc.
If any one can write a program
Tom Lane writes:
Yeah. I would suggest doing it at the check that C compiler still
works stage, after we think we have all the CFLAGS. Couldn't we just
throw a prototyped function into that test program?
The standard Autoconf prototype test is pretty involved (see
AC_PROG_CC_STDC in
Does anybody know of a BSD licensed signal implementation that
compiles on win32?
See how Apache handles this problem (via APR?).
-sc
--
Sean Chittenden
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
What do people think about adding the transaction status indicator to the
default psql prompt, so it'd look something like this:
peter=# begin;
BEGIN
peter*=# foo;
ERROR: syntax error at or near foo at character 1
peter!=# rollback;
ROLLBACK
peter=#
I think many people would find that useful.
I'm seeing the following with the current CVS code on my Linux dev box:
$ make maintainer-clean
$ ./configure --enable-depend --enable-cassert --enable-debug
--prefix=/pgsql --with-openssl
[ ... ]
$ make -s
In file included from bootparse.y:340:
lex.Int_yy.c:1832: warning: no previous prototype
Tom Lane wrote:
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
From UnixWare:
$ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
UX:acomp: WARNING: test_thread.c, line 60: argument #3 incompatible with
prototype: pthread_create()
UX:acomp: WARNING: test_thread.c, line 61: argument #3 incompatible with
prototype: pthread_create()
$ ./test_thread
Tom Lane wrote:
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
FWIW, I do confirm, on dual XEON with JT enabled
On Wed, 3 Sep 2003, Larry Rosenman wrote:
Date: Wed, 03 Sep 2003 14:53:39 -0500
From: Larry Rosenman [EMAIL PROTECTED]
To: Bruce Momjian [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Unixware Patch (Was: Re:
On Wed, Sep 03, 2003 at 03:36:53PM -0400, Bruce Momjian wrote:
I would like every operating system that supports thread-safety to run
this program and report back the results.
On a Linux system with glibc 2.1:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your
--On Wednesday, September 03, 2003 17:09:49 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
--On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
From UnixWare:
$ cc -O -Kpthread test_thread.c -o test_thread
Larry Rosenman wrote:
--On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
From UnixWare:
$ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
UX:acomp: WARNING: test_thread.c, line 60: argument #3 incompatible
Tom Lane wrote:
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
--On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
From UnixWare:
$ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
UX:acomp: WARNING: test_thread.c, line 60: argument #3 incompatible
with prototype: pthread_create()
[EMAIL PROTECTED] wrote:
FWIW, I do confirm, on dual XEON with JT enabled
Oh, I now see OS as Unixware:
I have 2 bi-pro machines here both running unixware
7.1.3 I can make tests if you want
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
FWIW, I do confirm, on dual XEON with JT enabled
Operating system?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your
Larry Rosenman wrote:
From UnixWare:
$ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
UX:acomp: WARNING: test_thread.c, line 60: argument #3 incompatible with
prototype: pthread_create()
UX:acomp: WARNING: test_thread.c, line 61: argument #3 incompatible with
prototype:
Dann Corbit wrote:
I sent signal code to Bruce Momjian that can be freely used in the
project. It compiles on Win32 and has been contributed as BSD license.
The architecture is a bit different from what had already been
accomplished, so I don't know how hard it will be to splice it in.
I
Christopher Kings-Lynne wrote:
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
Christopher Kings-Lynne wrote:
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
Larry Rosenman wrote:
What does your OS want for the 3rd argument of pthread_create()? I
thought a void pointer would be OK for everyone:
pthread_create(thread1, NULL, (void *) func_call_1, NULL);
void *(*start_routine)(void*)
Here is our man page:
On Wed, 3 Sep 2003, Alvaro Herrera wrote:
On Wed, Sep 03, 2003 at 06:18:40PM +1000, Gavin Sherry wrote:
As for materialised views, I cannot recall any discussion of this in the
recent past.
Sorry, what is a materialized view? Is it something that you can do
with CREATE TABLE AS, or it
Neil Conway writes:
lex.Int_yy.c:1832: warning: no previous prototype for `Int_yyget_lineno'
These are caused by the new flex. Ignore them.
tablecmds.c: In function `validateForeignKeyConstraint':
tablecmds.c:3546: warning: dereferencing type-punned pointer will break
strict-a
Kurt Roeckx wrote:
On Wed, Sep 03, 2003 at 03:36:53PM -0400, Bruce Momjian wrote:
I would like every operating system that supports thread-safety to run
this program and report back the results.
On a Linux system with glibc 2.1:
Your gethostbyname() is _not_ thread-safe
Your
Can you pass me what's in CVS (anon hasn't updated afaict).
And, what didn't you like about my version?
LER
--On Wednesday, September 03, 2003 18:35:44 -0400 Bruce Momjian
[EMAIL PROTECTED] wrote:
Larry Rosenman wrote:
What does your OS want for the 3rd argument of pthread_create()? I
On Wed, Sep 03, 2003 at 09:19:33PM -0400, Serguei A. Mokhov wrote:
If you take a close look at the output above, you will see that the
prompt shifts one character to the right when you are in a transaction.
That is going to look terrible. I don't think we should have a moving
prompt as
Serguei A. Mokhov [EMAIL PROTECTED] writes:
On Wed, 3 Sep 2003, Alvaro Herrera wrote:
On Wed, Sep 03, 2003 at 09:19:33PM -0400, Serguei A. Mokhov wrote:
On the contrary, it could show the transaction level for the case of
nested transactions:
foo**=#
Ugh... pretty ugly.
Peter Eisentraut [EMAIL PROTECTED] writes:
What do people think about adding the transaction status indicator to the
default psql prompt, so it'd look something like this:
Okay with me.
Btw., would anyone mind if the code for this indicator where not %T, but
say instead %x, because there is
Neil Conway [EMAIL PROTECTED] writes:
I'm seeing the following with the current CVS code on my Linux dev box:
In file included from bootparse.y:340:
lex.Int_yy.c:1832: warning: no previous prototype for `Int_yyget_lineno'
lex.Int_yy.c:1841: warning: no previous prototype for `Int_yyget_in'
I was attempting to get pg_autovacuum to work on my database and after much hammering
at it I discovered that the stats system was not working. I tried it with both
7.4beta1 and 7.4beta2 in both cases the number of tuples inserted, deleted and updated
remained at 0 no matter what database
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
What do people think about adding the transaction status indicator to the
default psql prompt, so it'd look something like this:
Okay with me.
Btw., would anyone mind if the code for this indicator where not %T, but
say
Bruce Momjian [EMAIL PROTECTED] writes:
If you take a close look at the output above, you will see that the
prompt shifts one character to the right when you are in a transaction.
That is going to look terrible.
It didn't look so bad to me. But anyway, what the %T indicator should
look like
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
If you take a close look at the output above, you will see that the
prompt shifts one character to the right when you are in a transaction.
That is going to look terrible.
It didn't look so bad to me. But anyway, what the %T
Today's commits from Bruce don't seem to be there.
I'm doing:
cvs update -d -P
(I sent another note to Marc as a safety).
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs
Adam Kavan [EMAIL PROTECTED] writes:
I was attempting to get pg_autovacuum to work on my database and after
much hammering at it I discovered that the stats system was not
working.
Does 'ps' show that the stats collector and stats buffer postmaster
child processes are alive? Are there any
everything looks okay on teh server ...the script is set to run hourly,
and there aren't any log files to that can go stale with that one to
prevent it from happening ...
I just manually ran it .. did that help?
On Wed, 3 Sep 2003, Larry Rosenman wrote:
Today's commits from Bruce don't seem
--On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
everything looks okay on teh server ...the script is set to run hourly,
and there aren't any log files to that can go stale with that one to
prevent it from happening ...
I just manually ran it .. did
--On Wednesday, September 03, 2003 23:34:09 -0500 Larry Rosenman
[EMAIL PROTECTED] wrote:
--On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier
[EMAIL PROTECTED] wrote:
everything looks okay on teh server ...the script is set to run hourly,
and there aren't any log files to
On Wed, 2003-09-03 at 23:50, Tom Lane wrote:
Does 'ps' show that the stats collector and stats buffer postmaster
child processes are alive? Are there any suggestive complaints in
the postmaster's log?
As Adam mentioned, I took a look at his system since the initial report
was about a problem
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Couldn't we just throw a prototyped function into that test program?
The standard Autoconf prototype test is pretty involved (see
AC_PROG_CC_STDC in /usr/local/share/autoconf/autoconf/c.m4 or whatever).
Yikes. And that's really of
Matthew T. O'Connor [EMAIL PROTECTED] writes:
... Initially I saw an error in the logs about an IPv6 address
error but after I recompiled everthing with a simple ./configure
--prefix=/home/user/somethingelse/ I didn't get the IPv6 error in the
logs anymore.
Hm. Could it be an IPv6 issue ---
pg_class.relacl is of type aclitem[] and has a pg_attribute.attstorage
of 'x', even though it doesn't support TOAST expansion:
grant select on t1 to foo1,foo2,foo3,foo4, ...(10k of items)
ERROR: Tuple is too big: size 32684, max size 813
Is it 'x' to be
On Thu, 2003-09-04 at 01:23, Tom Lane wrote:
Hm. Could it be an IPv6 issue --- that is, the stats collector is alive
and faithfully listening on some UDP port, but it's not the same port
the backends try to send to? Given the discussion over the past couple
of days about bizarre
Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
... Initially I saw an error in the logs about an IPv6 address
error but after I recompiled everthing with a simple ./configure
--prefix=/home/user/somethingelse/ I didn't get the IPv6 error in the
logs anymore.
Hm. Could
Bruce Momjian [EMAIL PROTECTED] writes:
Doesn't the stats collector use unix domain sockets, not IP?
No. IIRC, we deliberately chose IP/UDP because it had buffering
behavior we liked.
There are pipes involved in the stats stuff too, but the weak link
in my mind is the
I have made Debian packages of PostgreSQL 7.4beta2 and uploaded them to
Debian's experimental archive.
The package version is 7.3.99.7.4beta2-1 (so that when 7.4's final
version comes out, it will be perceived as a later package). They are
built on a machine running current unstable, so they
the offnum of LOCKTAG I gather indicates which row (tuple) is being locked
in a row level locking. But when I lock 2 diffrent rows of a table, offset
for both is 0. and also offset is 0 if i take a table lock on the same
table. (blkno is the same for all three locks)..shouldnt the OffsetNumber
On 3 Sep 2003 at 11:28, Bo Lorentsen wrote:
On Wed, 2003-09-03 at 11:10, Shridhar Daithankar wrote:
Yes. It is correct. As of 7.3.x and onwards oids are optional at table creation
times. They default to be available for new objects but that is for backwards
compatibility I believe. In
On Wed, Sep 03, 2003 at 12:20:42PM +0200, Bo Lorentsen wrote:
On Wed, 2003-09-03 at 11:38, Shridhar Daithankar wrote:
Well, what I do is, declare a serate sequence, retrive next available value and
explicitly insert it into a integer field. That avoids having to retrieve the
latest
That said, there is no reason why someone couldn't create a last_sequence()
function so you could say SELECT currval( last_sequence() ). Ofcourse, if
your table has no SERIAL field, you're stuffed either way.
Instead of SELECT currval( last_sequence() ), what about implementing
oracl type
On Wed, Sep 03, 2003 at 01:47:01PM +0200, Bo Lorentsen wrote:
On Wed, 2003-09-03 at 13:19, Martijn van Oosterhout wrote:
The only thing you need to know is the name of the primary key field. This
many be a problem in a generic layer. If you like you can make a UNIQUE
INDEX on the oid column
77 matches
Mail list logo
