Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Isn't it practical to replace all susipicious Search
SysCacheTuple() by SearchSysCacheTupleCopy() ?
That would replace a rare failure condition by a not-at-all-rare
memory leak. I'm not sure there'd be a net gain in reliability :-(
* Peter Eisentraut [EMAIL PROTECTED] [001113 23:52]:
Okay, but you can't make these options PGC_SIGHUP unless you make sure to
close and re-open the syslog channel whenever these options
change. Probably ought to be PGC_POSTMASTER.
Is there a mechanism to "hear" the SIGHUP? Although, it
Hiroshi Inoue [EMAIL PROTECTED] writes:
A more serious objection to SearchSysCacheTupleCopy is that once the
tuple is copied out of the syscache, there isn't any mechanism to
detect whether it's still valid. If an SI message arrives for a
recently-copied tuple, we have no way to know if we
I've committed the template0/template1 changes we were discussing
earlier. Plain pg_dump and pg_dumpall are changed to behave properly,
but I didn't touch pg_backup or pg_restore; can you deal with those?
regards, tom lane
On Tue, 14 Nov 2000, Hannu Krosing wrote:
when trying to do
get -R RedHat-6.x RedHat-7.0 Mandrake-7.x
I got
get RedHat-7.0: server said: Permission denied on server. (Transfer
limits exceeded)
aftre all of RedHat-6.x was retrieved
is there any reason for this ?
Yes, we don't
[EMAIL PROTECTED] (David J. MacKenzie) writes:
I was afraid you were planning to run that way. Did you absorb the
point about shared memory keys being based (only) on the port number?
+* So, if you use -h or PGHOST, don't try to run two instances of
+* PostgreSQL on the same
On Tue, Nov 14, 2000 at 03:05:04PM -0500, Tom Lane wrote:
I think that in the last discussion of shared memory key assignment,
we had come up with a plan for detecting key collisions directly instead
of hoping they wouldn't happen. I don't have time to pursue this right
now, but according
Trying to get my FreeBSD box (lerbsd.lerctr.org, 4.2-BETA) up on
current sources. Got this error:
make[3]: Entering directory `/home/ler/pg-dev/src/backend/parser'
cc -O2 -m486 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations
-Wno-error
-I/usr/local/include -I../../../src/include -c -o
Is your copy of gram.y up to date?
regards, tom lane
* Tom Lane [EMAIL PROTECTED] [001114 15:07]:
Is your copy of gram.y up to date?
$ find . -name gram.y
./src/backend/parser/gram.y
./src/pl/plpgsql/src/gram.y
$ more src/backend/parser/gram.y
src/backend/parser/gram.y 0%
%{
/*#define YYDEBUG 1*/
Larry Rosenman [EMAIL PROTECTED] writes:
* Tom Lane [EMAIL PROTECTED] [001114 15:07]:
Is your copy of gram.y up to date?
*$Header:
*/home/projects/pgsql/cvsroot/pgsql/src/backend/parser/gram.y,
v 2.209 2000/11/14 18:37:49 tgl Exp $
Hm. Looks up-to-date to me. I wonder
* Tom Lane [EMAIL PROTECTED] [001114 15:16]:
Larry Rosenman [EMAIL PROTECTED] writes:
* Tom Lane [EMAIL PROTECTED] [001114 15:07]:
Is your copy of gram.y up to date?
*$Header:
*/home/projects/pgsql/cvsroot/pgsql/src/backend/parser/gram.y,
v 2.209 2000/11/14 18:37:49
* Tom Lane [EMAIL PROTECTED] [001114 15:16]:
Larry Rosenman [EMAIL PROTECTED] writes:
* Tom Lane [EMAIL PROTECTED] [001114 15:07]:
Is your copy of gram.y up to date?
*$Header:
*/home/projects/pgsql/cvsroot/pgsql/src/backend/parser/gram.y,
v 2.209 2000/11/14 18:37:49
Anyone care if I build a patch to kill the -m486 type options in the
following files:
$ grep -i -- 486 *
bsdi: i?86) CFLAGS="$CFLAGS -m486";;
freebsd:CFLAGS='-O2 -m486 -pipe'
univel:CFLAGS='-v -O -K i486,host,inline,loop_unroll -Dsvr4'
$ pwd
/home/ler/pg-dev/pgsql/src/template
$
--
Larry
Larry Rosenman [EMAIL PROTECTED] writes:
Anyone care if I build a patch to kill the -m486 type options in the
following files:
$ grep -i -- 486 *
bsdi: i?86) CFLAGS="$CFLAGS -m486";;
freebsd:CFLAGS='-O2 -m486 -pipe'
univel:CFLAGS='-v -O -K i486,host,inline,loop_unroll -Dsvr4'
Why
* Trond Eivind Glomsr?d [EMAIL PROTECTED] [001114 15:43]:
Larry Rosenman [EMAIL PROTECTED] writes:
Anyone care if I build a patch to kill the -m486 type options in the
following files:
$ grep -i -- 486 *
bsdi: i?86) CFLAGS="$CFLAGS -m486";;
freebsd:CFLAGS='-O2 -m486 -pipe'
* Larry Rosenman [EMAIL PROTECTED] [001114 13:42] wrote:
Anyone care if I build a patch to kill the -m486 type options in the
following files:
$ grep -i -- 486 *
bsdi: i?86) CFLAGS="$CFLAGS -m486";;
freebsd:CFLAGS='-O2 -m486 -pipe'
univel:CFLAGS='-v -O -K i486,host,inline,loop_unroll
* Trond Eivind Glomsrød [EMAIL PROTECTED] [001114 13:45] wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
Anyone care if I build a patch to kill the -m486 type options in the
following files:
$ grep -i -- 486 *
bsdi: i?86) CFLAGS="$CFLAGS -m486";;
freebsd:CFLAGS='-O2 -m486 -pipe'
* Alfred Perlstein [EMAIL PROTECTED] [001114 15:47]:
* Trond Eivind Glomsrød [EMAIL PROTECTED] [001114 13:45] wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
Anyone care if I build a patch to kill the -m486 type options in the
following files:
$ grep -i -- 486 *
bsdi: i?86)
* Larry Rosenman [EMAIL PROTECTED] [001114 13:47] wrote:
* Alfred Perlstein [EMAIL PROTECTED] [001114 15:46]:
* Larry Rosenman [EMAIL PROTECTED] [001114 13:42] wrote:
Anyone care if I build a patch to kill the -m486 type options in the
following files:
$ grep -i -- 486 *
bsdi:
* Alfred Perlstein [EMAIL PROTECTED] [001114 15:46]:
* Larry Rosenman [EMAIL PROTECTED] [001114 13:42] wrote:
Anyone care if I build a patch to kill the -m486 type options in the
following files:
$ grep -i -- 486 *
bsdi: i?86) CFLAGS="$CFLAGS -m486";;
freebsd:CFLAGS='-O2 -m486
Larry Rosenman [EMAIL PROTECTED] writes:
* Trond Eivind Glomsr?d [EMAIL PROTECTED] [001114 15:43]:
Larry Rosenman [EMAIL PROTECTED] writes:
Anyone care if I build a patch to kill the -m486 type options in the
following files:
$ grep -i -- 486 *
bsdi: i?86) CFLAGS="$CFLAGS
[EMAIL PROTECTED] (Trond Eivind Glomsrød) writes:
Larry Rosenman [EMAIL PROTECTED] writes:
* Trond Eivind Glomsr?d [EMAIL PROTECTED] [001114 15:43]:
Larry Rosenman [EMAIL PROTECTED] writes:
Anyone care if I build a patch to kill the -m486 type options in the
following files:
At 13:39 14/11/00 -0500, Tom Lane wrote:
I've committed the template0/template1 changes we were discussing
earlier. Plain pg_dump and pg_dumpall are changed to behave properly,
but I didn't touch pg_backup or pg_restore; can you deal with those?
There's no such think as pg_backup, but
* Larry Rosenman [EMAIL PROTECTED] [001114 16:06]:
* Peter Eisentraut [EMAIL PROTECTED] [001114 16:03]:
Larry Rosenman writes:
log_connections = on
fsync = off
#max_backends = 64
syslog_facility = LOCAL5.3we4rwjtasrtuert
It's the dot. The regular expression needs some
I remeber a few developers used to gather on efnet irc,
there was a lot of instability recently that seems to have
cleared up even more recently.
Are you guys planning on coming back? Or have you all
moved to a different network?
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Sorry, I mixed it up with LATIN1.
Yes, "³\" is a valid big5 code, but I don't know how
to convert it to big5. This problem has been raised in
Taiwan forum many times, you can check it out from
http://www.linuxfab.cx. However, this site supports only
chinese.
Thanks
Dave
What is
Tom Lane wrote:
I said:
This class of bugs has been there since the beginning of Postgres,
so I do not feel that we need to panic about it. Let's take the
time to design and implement a proper solution, rather than expending
effort on a stopgap solution that'll have to be undone later.
* Larry Rosenman [EMAIL PROTECTED] [001114 16:56]:
Ok, so what I think(?) needs to happen is the FIXME: tag needs to be
handled. We need to code a version of src/backend/parser/scansup.c
that doesn't use palloc, and also strips the apostrophes from the
front and end of the string? This
At 13:39 14/11/00 -0500, Tom Lane wrote:
I've committed the template0/template1 changes we were discussing
earlier. Plain pg_dump and pg_dumpall are changed to behave properly,
but I didn't touch pg_backup or pg_restore; can you deal with those?
I still think that pg_dump needs to use the
I'm at Comdex right now, but when I'm around, I'm on channel ...
On Tue, 14 Nov 2000, Alfred Perlstein wrote:
I remeber a few developers used to gather on efnet irc,
there was a lot of instability recently that seems to have
cleared up even more recently.
Are you guys planning on coming
Hi ,
I would like to increase perfomance of PG 7.02 on i486,
where can I read about this ? May be there is any flags for
postgres ?
Thanks.
Igor
At 23:20 14/11/00 -0500, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
I still think that pg_dump needs to use the lastoid in template0 - did you
fail to implement this because you disagree, or because you think it should
use the current db lastsysoid?
I think it should use the
Philip Warner [EMAIL PROTECTED] writes:
Given the present backend coding, all the DBs in an installation will
have the same lastsysoid as template0 anyway, barring manual
intervention.
Not the way the current 'CREATE DATABASE' code works - remember the changes
to set the OID at create time?
At 23:48 14/11/00 -0500, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
Given the present backend coding, all the DBs in an installation will
have the same lastsysoid as template0 anyway, barring manual
intervention.
Not the way the current 'CREATE DATABASE' code works - remember
Hiroshi Inoue [EMAIL PROTECTED] writes:
Callers that want to be certain they have a completely-up-to-date copy
should acquire a suitable lock on the associated system relation before
calling SearchSysCache().
I'm suspcious if it's practical.
What is a suitable lock ?
The lock should
* igor [EMAIL PROTECTED] [001114 20:46] wrote:
Hi ,
I would like to increase perfomance of PG 7.02 on i486,
where can I read about this ? May be there is any flags for
postgres ?
Check your C compiler's manpage for the relevant optimization
flags, be aware that some compilers can emit
Peter Eisentraut [EMAIL PROTECTED] writes:
Should the parameter determine the directory or the full file name? I'd
go for the former, but it's not a strong case.
Directory was what I had in mind too, but I'm not sure what Bruce
actually did ...
I did whatever the patch did. I believe
[EMAIL PROTECTED] (David J. MacKenzie) writes:
but the 7.0 method of computing the socket file name (based
only on the port number) doesn't work for multiple instances
listening on the same port on different IP addresses.
I was afraid you were planning to run that way. Did you absorb the
Peter Eisentraut [EMAIL PROTECTED] writes:
Larry Rosenman writes:
In looking at this some more, it appears that *SOMETHING* is not
allowing messages from set_config_option() in
/src/backend/utils/misc/guc.c out WHEN WE ARE DEALING WITH syslog type
stuff and we are reading it from the
* Peter Eisentraut [EMAIL PROTECTED] [001114 12:45]:
Larry Rosenman writes:
In looking at this some more, it appears that *SOMETHING* is not
allowing messages from set_config_option() in
/src/backend/utils/misc/guc.c out WHEN WE ARE DEALING WITH syslog type
stuff and we are reading it
Larry Rosenman writes:
* Peter Eisentraut [EMAIL PROTECTED] [001114 13:18]:
Larry Rosenman writes:
I can't reproduce that. I set 'syslog_facility = local97' and got the
right error message.
try setting it in postgresql.conf
That's what I did.
Hmm. Here is what I get:
Larry Rosenman writes:
log_connections = on
fsync = off
#max_backends = 64
syslog_facility = LOCAL5.3we4rwjtasrtuert
It's the dot. The regular expression needs some work. Make a note to
always test with identical values next time. :-)
syslog_progid = pgtest
syslog=2
showportnumber =
* Peter Eisentraut [EMAIL PROTECTED] [001114 16:03]:
Larry Rosenman writes:
log_connections = on
fsync = off
#max_backends = 64
syslog_facility = LOCAL5.3we4rwjtasrtuert
It's the dot. The regular expression needs some work. Make a note to
always test with identical values next
* Peter Eisentraut [EMAIL PROTECTED] [001114 14:39]:
Larry Rosenman writes:
* Peter Eisentraut [EMAIL PROTECTED] [001114 13:18]:
Larry Rosenman writes:
I can't reproduce that. I set 'syslog_facility = local97' and got the
right error message.
try setting it in
I said:
I'm surprised you get any error message at all (as seen by a client,
that is, not as seen in the postmaster log). AFAICT, backend libpq
is not fired up until well down inside PostmasterMain --- look at the
call to pq_init.
s/PostmasterMain/PostgresMain/ ...
Larry Rosenman writes:
I can't reproduce that. I set 'syslog_facility = local97' and got the
right error message.
try setting it in postgresql.conf
That's what I did.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Tom Lane writes:
I can't reproduce that. I set 'syslog_facility = local97' and got the
right error message.
I'm surprised you get any error message at all (as seen by a client,
that is, not as seen in the postmaster log).
I was talking about the postmaster log. No clients involved.
* Peter Eisentraut [EMAIL PROTECTED] [001114 13:18]:
Larry Rosenman writes:
I can't reproduce that. I set 'syslog_facility = local97' and got the
right error message.
try setting it in postgresql.conf
That's what I did.
Hmm. Here is what I get:
$ ../bin/pg_ctl -D
49 matches
Mail list logo
