> 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 sho
> > What about the server versioning issue? I see no mention of
> > REL_16_1p 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 see
> 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 direct
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 posting/r
> 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 backe
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 real ob
> 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%
> pgst
> 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. bru
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
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_
> 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 reco
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, 200
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 machine
> 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 d
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
> selec
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 C
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,
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 th
-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 v1.0
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 necessari
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
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 o
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] http://funkturm.ho
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
Me Too!
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
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". T
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, 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 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
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? "
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
-
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 lo
> $ 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 (
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 issu
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 cvsup.pos
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
5)-> head -20 !$
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
Establis
> > 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 b
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 [1
> 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 abo
Thus spake Marc G. Fournier
> > > can you ssh into cvs.postgresql.org?
> >
> > Yes! I could not do that before. Did you fix something?
>
> Nope :(
Just weird. Oh well. All's well, etc.
--
D'Arcy J.M. Cain| Democracy is three wolves
http://www.druid.net/darcy/| and a s
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 a
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.1beta
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 pgs
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.or
> 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
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 com
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
On Thu, Sep 20, 2001 at 12:47:08PM -0400, Marc G. Fournier wrote:
>
> 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 and kids will see more of him
It seems that GB finish is their women conspiracy :-)
Karel
> > 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,
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.
$ ./mbr
51 matches
Mail list logo
