Are we going to release subj in near future?
If yes then please wait a few days - seems that I'll
have patch for btree to fix problems reported by
Oleg Bartunov - indices growing/update slowdown...

Vadim

Fri, 06 Aug 1999 17:59:38 +0800
Vadim Mikheev <vadim@krs.ru>
6.5.2
Vadim Mikheev <vadim@krs.ru> writes:
> Are we going to release subj in near future?
> If yes then please wait a few days -

Also, I'd like to see if we can't resolve Adriaan Joubert's bug report
first.  The list-clearing problem doesn't seem to be it...

			regards, tom lane

Fri, 06 Aug 1999 09:52:47 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] 6.5.2 
All has been going well with this version, so I decided to
let 'er rip in public two days ago.  Last night, I got the
following error from my nightly pg_dump, which has been running
fine for weeks during development:

Can not create pgdump_oid table.  Explanation from backend: 'ERROR:  cannot
create pgdump_oid
'.

Any explanations for this behavior?

Any ideas as to how I can fix it?  I'm dumping OIDs because some of the
free code I'm porting from Oracle/Tcl/AOLserver to Postgres/Tcl/AOLserver
uses their equivalent row id in places.

sigh...



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Fri, 06 Aug 1999 08:40:10 -0700
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] 6.5.1, error in pg_dump
Don Baccus <dhogaza@pacifier.com> writes:
> Can not create pgdump_oid table.  Explanation from backend: 'ERROR:  cannot
> create pgdump_oid
> '.

AFAICT, the only way that you'd get that precise wording out of the
backend is if its attempt to create the physical file for the table
fails --- that is, open(filename, O_RDWR | O_CREAT | O_EXCL, 0600)
fails.  The only error message I can find with that wording is in
smgrcreate(), and it looks like all the other potential causes of
failure below that point (such as running out of memory) would yield
different messages.

So, it would seem that the initial cause of the problem is that there
was already a file by that name --- perhaps because some earlier
instance of postgres failed to unlink it.

I'm not sure about the bizarrenesses you report later on --- they
sound like the system tables may have gotten corrupted, or perhaps
just the relation cache inside the backend.  (Did killing the backend
and starting a new one help?)  But I am thinking the error messages
must have been different at that point...

We saw vaguely similar behaviors with temp tables when we were still
flushing the bugs out of temp tables.  I wonder if there are still
some temp-table-related bugs?

			regards, tom lane

Fri, 06 Aug 1999 18:48:16 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] 6.5.1, error in pg_dump 
At 06:48 PM 8/6/99 -0400, Tom Lane wrote:
>Don Baccus <dhogaza@pacifier.com> writes:
>> Can not create pgdump_oid table.  Explanation from backend: 'ERROR:  cannot
>> create pgdump_oid
>> '.
>
>AFAICT, the only way that you'd get that precise wording out of the
>backend is if its attempt to create the physical file for the table
>fails --- that is, open(filename, O_RDWR | O_CREAT | O_EXCL, 0600)
>fails.  The only error message I can find with that wording is in
>smgrcreate(), and it looks like all the other potential causes of
>failure below that point (such as running out of memory) would yield
>different messages.
>
>So, it would seem that the initial cause of the problem is that there
>was already a file by that name --- perhaps because some earlier
>instance of postgres failed to unlink it.

thanks for tracking this down, I was busy yesterday, started to
poke at sources but didn't really have time to do so in earnest.

This does fit with the fact that the files for the offending
tables did indeed still exist.

I did try deleting the one for my "foo" test case, and could
then create and supposedly drop the table, but the relation
in this case then was not removed from pg_class, nor was the
file removed.  

I have had occassional filesystem problems on this machine,
and not only in postgres.  Linux flakies?  System flakies?
I've not quite been able to decide, nor do I have a spare
machine to rebuild on.  I keep hearing that Linux is very
solid, particularly the 2.0.36 kernal I'm using, but this
is my first experience running Linux on a steady basis (I
have tons of other Unix experience, of course).

