Thread: 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.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
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
> I'll post these changes today directly to you.
> Text version...
Thanks :)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> 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,
Pennsylvania19026
> > 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
> 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,
Pennsylvania19026
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
> > 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
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
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
> 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, Pennsylvania19026
> > 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, Pennsylvania19026
> 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
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
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
> 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
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
> 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, Pennsylvania19026
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
> 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, Pennsylvania19026
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
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
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
> 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, Pennsylvania19026
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
> 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, Pennsylvania19026
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
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
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
> 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, Pennsylvania19026
> 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
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
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
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
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