I've frozen the docs sources for the Programmer's Guide, and have
generated the hardcopy. I'm planning on generating the Tutorial,
INSTALL, and HISTORY tonight, and the User's Guide tomorrow.

Bruce, are install.sgml and release.sgml finished?

I am looking for updates to ref/{lock,set}.sgml for MVCC and related
changes, which go into the User's Guide. I'm out of town Saturday Jun
5 01:00 UTC through Monday June 7 5:00 UTC, so will need the updates
by tomorrow or I'll need to ask for yet another extension.

                    - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Thu, 03 Jun 1999 02:07:48 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Freezing docs for v6.5
Thomas Lockhart wrote:
> 
> I've frozen the docs sources for the Programmer's Guide, and have
> generated the hardcopy. I'm planning on generating the Tutorial,
> INSTALL, and HISTORY tonight, and the User's Guide tomorrow.
> 
> Bruce, are install.sgml and release.sgml finished?
> 
> I am looking for updates to ref/{lock,set}.sgml for MVCC and related
> changes, which go into the User's Guide. I'm out of town Saturday Jun
> 5 01:00 UTC through Monday June 7 5:00 UTC, so will need the updates
> by tomorrow or I'll need to ask for yet another extension.

I'll post these changes today directly to you.
Text version...

Vadim

Thu, 03 Jun 1999 10:22:55 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Freezing docs for v6.5
> I'll post these changes today directly to you.
> Text version...

Thanks :)

                   - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Thu, 03 Jun 1999 02:41:31 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Freezing docs for v6.5
> I've frozen the docs sources for the Programmer's Guide, and have
> generated the hardcopy. I'm planning on generating the Tutorial,
> INSTALL, and HISTORY tonight, and the User's Guide tomorrow.
> 
> Bruce, are install.sgml and release.sgml finished?
> 
> I am looking for updates to ref/{lock,set}.sgml for MVCC and related
> changes, which go into the User's Guide. I'm out of town Saturday Jun
> 5 01:00 UTC through Monday June 7 5:00 UTC, so will need the updates
> by tomorrow or I'll need to ask for yet another extension.
> 

No, nor is the ref stuff done.  Extend it.

-- 
  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

Wed, 2 Jun 1999 22:47:39 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: Freezing docs for v6.5
> > I've frozen the docs sources for the Programmer's Guide, and have
> > generated the hardcopy. I'm planning on generating the Tutorial,
> > INSTALL, and HISTORY tonight, and the User's Guide tomorrow.
> > Bruce, are install.sgml and release.sgml finished?
> > I am looking for updates to ref/{lock,set}.sgml for MVCC and related
> > changes, which go into the User's Guide. I'm out of town Saturday Jun
> > 5 01:00 UTC through Monday June 7 5:00 UTC, so will need the updates
> > by tomorrow or I'll need to ask for yet another extension.
> No, nor is the ref stuff done.  Extend it.

Whoops! The "No" means that install.sgml and release.sgml are not
finished? What else needs to be done on them? I've made some very
minor wording and markup changes in the release notes, and will commit
those tonight. the Programmer's Guide and the Tutorial are finished,
and I was hoping to do INSTALL, HISTORY, and the Admin Guide (all of
which need install.sgml and release.sgml to be done) tonight.

Vadim sez he'll send some plain text updates (hopefully for the ref
pages) tomorrow, so I should be able to get that incorporated into the
User's Guide then.

                      - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Thu, 03 Jun 1999 03:48:57 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Freezing docs for v6.5
> I've frozen the docs sources for the Programmer's Guide, and have
> generated the hardcopy. I'm planning on generating the Tutorial,
> INSTALL, and HISTORY tonight, and the User's Guide tomorrow.
> 
> Bruce, are install.sgml and release.sgml finished?
> 
> I am looking for updates to ref/{lock,set}.sgml for MVCC and related
> changes, which go into the User's Guide. I'm out of town Saturday Jun
> 5 01:00 UTC through Monday June 7 5:00 UTC, so will need the updates
> by tomorrow or I'll need to ask for yet another extension.

