Hi,
This is not a real security issue but it seems not very appropreate
behavior for me.
$ psql -U foo test
Password: XXX
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash
I still have problem when doing cvs update on a fresh source tree. I did
cvs checkout after the changes in cvs servers.
$ cvs update
cannot create_adm_p /tmp/cvs-serv24877/ChangeLogs
Permission denied
I think it is a problem on the CVS server. My client side is Cygwin
1.3.3 and cvs 1.11
Do the multibyte regression tests in src/test/mb currently pass for
other people? I'm getting failures on most of them, and what it looks
like to me is that the latest commits of the expected files contain
wrong results.
You are correct. Will fix.
--
Tatsuo Ishii
Ookay, this it now:
cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot login
(Logging in to [EMAIL PROTECTED])
CVS password:
cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot co pgsql
cvs server: Updating pgsql
U pgsql/COPYRIGHT
U pgsql/GNUmakefile.in
U pgsql/HISTORY
U pgsql/INSTALL
U
Try it:
cd pgsql
cvs -q update -APd .
? .new.configure
U configure
U configure.in
U register.txt
U ChangeLogs/ChangeLog-7.1-7.1.1
U ChangeLogs/ChangeLog-7.1RC1-to-7.1RC2
U ChangeLogs/ChangeLog-7.1RC2-to-7.1RC3
U ChangeLogs/ChangeLog-7.1RC3-to-7.1rc4
U ChangeLogs/ChangeLog-7.1beta1-to-7.1beta3
just checked, and the machine has been up 14days now ... I can ssh into it
from cvs.postgresql.org, and the last cvsup connection was about 5 minutes
ago:
Sep 21 09:10:42 server1 cvsupd[50149]: +3 [EMAIL PROTECTED] (fs1.olabinc.com)
[SNAP_16_1e/16.1]
Sep 21 09:11:53 server1 cvsupd[50149]: -3
!$
head -20 20010921.out
Parsing supfile cvsup_config
Connecting to cvsup.postgresql.org
Connected to cvsup.postgresql.org
Server software version: REL_16_1p3
Falling back to protocol version 16.1
Negotiating file attribute support
Exchanging collection information
Establishing multiplexed-mode data
Tatsuo Ishii [EMAIL PROTECTED] writes:
As you can see, psql reconnect as any user if the password is same as
foo. Of course this is due to the careless password setting, but I
think it's better to prompt ANY TIME the user tries to switch to
another user. Comments?
Yeah, I agree. Looks like
While looking through the code I found an already existing alter table drop
column in src/backend/parser/gram.y. However, when I try to run it in psql
it comes back with a not implemented. Was the left hand not talking to the
right hand when this was coded or is there more to this?
Geoff
When modifying postgresql.conf (or, now, pg_hba.conf) one must send a
SIGHUP to the postmaster to get it to pay attention. Seems like it'd
be nice if pg_ctl had an option to do that, rather than having to muck
about with looking in ps output. Any objections? What should the
option be called?
On Fri, 21 Sep 2001, Gowey, Geoffrey wrote:
While looking through the code I found an already existing alter table drop
column in src/backend/parser/gram.y. However, when I try to run it in psql
it comes back with a not implemented. Was the left hand not talking to the
right hand when
I am running the command as you have written:
cd pgsql
cvs -q update -APd .
but still I am getting
cannot create_adm_p /tmp/cvs-serv24877/ChangeLogs
Permission denied
on both Cygwin and Linux
my CVS/Repository for the top-level directory
/projects/cvsroot/pgsql
and I have tries only
On Fri, Sep 21, 2001 at 07:27:10PM +0200, Horák Daniel wrote:
...
but still I am getting
cannot create_adm_p /tmp/cvs-serv24877/ChangeLogs
Permission denied
aol
Me Too!
/aol
---(end of broadcast)---
TIP 5: Have you checked our extensive
try that ... you might have to remove the pgsql directory first, but I've
just tried from a remote machine and ran into same problems (testing from
same machine isn't necessarily good *groan*) ... it looks like its working
for me now ...
On Fri, 21 Sep 2001, Oleg Bartunov wrote:
Marc,
I'm
Thanks.
It works now for me
Regards,
Oleg
On Fri, 21 Sep 2001, Marc G. Fournier wrote:
try that ... you might have to remove the pgsql directory first, but I've
just tried from a remote machine and ran into same problems (testing from
same machine isn't necessarily
Alex Pilosov [EMAIL PROTECTED] writes:
Alex, could we have this resubmitted in diff -c format? Plain diff
format is way too risky to apply.
Resubmitted. In case list server chokes on the attachment's size, it is
also available on www.formenos.org/pg/cursor.fix5.diff
I've looked this over,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Folks-
Has the password for anoncvs been changed? I can't seem to get into it
anymore.
Virtually,
Ned Wolpert [EMAIL PROTECTED]
D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45
-BEGIN PGP SIGNATURE-
Version: GnuPG
I am back from one week vacation. I will work through the mailing lists
tomorrow and leave for OSDN conference on Sunday afternoon, EST.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive,
what sort of error?
On Fri, 21 Sep 2001, Ned Wolpert wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Folks-
Has the password for anoncvs been changed? I can't seem to get into it
anymore.
Virtually,
Ned Wolpert [EMAIL PROTECTED]
D08C2F45: 28E7 56CB 58AC C622 5A51 3C42
On Fri, 21 Sep 2001, Tom Lane wrote:
I've looked this over, and I think it's not mature enough to apply at
this late stage of the 7.2 cycle; we'd better hold it over for more work
during 7.3. Major problems:
1. Insufficient defense against queries that outlive the cursors they
select
2) I just sync'ed via cvsup at cvsup.postgresql.org and it deleted all
under pgsql/src/interfaces/odbc/*. It also does not seem to appear
anywhere else. What's up?
I see this too. I blew away my repository and populated it from scratch,
and still see the problem. In fact, the odbc
Fixed ... my exclude file had a rule in it that prevented odbc from being
rsync'd down ... all should be downloaded now ...
as for a 'sitemap', the server that all of this is on is meant to be
purelya 'mirror' of the central one on mail.postgresql.org, except there
are no accounts on the
Thanks Marc !
I just cvsup'ed and odbc seems to be all back.
Thanks !
Best regards,
.. Otto
Otto Hirr
OLAB Inc
503.617.6595
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Marc
G. Fournier
Sent: Friday, September 21, 2001
Fixed ... my exclude file had a rule in it that prevented odbc from being
rsync'd down ... all should be downloaded now ...
Great! Haven't tested it yet, but Otto is happy so I'm sure I'll be
too...
Server software version: REL_16_1p3
This does *not* seem to be fresh enough. JDP
On Sat, 22 Sep 2001, Thomas Lockhart wrote:
Fixed ... my exclude file had a rule in it that prevented odbc from being
rsync'd down ... all should be downloaded now ...
Great! Haven't tested it yet, but Otto is happy so I'm sure I'll be
too...
Server software version: REL_16_1p3
Hi,
I have written a small function that show how many tuples are dead
etc. in a specified table. Example output is:
test=# select pgstattuple('tellers');
NOTICE: physical length: 0.02MB live tuples: 200 (0.01MB, 58.59%) dead tuples: 100
(0.00MB, 29.30%) overhead: 12.11%
pgstattuple
Tatsuo Ishii [EMAIL PROTECTED] writes:
I have written a small function that show how many tuples are dead
etc. in a specified table.
Dead according to whose viewpoint? Under MVCC this seems to be
in the eye of the beholder...
Shall I add this function into contrib directory?
No
On Fri, 21 Sep 2001, Thomas Lockhart wrote:
$ ping cvsup.postgresql.org
PING rs.postgresql.org: 64 byte packets
64 bytes from 64.39.15.238: icmp_seq=0. time=57. ms
64 bytes from 64.39.15.238: icmp_seq=1. time=70. ms
Perhaps there is a routing problem somewhere between you and
On Wed, 19 Sep 2001, D'Arcy J.M. Cain wrote:
Thus spake Marc G. Fournier
can you ssh into cvs.postgresql.org?
Yes! I could not do that before. Did you fix something?
Nope :(
---(end of broadcast)---
TIP 2: you can get off all lists at
For me it seems to be slow due to the sorting. Is this right?
Is this normal at all? Is it possible to make it faster?
If you know, that your result does not produce duplicates
(which are filtered away with union) you can use a
union all which should be substantially faster, since it
Okay, that is fixed ... for some reason, it didn't restart on last reboot,
have to watch that one ...
Thanks for fixing it. Now of course the machine does not seem to be
visible. That was the case yesterday too; are these planned outages, is
it still bouncing up and down as it is configured,
Tatsuo Ishii writes:
As you can see, psql reconnect as any user if the password is same as
foo. Of course this is due to the careless password setting, but I
think it's better to prompt ANY TIME the user tries to switch to
another user.
I'm not sure. A few users have voiced concerns about
As you can see, psql reconnect as any user if the password is same
as
foo. Of course this is due to the careless password setting, but I
think it's better to prompt ANY TIME the user tries to switch to
another user.
I'm not sure. A few users have voiced concerns about this before,
Peter Eisentraut [EMAIL PROTECTED] writes:
concluding that this password is valid for all databases is trivial since
that's the default setup.
No, I think you're missing the point --- we're concerned about
reconnecting as a different user, not reconnecting to a different
database. The issue
Hi,
I have written a small function that show how many tuples are dead
etc. in a specified table. Example output is:
test=# select pgstattuple('tellers');
NOTICE: physical length: 0.02MB live tuples: 200 (0.01MB, 58.59%) dead tuples: 100
(0.00MB, 29.30%) overhead: 12.11%
pgstattuple
Thomas Lockhart [EMAIL PROTECTED] writes:
Thanks for fixing it. Now of course the machine does not seem to be
visible. That was the case yesterday too; are these planned outages, is
it still bouncing up and down as it is configured, or is it flakey?
Looks fine from here:
$ ping
$ ping cvsup.postgresql.org
PING rs.postgresql.org: 64 byte packets
64 bytes from 64.39.15.238: icmp_seq=0. time=57. ms
64 bytes from 64.39.15.238: icmp_seq=1. time=70. ms
Perhaps there is a routing problem somewhere between you and 64.39.15.238?
That machine is not physically at hub (looks
Marc,
I'm back from vacation and also can't do cvs:
pg@zen:~/cvs$ cvs -z3 checkout pgsql
cannot create_adm_p /tmp/cvs-serv67095/pgsql
Permission denied
Oleg
On Fri, 21 Sep 2001, Marc G. Fournier wrote:
Ookay, this it now:
cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot login
Tom Lane writes:
Any objections?
No. Definitely needed.
What should the option be called? pg_ctl hup is short but maybe too
Unix-sysadminy; perhaps something like pg_ctl reconfig?
If you accept the Linux Standards Base as a precedent for the other
options, it should be reload. That will
Tom Lane writes:
No, I think you're missing the point --- we're concerned about
reconnecting as a different user, not reconnecting to a different
database.
Oh, of course. I agree, in that case the password shouldn't be reused.
--
Peter Eisentraut [EMAIL PROTECTED]
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
What should the option be called?
If you accept the Linux Standards Base as a precedent for the other
options, it should be reload.
Works for me.
regards, tom lane
---(end of
Tatsuo Ishii [EMAIL PROTECTED] writes:
I have written a small function that show how many tuples are dead
etc. in a specified table.
Dead according to whose viewpoint? Under MVCC this seems to be
in the eye of the beholder...
You can know if the tuple is visible to other backends, or
Three things that GB provided for their $25million:
1. Tom's ability to focus on programming more
2. Bruce's ability to travel and evangelize(sp?) more
3. www.greatbridge.org
Three things that are going to change now that GB is gone:
1. tom's wife will see more of him
2. bruce's wife
Bruce Momjian [EMAIL PROTECTED] writes:
... Maybe he has coded that in there.
Maybe so, but he didn't say. That's why I was asking for exact
documentation.
regards, tom lane
---(end of broadcast)---
TIP 3: if
What about the server versioning issue? I see no mention of
REL_16_1panything as being safe to use. Please confirm that this is in
fact the 16_1d or 16_1e release!!
This is what is/was latest in ports after you mentioned the problem ...
I'll check ports again over the next day or so to
Bruce Momjian [EMAIL PROTECTED] writes:
... Maybe he has coded that in there.
Maybe so, but he didn't say. That's why I was asking for exact
documentation.
As you can see from the source code, it just use
HeapTupleSatisfiesNow(). I wrote this function for the admin
use. He/she should
Okay, that is fixed ... for some reason, it didn't restart on last reboot,
have to watch that one ...
On Thu, 20 Sep 2001, Thomas Lockhart wrote:
I'm trying to update my cvs tree and am currently seeing the following:
Parsing supfile postgres.cvsup
Connecting to cvsup.postgresql.org
On Thu, Sep 20, 2001 at 09:55:56PM -0400, Tom Lane wrote:
Do the multibyte regression tests in src/test/mb currently pass for
other people? I'm getting failures on most of them, and what it looks
like to me is that the latest commits of the expected files contain
wrong results.
$
48 matches
Mail list logo