>
>I'm not sure about the bizarrenesses you report later on --- they
>sound like the system tables may have gotten corrupted, or perhaps
>just the relation cache inside the backend.  (Did killing the backend
>and starting a new one help?)

No, unfortunately.

>  But I am thinking the error messages
>must have been different at that point...

Yes, the relation was still in the pg_class table (I think that's
right as opposed to pg_tables).  As was the file.  This makes more
sense, actually, in that it appears that the unlink was failing
and it didn't get removed from the system table, either - though
it's weird it reported success on the drop.

One thought crossing my mind was that the Linux filesystem may've
gotten itself into a weird state, in particular the cache.  I
rebooted, initdb'd and rebuilt and everything's OK now.

>We saw vaguely similar behaviors with temp tables when we were still
>flushing the bugs out of temp tables.  I wonder if there are still
>some temp-table-related bugs?

At this point I'm willing to believe it is a Linux or (perhaps
more likely) system problem.   If it happens again, I'm better
prepared as to where to look for more details, at least.




- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Sat, 07 Aug 1999 08:01:17 -0700
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] 6.5.1, error in pg_dump 
On Fri, 6 Aug 1999, Tom Lane wrote:

> Vadim Mikheev <vadim@krs.ru> writes:
> > Are we going to release subj in near future?
> > If yes then please wait a few days -
> 
> Also, I'd like to see if we can't resolve Adriaan Joubert's bug report
> first.  The list-clearing problem doesn't seem to be it...

Shall we go for a Sept 1st release of  v6.5.2?  Vadim, does that give you
enough time?  It doesn't have to be "perfect", only better then v6.5.1...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Sun, 15 Aug 1999 23:22:30 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] 6.5.2 
On Sun, 15 Aug 1999, The Hermit Hacker wrote:

> Date: Sun, 15 Aug 1999 23:22:30 -0300 (ADT)
> From: The Hermit Hacker <scrappy@hub.org>
> To: Tom Lane <tgl@sss.pgh.pa.us>
> Cc: Vadim Mikheev <vadim@krs.ru>,
>     PostgreSQL Developers List <hackers@postgreSQL.org>
> Subject: Re: [HACKERS] 6.5.2 
> 
> On Fri, 6 Aug 1999, Tom Lane wrote:
> 
> > Vadim Mikheev <vadim@krs.ru> writes:
> > > Are we going to release subj in near future?
> > > If yes then please wait a few days -
> > 
> > Also, I'd like to see if we can't resolve Adriaan Joubert's bug report
> > first.  The list-clearing problem doesn't seem to be it...
> 
> Shall we go for a Sept 1st release of  v6.5.2?  Vadim, does that give you
> enough time?  It doesn't have to be "perfect", only better then v6.5.1...

Vadim has made a quick patch for row-reusing in index file after vacuum and
I've tested it on my Linux box, 6.5.1 sources. It works fine - 
now index file doesn't grow indefinitely ! It still grows (logarithmically) 
but not as before. Of course, fully truncating would be fine. but
as Vadim said it's another story.

What's a list of changes for 6.5.2 ? I've seen several patches for 6.5.1
and current tree. Some of them I'd like to see in 6.5.2:

1. Vadim's patch for nbtinsert
2. enabling Index access for multi-column indices by Hiroshi Inoue
3. Descending order Index scan patch by Hiroshi Inoue 


	Regards,

		Oleg

> 
> Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
> Systems Administrator @ hub.org 
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 
> 
> 

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83




Mon, 16 Aug 1999 13:01:42 +0400 (MSD)
Oleg Bartunov <oleg@sai.msu.su>
None
Hello!

   I didn't saw my latest patches for README.locale in latest (Aug 15)
snapshot, although Bruce reported he got it. I think it best to apply it
for 6.5.2 than to 6.6 ot 7.0...

Oleg.
---- 
    Oleg Broytmann     http://members.xoom.com/phd2/     phd2@earthling.net
           Programmers don't die, they just GOSUB without RETURN.