If someone else can take on the lock/set grammar changes, that would be
great.  I did a cvs diff of gram.y from the 6.4.2 date and current, and
there is what needs to be changed.

-- 
  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

Wed, 2 Jun 1999 23:57:09 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: Freezing docs for v6.5
Thomas Lockhart wrote:
> 
> > > I've frozen the docs sources for the Programmer's Guide, and have
> > > generated the hardcopy. I'm planning on generating the Tutorial,
> > > INSTALL, and HISTORY tonight, and the User's Guide tomorrow.
> > > Bruce, are install.sgml and release.sgml finished?
> > > I am looking for updates to ref/{lock,set}.sgml for MVCC and related
> > > changes, which go into the User's Guide. I'm out of town Saturday Jun
> > > 5 01:00 UTC through Monday June 7 5:00 UTC, so will need the updates
> > > by tomorrow or I'll need to ask for yet another extension.
> > No, nor is the ref stuff done.  Extend it.
> 
> Whoops! The "No" means that install.sgml and release.sgml are not
> finished? What else needs to be done on them? I've made some very
> minor wording and markup changes in the release notes, and will commit
> those tonight. the Programmer's Guide and the Tutorial are finished,
> and I was hoping to do INSTALL, HISTORY, and the Admin Guide (all of
> which need install.sgml and release.sgml to be done) tonight.
> 
> Vadim sez he'll send some plain text updates (hopefully for the ref
> pages) tomorrow, so I should be able to get that incorporated into the

For lock.sgml and set.sgml. I assume that they are used for lock and
set man pages which I would like to use as sources for updation.

> User's Guide then.

BTW, I have some notes for release.sgml, "Migration to v6.5" section,
about using contrib/refint.* - one will have to use LOCK statements
to get it working properly, -:(. I'll write it in the next 12 hours...

Vadim

Thu, 03 Jun 1999 11:58:18 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Re: Freezing docs for v6.5
> Whoops! The "No" means that install.sgml and release.sgml are not
> finished? What else needs to be done on them? I've made some very
> minor wording and markup changes in the release notes, and will commit
> those tonight. the Programmer's Guide and the Tutorial are finished,
> and I was hoping to do INSTALL, HISTORY, and the Admin Guide (all of
> which need install.sgml and release.sgml to be done) tonight.
> 
> Vadim sez he'll send some plain text updates (hopefully for the ref
> pages) tomorrow, so I should be able to get that incorporated into the
> User's Guide then.

Sorry.  Install is done.  release notes just need to be finalized with
all listed changes.  When should we say no more?  Things are still
happening in the fix area, I think.

The man pages and sgml/ref stuff is the hard part.  I am not sure what
they all do, and was discouraged to see the 'set' manual page doesn't
have lots of stuff that should be in there, and are in the sgml version.
The psql \h stuff also needs work.  I am pretty busy with other stuff
for the next two days.  That is the problem.

-- 
  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

Thu, 3 Jun 1999 00:07:19 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: Freezing docs for v6.5
> > Vadim sez he'll send some plain text updates (hopefully for the ref
> > pages) tomorrow
> For lock.sgml and set.sgml. I assume that they are used for lock and
> set man pages which I would like to use as sources for updation.

The sgml produces html and ps formats. The man pages are not (yet)
generated automatically from the sgml, but will be in some future
release (offers of help on the conversion have not yet resulted in
actual help...).

I would appreciate getting the updates inside of ref/{lock,set}.sgml,
and then you or someone else can update the man pages while I am
working on the hardcopy.

