Thread: 6.5.2
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
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
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 Serviceand other goodies at http://donb.photo.net.
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
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 Serviceand other goodies at http://donb.photo.net.
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
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
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 justGOSUB without RETURN.
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
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
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
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
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 justGOSUB without RETURN.
> 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, Pennsylvania19026