Mon, 16 Aug 1999 13:48:49 +0400 (MSD)
Oleg Broytmann <phd@emerald.netskate.ru>
Re: [HACKERS] 6.5.2
On Mon, 16 Aug 1999, Oleg Bartunov wrote:

> 1. Vadim's patch for nbtinsert
> 2. enabling Index access for multi-column indices by Hiroshi Inoue
> 3. Descending order Index scan patch by Hiroshi Inoue 

Expect bug fixes, not extra features...2 and 3 are nice, but don't fix a
bug other them possibly improving speed...they will not be in 6.5.2...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Mon, 16 Aug 1999 09:08:57 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: your mail
The Hermit Hacker wrote:
> 
> On Mon, 16 Aug 1999, Oleg Bartunov wrote:
> 
> > 1. Vadim's patch for nbtinsert
> > 2. enabling Index access for multi-column indices by Hiroshi Inoue
> > 3. Descending order Index scan patch by Hiroshi Inoue
> 
> Expect bug fixes, not extra features...2 and 3 are nice, but don't fix a
> bug other them possibly improving speed...

Or in case of 3 avoiding exhausting memory on unneccessary sort.

>they will not be in 6.5.2...

Will they be in patches/ in a form ready to apply to 6.5.2 ?

--------
Hannu

Tue, 17 Aug 1999 00:42:27 +0300
Hannu Krosing <hannu@trust.ee>
Re: [HACKERS] Re: your mail
The Hermit Hacker wrote:
> 
> On Fri, 6 Aug 1999, Tom Lane wrote:
> 
> > Vadim Mikheev <vadim@krs.ru> writes:
> > > Are we going to release subj in near future?
> > > If yes then please wait a few days -
> >
> > Also, I'd like to see if we can't resolve Adriaan Joubert's bug report
> > first.  The list-clearing problem doesn't seem to be it...
> 
> Shall we go for a Sept 1st release of  v6.5.2?  Vadim, does that give you
> enough time?  It doesn't have to be "perfect", only better then v6.5.1...

I posted patch to hackers- or patches-list - sorry, but I haven't
6.5.X tree. I don't know is it applied or not...

Vadim

Tue, 17 Aug 1999 09:25:32 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] 6.5.2
Oleg, do you seem them now?  If not, can you send them to me.

> Hello!
> 
>    I didn't saw my latest patches for README.locale in latest (Aug 15)
> snapshot, although Bruce reported he got it. I think it best to apply it
> for 6.5.2 than to 6.6 ot 7.0...


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 27 Sep 1999 14:21:23 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] 6.5.2
Hi!

On Mon, 27 Sep 1999, Bruce Momjian wrote:
> Oleg, do you seem them now?  If not, can you send them to me.

   I saw it long time ago and sent my thankx to the list. It seems you
store messages in your mailbox a little too long :)

> > Hello!
> > 
> >    I didn't saw my latest patches for README.locale in latest (Aug 15)
> > snapshot, although Bruce reported he got it. I think it best to apply it
> > for 6.5.2 than to 6.6 ot 7.0...

> -- 
>   Bruce Momjian                        |  http://www.op.net/~candle
>   maillist@candle.pha.pa.us            |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Oleg.
---- 
    Oleg Broytmann     http://members.xoom.com/phd2/     phd2@earthling.net
           Programmers don't die, they just GOSUB without RETURN.


Tue, 28 Sep 1999 11:06:42 +0400 (MSD)
Oleg Broytmann <phd@sun.med.ru>
Re: [HACKERS] 6.5.2
> Hi!
> 
> On Mon, 27 Sep 1999, Bruce Momjian wrote:
> > Oleg, do you seem them now?  If not, can you send them to me.
> 
>    I saw it long time ago and sent my thankx to the list. It seems you
> store messages in your mailbox a little too long :)

Yes, I am way behind.  I just got off a 4 month job, so I finally had
some time to work on this.  With a major release months away, I wasn't
rushing to apply patches.  I am now.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 28 Sep 1999 08:51:43 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] 6.5.2