> BTW, I have some notes for release.sgml, "Migration to v6.5" section,
> about using contrib/refint.* - one will have to use LOCK statements
> to get it working properly, -:(. I'll write it in the next 12 hours...

OK, great. That might delay me a bit, but it will be well worth it. I
had hoped to run through another ~200 pages of hardcopy tonight, but
am on hold for both the release notes and the User's Guide.

If you can get to the release notes first, then I can go ahead and
finish 3 docs (the Admin Guide, INSTALL, and HISTORY).

Thanks for all of your work. Hope this crunch isn't too painful :/

                    - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Thu, 03 Jun 1999 04:17:52 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Re: Freezing docs for v6.5
Thomas Lockhart wrote:
> 
> > > Vadim sez he'll send some plain text updates (hopefully for the ref
> > > pages) tomorrow
> > For lock.sgml and set.sgml. I assume that they are used for lock and
> > set man pages which I would like to use as sources for updation.
> 
> The sgml produces html and ps formats. The man pages are not (yet)
> generated automatically from the sgml, but will be in some future
> release (offers of help on the conversion have not yet resulted in
> actual help...).
> 
> I would appreciate getting the updates inside of ref/{lock,set}.sgml,

Ok.

> and then you or someone else can update the man pages while I am
> working on the hardcopy.
> 
> > BTW, I have some notes for release.sgml, "Migration to v6.5" section,
> > about using contrib/refint.* - one will have to use LOCK statements
> > to get it working properly, -:(. I'll write it in the next 12 hours...
> 
> OK, great. That might delay me a bit, but it will be well worth it. I
> had hoped to run through another ~200 pages of hardcopy tonight, but
> am on hold for both the release notes and the User's Guide.
> 
> If you can get to the release notes first, then I can go ahead and
> finish 3 docs (the Admin Guide, INSTALL, and HISTORY).

Ok. In the next 3 hours... ok?

Vadim

Thu, 03 Jun 1999 12:24:43 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Re: Freezing docs for v6.5
On Thu, 3 Jun 1999, Thomas Lockhart wrote:

> If you can get to the release notes first, then I can go ahead and
> finish 3 docs (the Admin Guide, INSTALL, and HISTORY).
> 
> Thanks for all of your work. Hope this crunch isn't too painful :/

How are we doing for the 7th as a release?  Need a couple of more days to
touch up docs?  Or are we okay for the 7th?

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


Thu, 3 Jun 1999 01:27:47 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: Freezing docs for v6.5
> > Whoops! The "No" means that install.sgml and release.sgml are not
> > finished? What else needs to be done on them? I've made some very
> > minor wording and markup changes in the release notes, and will commit
> > those tonight. the Programmer's Guide and the Tutorial are finished,
> > and I was hoping to do INSTALL, HISTORY, and the Admin Guide (all of
> > which need install.sgml and release.sgml to be done) tonight.
> > 
> > Vadim sez he'll send some plain text updates (hopefully for the ref
> > pages) tomorrow, so I should be able to get that incorporated into the
> 
> For lock.sgml and set.sgml. I assume that they are used for lock and
> set man pages which I would like to use as sources for updation.

The man pages and sgml pages are separate, and require separate
maintenance.


-- 
  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

Thu, 3 Jun 1999 00:33:38 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: Freezing docs for v6.5]
> How are we doing for the 7th as a release?  Need a couple of more days 
> to touch up docs?  Or are we okay for the 7th?

Not sure yet. I expect that I will need an extra day or two since I'm
out of town for the 5th and 6th. But if we plan to slip, then the
stuff I need might slip too :/

Tom Lane is still chasing bugs with great efficiency, so an extra day
to test a "candidate release tarball" (missing only a few of the docs)
could certainly do no harm. If nothing else it would let us test the
tarball to make sure that the yacc/bison file phasing is OK (this has
bit us a few times recently).

                         - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Thu, 03 Jun 1999 05:31:45 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Re: Freezing docs for v6.5
On Thu, 3 Jun 1999, Thomas Lockhart wrote:

> > How are we doing for the 7th as a release?  Need a couple of more days 
> > to touch up docs?  Or are we okay for the 7th?
> 
> Not sure yet. I expect that I will need an extra day or two since I'm
> out of town for the 5th and 6th. But if we plan to slip, then the
> stuff I need might slip too :/
> 
> Tom Lane is still chasing bugs with great efficiency, so an extra day
> to test a "candidate release tarball" (missing only a few of the docs)
> could certainly do no harm. If nothing else it would let us test the
> tarball to make sure that the yacc/bison file phasing is OK (this has
> bit us a few times recently).

