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 reliabi
* 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 p
* 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.
Here is a patch to change to PGC_POSTMASTER...
Index: g
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 ?
Hannu
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 kno
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.
I've reviewed the
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,
[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
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 accord
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 k
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
* 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 2
* 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 2
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 Ros
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'
* 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 -
* 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_u
* 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=
* 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 --
* 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 -
* 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:CFLAG
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
[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
>
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 pg_rest
* 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 ex
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Looks, to me, like gmake distclean should remove gram.c and it's
> header. I removed gram.c, and restarted, and it went to completion.
distclean does not remove gram.c because we include gram.c in the
distribution. Perhaps there should be another ta
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]]
"I
Tom Lane wrote:
> 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 tu
> 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
W
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
* 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 las
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 co
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 current DB's lastsysoid, which is how I
l
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 us
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 cre
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
At 15:59 15/11/00 +1100, Philip Warner wrote:
>
>It looks to me like that was the intent of the code; but there is still:
>
...
>
>Pretty much. Sorry. Is there a smiley for embarrasment?
>
I really need that smiley now. Just saw my mistake.
--
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 sho
* Larry Rosenman <[EMAIL PROTECTED]> [001114 20:45]:
> * 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
* 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 emi
> 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
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> 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
>> ac
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 ...
regards, tom lane
[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
p
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 t
* 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
* Larry Rosenman <[EMAIL PROTECTED]> [001114 14:44]:
> * 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_fac
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
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
> showportnumb
* 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
* 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.
> > > >
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 involv
* 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
Larry Rosenman writes:
> Here is a patch to change to PGC_POSTMASTER...
Thanks. I polished things a bit and it works well for me now.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
After a long day out of the office for my day job, I'm going ahead and
announcing the release of the 7.0.3-1 RPMset for PostgreSQL, which were
completed and passed regression testing yesterday.
ftp://ftp.postgresql.org/pub/binary/v7.0.3/RPMS/*
Binary RPM's are currently available for i386 and Po
62 matches
Mail list logo