Okay, let's go with a 'pre-release' tarball for the 7th and a release on
the 9th then, if no objections?

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


Thu, 3 Jun 1999 09:16:33 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: Freezing docs for v6.5
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> Tom Lane is still chasing bugs with great efficiency,

Chasing 'em, anyway; no claims about efficiency :-).  Most of the stuff
on my "to fix" list is not showstopper material; it'd be nice to get it
done before 6.5 but I won't feel bad if it isn't.  There's always
another bug...

The two bugs I am really concerned about right now are the
inheritance-vs-GROUP-BY issue and the bogus-cache-entries-not-flushed-
at-xact-abort issue, because I am not sure I know enough to fix either
one right, and there is very little testing time left.  These are bad
bugs, but they exist in older releases too, so maybe we should just
leave 'em alone for 6.5?  Opinions?  (There seem to be some nontrivial
open issues in locking and segmented relations, too, so maybe there is
enough stuff here to delay the release while we fix these things?)

> so an extra day
> to test a "candidate release tarball" (missing only a few of the docs)
> could certainly do no harm. If nothing else it would let us test the
> tarball to make sure that the yacc/bison file phasing is OK (this has
> bit us a few times recently).

In theory, that problem is Permanently Fixed, since the derived yacc
files are no longer in the CVS tree but are created on-the-fly during
tarball preparation.  In practice, we should double-check it.

You've all seen this one, right?
	Q: What is the difference between theory and practice?
	A: In theory, there is no difference.


			regards, tom lane

Thu, 03 Jun 1999 10:13:15 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: Freezing docs for v6.5 
> Sorry.  Install is done.  release notes just need to be finalized with
> all listed changes.  When should we say no more?  Things are still
> happening in the fix area, I think.

OK, I'm freezing install.sgml and release.sgml. Feel free to make
changes to release.sgml, and *if* you limit the changes to one or a
few one-liners I can update the hardcopy at the last minute. But we
should document release info up to the last minute rather than leaving
something out because docs were supposed to be frozen.

> The man pages and sgml/ref stuff is the hard part.  I am not sure what
> they all do, and was discouraged to see the 'set' manual page doesn't
> have lots of stuff that should be in there, and are in the sgml version.
> The psql \h stuff also needs work.  I am pretty busy with other stuff
> for the next two days.  That is the problem.

No problem. afaik the sgml sources are almost done, with a couple of
patches coming from Vadim sometime soon. imho the original man pages
are doing pretty well, and we aren't promising that they are as
complete or voluminous as the html docs.

The "set" man page is probably the most out of date since there were
several new commands added recently. So if you have a chance to update
that one things are likely to be good enough.

                           - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Thu, 03 Jun 1999 14:58:01 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Freezing docs for v6.5
On Thu, 3 Jun 1999, Tom Lane wrote:

> The two bugs I am really concerned about right now are the
> inheritance-vs-GROUP-BY issue and the bogus-cache-entries-not-flushed-
> at-xact-abort issue, because I am not sure I know enough to fix either
> one right, and there is very little testing time left.  These are bad
> bugs, but they exist in older releases too, so maybe we should just
> leave 'em alone for 6.5?  Opinions?  (There seem to be some nontrivial
> open issues in locking and segmented relations, too, so maybe there is
> enough stuff here to delay the release while we fix these things?)

If the 'bugs' aren't something new we created since v6.4.2, leave them
alone...would be nice to fix them, but nobody expected them to work to
date, so leavign it for v6.6 (or even a v6.5.1) is acceptable...

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


Thu, 3 Jun 1999 13:25:54 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: Freezing docs for v6.5 
> If the 'bugs' aren't something new we created since v6.4.2, leave them
> alone...would be nice to fix them, but nobody expected them to work to
> date, so leavign it for v6.6 (or even a v6.5.1) is acceptable...
> 

Isn't minor bugfixing in 6.5.1 a no-no.  We only do major fixes in those
minor releases, right?

-- 
  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

Thu, 3 Jun 1999 12:48:07 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: Freezing docs for v6.5
The Hermit Hacker <scrappy@hub.org> writes:
> On Thu, 3 Jun 1999, Tom Lane wrote:
>> The two bugs I am really concerned about right now are the
>> inheritance-vs-GROUP-BY issue and the bogus-cache-entries-not-flushed-
>> at-xact-abort issue, because I am not sure I know enough to fix either
>> one right, and there is very little testing time left.  These are bad
>> bugs, but they exist in older releases too, so maybe we should just
>> leave 'em alone for 6.5?

> If the 'bugs' aren't something new we created since v6.4.2, leave them
> alone...would be nice to fix them, but nobody expected them to work to
> date, so leavign it for v6.6 (or even a v6.5.1) is acceptable...

I don't mind postponing the inheritance/GROUP-BY issue on that basis,
because it's an identifiable feature that doesn't work (and never has
worked).  I'm more troubled about the cache issue, because that could
give rise to hard-to-predict flaky behavior; we might waste a lot of
time chasing bug reports that ultimately reduce to that problem but
are not easily recognizable as such.

Bruce seemed to think that we could just flush the sys caches and
relation cache completely during xact abort.  This would probably be
less efficient than identifying the specific entries to get rid of, but
it would plug the hole in the dike well enough for 6.5.  Any objections
to doing that?

			regards, tom lane

Thu, 03 Jun 1999 13:43:44 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: Freezing docs for v6.5 
> Bruce seemed to think that we could just flush the sys caches and
> relation cache completely during xact abort.  This would probably be
> less efficient than identifying the specific entries to get rid of, but
> it would plug the hole in the dike well enough for 6.5.  Any objections
> to doing that?

I don't see how we could do anything more aggressive at this point,
though the flush may have some side-affects we don't know about yet,
even though it works for temp tables.

-- 
  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

Thu, 3 Jun 1999 14:09:13 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: Freezing docs for v6.5
On Thu, 3 Jun 1999, Tom Lane wrote:

> Bruce seemed to think that we could just flush the sys caches and
> relation cache completely during xact abort.  This would probably be
> less efficient than identifying the specific entries to get rid of, but
> it would plug the hole in the dike well enough for 6.5.  Any objections
> to doing that?

Sounds reasonable to me...its a stop gap that, the wya things have gone,
since its less efficient, will get re-identified in the future when
someone trying to optimize hings even further...

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


Thu, 3 Jun 1999 15:15:03 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: Freezing docs for v6.5 
On Thu, 3 Jun 1999, Bruce Momjian wrote:

> > If the 'bugs' aren't something new we created since v6.4.2, leave them
> > alone...would be nice to fix them, but nobody expected them to work to
> > date, so leavign it for v6.6 (or even a v6.5.1) is acceptable...
> > 
> 
> Isn't minor bugfixing in 6.5.1 a no-no.  We only do major fixes in those
> minor releases, right?

*raised eyebrow*  Wouldn't minor-bugfixing be "safer" then major ones?

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


Thu, 3 Jun 1999 15:16:34 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: Freezing docs for v6.5
The Hermit Hacker wrote:
> 
> On Thu, 3 Jun 1999, Tom Lane wrote:
> 
> > Bruce seemed to think that we could just flush the sys caches and
> > relation cache completely during xact abort.  This would probably be
> > less efficient than identifying the specific entries to get rid of, but
> > it would plug the hole in the dike well enough for 6.5.  Any objections
> > to doing that?
> 
> Sounds reasonable to me...its a stop gap that, the wya things have gone,
> since its less efficient, will get re-identified in the future when
> someone trying to optimize hings even further...

Could you remember me what's the problem with cache?

Vadim

Fri, 04 Jun 1999 02:25:54 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Re: Freezing docs for v6.5
> On Thu, 3 Jun 1999, Bruce Momjian wrote:
> 
> > > If the 'bugs' aren't something new we created since v6.4.2, leave them
> > > alone...would be nice to fix them, but nobody expected them to work to
> > > date, so leavign it for v6.6 (or even a v6.5.1) is acceptable...
> > > 
> > 
> > Isn't minor bugfixing in 6.5.1 a no-no.  We only do major fixes in those
> > minor releases, right?
> 
> *raised eyebrow*  Wouldn't minor-bugfixing be "safer" then major ones?
> 

I thought we only fixed must-fix bugs in minor releases because there
was too much of a risk that any fix will break too many things, and
there is little testing of minor releases, so we fix as few things as
possible.


-- 
  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

Thu, 3 Jun 1999 14:42:43 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: Freezing docs for v6.5
On Thu, 3 Jun 1999, Bruce Momjian wrote:

> > On Thu, 3 Jun 1999, Bruce Momjian wrote:
> > 
> > > > If the 'bugs' aren't something new we created since v6.4.2, leave them
> > > > alone...would be nice to fix them, but nobody expected them to work to
> > > > date, so leavign it for v6.6 (or even a v6.5.1) is acceptable...
> > > > 
> > > 
> > > Isn't minor bugfixing in 6.5.1 a no-no.  We only do major fixes in those
> > > minor releases, right?
> > 
> > *raised eyebrow*  Wouldn't minor-bugfixing be "safer" then major ones?
> > 
> 
> I thought we only fixed must-fix bugs in minor releases because there
> was too much of a risk that any fix will break too many things, and
> there is little testing of minor releases, so we fix as few things as
> possible.

sorry, heat was hitting me over here :)  minor releases are meant to fix
things like 'it doesn't quite install cleaning on X platform', where the
fix is harmless...

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


Thu, 3 Jun 1999 16:01:10 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: Freezing docs for v6.5
> sorry, heat was hitting me over here :)  minor releases are meant to fix
> things like 'it doesn't quite install cleaning on X platform', where the
> fix is harmless...

Yes, the magnitude of possible damage for a patch is considered much
more in minor releases.

-- 
  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

Thu, 3 Jun 1999 15:11:57 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: Freezing docs for v6.5
Thomas Lockhart wrote:
> 
> I've frozen the docs sources for the Programmer's Guide, and have
> generated the hardcopy. I'm planning on generating the Tutorial,
> INSTALL, and HISTORY tonight, and the User's Guide tomorrow.
> 
> Bruce, are install.sgml and release.sgml finished?
> 
> I am looking for updates to ref/{lock,set}.sgml for MVCC and related
> changes, which go into the User's Guide. I'm out of town Saturday Jun
> 5 01:00 UTC through Monday June 7 5:00 UTC, so will need the updates
> by tomorrow or I'll need to ask for yet another extension.

Sorry, but I'm not able to update lock.sgml now - too many things
to say about and I'm tired, -:(.

Vadim

Fri, 04 Jun 1999 04:21:00 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Freezing docs for v6.5
Vadim Mikheev <vadim@krs.ru> writes:
>> On Thu, 3 Jun 1999, Tom Lane wrote:
>>>> Bruce seemed to think that we could just flush the sys caches and
>>>> relation cache completely during xact abort.

> Could you remember me what's the problem with cache?

The reported problem was that if a new relation is created, and then
the transaction is aborted, the SysCache entry for the new relation's
pg_class entry doesn't get removed.  For example:

test=> create table bug1 (f1 int28 primary key);
ERROR:  Can't find a default operator class for type 22.
-- That's expected, since we have no index support for int28.  But now:
test=> create table bug1 (f1 int28);
ERROR:  Relation 'bug1' already exists

The second try fails because it finds an entry for 'bug1' in the
RELNAME SysCache, which was made before the create-index step of
CREATE TABLE failed.  That entry should not be there anymore.

I suspect that this is an instance of a generic problem with *all*
the SysCache tables, and perhaps the relcache as well: there is no
mechanism to ensure that the caches stay in sync with the underlying
relation during an abort.  So there could be all kinds of weird
misbehavior following an error, if the transaction added or modified
a SysCache entry before failing.

Bruce has a related problem for temp tables: he needs to make sure that
their entries in these caches go away at end of transaction.  (BTW, what
makes that happen if the transaction is aborted rather than committed?)

There is probably a better way to fix it than the brute force "flush the
whole cache" method --- for example, how do cache entries get deleted
normally, if the underlying relation entry is deleted?  Maybe that
mechanism could be used.  But I doubt we have time to do anything fancy
for 6.5.

			regards, tom lane

Thu, 03 Jun 1999 17:23:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: Freezing docs for v6.5 
Tom Lane wrote:
> 
> Vadim Mikheev <vadim@krs.ru> writes:
> >> On Thu, 3 Jun 1999, Tom Lane wrote:
> >>>> Bruce seemed to think that we could just flush the sys caches and
> >>>> relation cache completely during xact abort.
> 
> > Could you remember me what's the problem with cache?
> 
> The reported problem was that if a new relation is created, and then
> the transaction is aborted, the SysCache entry for the new relation's
> pg_class entry doesn't get removed.  For example:
> 
> test=> create table bug1 (f1 int28 primary key);
> ERROR:  Can't find a default operator class for type 22.
> -- That's expected, since we have no index support for int28.  But now:
> test=> create table bug1 (f1 int28);
> ERROR:  Relation 'bug1' already exists
> 
> The second try fails because it finds an entry for 'bug1' in the
> RELNAME SysCache, which was made before the create-index step of
> CREATE TABLE failed.  That entry should not be there anymore.

Note this:

vac=> begin;
BEGIN
vac=> create table bug1 (f1 int28);
CREATE
vac=> abort;
ABORT
vac=> create table bug1 (f1 int28);
CREATE

I would leave this in 6.5 as is.

Vadim

Fri, 04 Jun 1999 09:53:54 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Re: Freezing docs for v6.5
> Vadim Mikheev <vadim@krs.ru> writes:
> >> On Thu, 3 Jun 1999, Tom Lane wrote:
> >>>> Bruce seemed to think that we could just flush the sys caches and
> >>>> relation cache completely during xact abort.
> 
> > Could you remember me what's the problem with cache?
> 
> The reported problem was that if a new relation is created, and then
> the transaction is aborted, the SysCache entry for the new relation's
> pg_class entry doesn't get removed.  For example:
> 
> test=> create table bug1 (f1 int28 primary key);
> ERROR:  Can't find a default operator class for type 22.
> -- That's expected, since we have no index support for int28.  But now:
> test=> create table bug1 (f1 int28);
> ERROR:  Relation 'bug1' already exists
> 
> The second try fails because it finds an entry for 'bug1' in the
> RELNAME SysCache, which was made before the create-index step of
> CREATE TABLE failed.  That entry should not be there anymore.

You know, I wonder if this is somewhat new.  The older code did more
sequential scans of the system tables.  We now do almost everything
through the syscache.

> 
> I suspect that this is an instance of a generic problem with *all*
> the SysCache tables, and perhaps the relcache as well: there is no
> mechanism to ensure that the caches stay in sync with the underlying
> relation during an abort.  So there could be all kinds of weird
> misbehavior following an error, if the transaction added or modified
> a SysCache entry before failing.
> 
> Bruce has a related problem for temp tables: he needs to make sure that
> their entries in these caches go away at end of transaction.  (BTW, what
> makes that happen if the transaction is aborted rather than committed?)

No, that is not the problem.  If there exists a non-temp table with the
same name as the new temp table I am creating, I want the non-temp table
out of the system cache so my new table is seen on the next cache
lookup.

> There is probably a better way to fix it than the brute force "flush the
> whole cache" method --- for example, how do cache entries get deleted
> normally, if the underlying relation entry is deleted?  Maybe that
> mechanism could be used.  But I doubt we have time to do anything fancy
> for 6.5.

Even if we knew how to do that, and I don't(though I tried), we still
have to have some way of knowing _which_ cache entries are invalidated
by the transaction rollback.  One idea was to mark the cache entries
with a transaction id of lookup, and remove those entries that are part
of an invalid transaction.

Other backends don't see the rows until they are committed, but we do
see them because they are part of our own transaction.

-- 
  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

Thu, 3 Jun 1999 21:59:38 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: Freezing docs for v6.5
> Sorry, but I'm not able to update lock.sgml now - too many things
> to say about and I'm tired, -:(.

OK. Bruce has made some additions already, and I'll do the User's
Guide (which contains ref/lock.sgml and ref/set.sgml) as the last doc.
Be sure to get the latest copies before making more changes.

                  - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Fri, 04 Jun 1999 02:08:36 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Freezing docs for v6.5
Vadim Mikheev <vadim@krs.ru> writes:
> Note this:
> vac=> begin;
> BEGIN
> vac=> create table bug1 (f1 int28);
> CREATE
> vac=> abort;
> ABORT
> vac=> create table bug1 (f1 int28);
> CREATE

That's not a very interesting case, because (AFAICS) there is nothing
that will cause the pg_class row for bug1 to get loaded into SysCache
during the transaction.  So, no problem.

I tried the obvious extension:

play=> begin;
BEGIN
play=> create table bug1 (f1 int);
CREATE
play=> create index bug1i on bug1(f1);
CREATE
play=> abort;
ABORT
play=> create table bug1 (f1 int);
CREATE

Hmm ... that's interesting, why does that work?  My guess is that the
CommandCounterIncrement() after the CREATE TABLE causes the SI code
to take responsibility for bug1's pg_class row even though it's not
truly committed.  However,

play=> begin;
BEGIN
play=> create table bug1 (f1 int28);
CREATE
play=> create index bug1i on bug1(f1);
ERROR:  Can't find a default operator class for type 22.
play=> abort;
ABORT
play=> create table bug1 (f1 int28);
ERROR:  bug1 relation already exists

I really do not understand why this last fails when the prior
example works.

However, I've already committed a fix, and all of these
examples now work fine with 6.5 ;-).  So I'm not inclined to
spend more time on the issue right now ... other bugs beckon.

			regards, tom lane

Thu, 03 Jun 1999 23:10:33 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: Freezing docs for v6.5 
Tom Lane wrote:
> 
> Hmm ... that's interesting, why does that work?  My guess is that the
> CommandCounterIncrement() after the CREATE TABLE causes the SI code
  ^^^^^^^^^^^^^^^^^^^^^^^^^
It's called in the case of 
create table bug1 (f1 int28 primary key);
too (after CREATE TABLE and before CREATE INDEX)...

> to take responsibility for bug1's pg_class row even though it's not
> truly committed.  However,

Vadim

Fri, 04 Jun 1999 11:19:00 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Re: Freezing docs for v6.5
I wrote:
>> I suspect that this is an instance of a generic problem with *all*
>> the SysCache tables, and perhaps the relcache as well: there is no
>> mechanism to ensure that the caches stay in sync with the underlying
>> relation during an abort.

Actually, there is such a mechanism: I find that the "shared
invalidation" manager has the right sorts of hooks into the SysCache
stuff.  It appears that once a tuple has been committed, the SI code
will ensure that it gets flushed from all the backends' caches if it
is modified.  The problem comes up when a backend creates a tuple,
causes it to be loaded into SysCache, and then aborts, all within
one transaction.  The SI code doesn't handle that case, for reasons
that are not clear to me.

Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Other backends don't see the rows until they are committed, but we do
> see them because they are part of our own transaction.

Yes, this seems to be a key part of the problem.

The fix I just committed seems to cure the known cases, but it is
not elegant.  I now think that the *real* problem is somewhere in
the sinval code.  But I'm not inclined to try to solve it for 6.5.

			regards, tom lane

Thu, 03 Jun 1999 23:19:26 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: Freezing docs for v6.5 
Vadim Mikheev <vadim@krs.ru> writes:
> Tom Lane wrote:
>> Hmm ... that's interesting, why does that work?  My guess is that the
>> CommandCounterIncrement() after the CREATE TABLE causes the SI code
>   ^^^^^^^^^^^^^^^^^^^^^^^^^
> It's called in the case of 
> create table bug1 (f1 int28 primary key);
> too (after CREATE TABLE and before CREATE INDEX)...

Yeah, I know --- that's why I'm confused about why the one case works
and the other doesn't...

			regards, tom lane

Thu, 03 Jun 1999 23:43:40 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: Freezing docs for v6.5 