Thread: Re: [HACKERS] Re: pgaccess update for 6.5.2?
Bruce Momjian wrote: > > The real issue was not if it was stable, but whether a non-bugfix > release of pgaccess was proper for a 6.5.2 release. I haven't heard any > comments on that yet. Not sure how I feel either. It's rock solid stable. I am using it for 2 weeks and just minor bugs have been reported (some color problems on Solaris that have been fixed, some messages missing from translations). It will be ready for tomorow to be picked up and included in 6.5.2 distribution. Just I will need a final confirmation with 10 minutes before someone downloads the .tar.gz to be sure that it will be the right one. I'll be (I hope) reachable by e-mail checking my mailbox every 1 minute. Please, there is available a bug fix list for 6.5.2 ? Teo
> Bruce Momjian wrote: > > > > The real issue was not if it was stable, but whether a non-bugfix > > release of pgaccess was proper for a 6.5.2 release. I haven't heard any > > comments on that yet. Not sure how I feel either. > > It's rock solid stable. > > I am using it for 2 weeks and just minor bugs have been reported (some > color problems on Solaris that have been fixed, some messages missing > from translations). > > It will be ready for tomorow to be picked up and included in 6.5.2 > distribution. > Just I will need a final confirmation with 10 minutes before someone > downloads the .tar.gz to be sure that it will be the right one. > I'll be (I hope) reachable by e-mail checking my mailbox every 1 minute. > > Please, there is available a bug fix list for 6.5.2 ? Can I download it 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
Bruce,
in HISTORY for 6.5.2 I see:
This is to re-use space on index pages freed by vacuum(Tom)
isn't this re-use indices after vacuum hack by Vadim ?
(prevent indices to grow infinitely)
Regards,
Oleg
_____________________________________________________________
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
> Bruce,
>
> in HISTORY for 6.5.2 I see:
>
> This is to re-use space on index pages freed by vacuum(Tom)
>
> isn't this re-use indices after vacuum hack by Vadim ?
> (prevent indices to grow infinitely)
>
Thanks. I have updated the release.sgml and the HISTORY file.
I should have posted the list of changes. Here it is. Gee, it is quite
a lot. Thomas, any way to get the dates from the release.sgml into the
HISTORY file and the html output?
---------------------------------------------------------------------------
Detailed Change List
subselect+CASE fixes(Tom) Add SHLIB_LINK setting for solaris_i386 and solaris_sparc ports(Daren Sefcik)
Fixes for CASE in WHERE join clauses(Tom) Fix BTScan abort(Tom) Repair the check for redundant UNIQUE and
PRIMARYKEY indices(Tom) Improve it so that it checks for multi-column constraints(Tom) Fix for Win32 making
problemwith MB enabled(Hiroki Kataoka) Allow BSD yacc and bison to compile pl code(Bruce) Fix SET NAMES
int8fixes(Thomas) Fix vacuum's memory consumption(Tom) Reduce the total memory consumption of vacuum(Tom)
Fix for timestamp(datetime) Rule deparsing bugfixes(Tom) Fix quoting problems in mkMakefile.tcldefs.sh.in and
mkMakefile.tkdefs.sh.in(Tom) Update frontend libpq to remove limits on query lengths, error/notice
messagelengths, and number of fields per tuple(Tom) This is to re-use space on index pages freed by vacuum(Vadim)
document -x for pg_dump(Bruce) Fix for unary operators in rule deparser(Tom) Comment out FileUnlink of
excesssegments during mdtruncate()(Tom) Irix linking fix from Yu Cao <yucao@falcon.kla-tencor.com> Repair
logicerror in LIKE: should not return LIKE_ABORT when reach end of pattern before end of text(Tom) Repair
incorrectcleanup of heap memory allocation during transaction abort(Tom)
-- 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
Oleg Bartunov <oleg@sai.msu.su> writes:
> in HISTORY for 6.5.2 I see:
> This is to re-use space on index pages freed by vacuum(Tom)
> isn't this re-use indices after vacuum hack by Vadim ?
Not mine, for sure.
regards, tom lane
Bruce Momjian wrote: --------------------------------------------------------------------------- > > Detailed Change List > [snip] Hey, Bruce -- did the patches for Alpha get in?? If not, I'll need to mung Ryan K's/Uncle G's patchset against 6.5.1 to work with 6.5.2. Your friendly RPM packager... Lamar Owen WGCR Internet Radio
> Bruce Momjian wrote: > > --------------------------------------------------------------------------- > > > > Detailed Change List > > > [snip] > > Hey, Bruce -- did the patches for Alpha get in?? If not, I'll need to > mung Ryan K's/Uncle G's patchset against 6.5.1 to work with 6.5.2. > > Your friendly RPM packager... The bad news is that those patches are too large/significant for a minor release. They could affect other platforms adversely, so we can't apply them until 6.6. -- 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
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Repair the check for redundant UNIQUE and PRIMARY KEY indices(Tom)
> Improve it so that it checks for multi-column constraints(Tom)
Those were Thomas, I believe.
> Fix vacuum's memory consumption(Tom)
> Reduce the total memory consumption of vacuum(Tom)
And I can't take credit for that either --- Hiroshi and/or Tatsuo get
the credit, IIRC. (BTW, did we patch those into 6.5.*, or only 6.6?)
> Update frontend libpq to remove limits on query lengths,
> error/notice message lengths, and number of fields per tuple(Tom)
This is *not* in 6.5.*, only 6.6.
regards, tom lane
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> Hey, Bruce -- did the patches for Alpha get in?? If not, I'll need to
>> mung Ryan K's/Uncle G's patchset against 6.5.1 to work with 6.5.2.
> The bad news is that those patches are too large/significant for a minor
> release. They could affect other platforms adversely, so we can't apply
> them until 6.6.
Also, most of them were patches for the portability problems in our
function call interface. I still have hopes of redesigning the fmgr
interface completely before 6.6 --- see my message in the hackers
archives for 6/14/99. If we get that done then there'll be no need for
the associated patches. (If we don't, we'd better apply the patches,
since Alpha is not the only platform where there are problems...)
regards, tom lane
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > > Repair the check for redundant UNIQUE and PRIMARY KEY indices(Tom) > > Improve it so that it checks for multi-column constraints(Tom) > > Those were Thomas, I believe. Done. > > > Fix vacuum's memory consumption(Tom) > > Reduce the total memory consumption of vacuum(Tom) > > And I can't take credit for that either --- Hiroshi and/or Tatsuo get > the credit, IIRC. (BTW, did we patch those into 6.5.*, or only 6.6?) Ah, let's give them both credit. > > > Update frontend libpq to remove limits on query lengths, > > error/notice message lengths, and number of fields per tuple(Tom) > > This is *not* in 6.5.*, only 6.6. Sorry. Shows up in the that tag log, so something must be in there. I don't make this stuff up. :-) Checking... -- 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
> And I can't take credit for that either --- Hiroshi and/or Tatsuo get > the credit, IIRC. (BTW, did we patch those into 6.5.*, or only 6.6?) > > > Update frontend libpq to remove limits on query lengths, > > error/notice message lengths, and number of fields per tuple(Tom) > > This is *not* in 6.5.*, only 6.6. I have:RCS file: /usr/local/cvsroot/pgsql/src/interfaces/libpq/pqexpbuffer.c,vWorking file: src/interfaces/libpq/pqexpbuffer.chead:1.1branch:locks: strictaccess list:symbolic names:keyword substitution: kvtotal revisions:1; selected revisions: 1description:----------------------------revision 1.1date: 1999/08/31 01:37:37; author:tgl; state: Exp;Update frontend libpq to remove limits on query lengths,error/notice message lengths, and numberof fields per tuple. Addpqexpbuffer.c/.h, a frontend version of backend's stringinfo module.This is first step inapplying Mike Ansley's long-query patches,even though he didn't do any of these particular changes... Seems addition of text files shows up in all branches, which I guess makes sense. No cause for alarm. -- 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
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> This is *not* in 6.5.*, only 6.6.
> I have:
> RCS file: /usr/local/cvsroot/pgsql/src/interfaces/libpq/pqexpbuffer.c,v
> Working file: src/interfaces/libpq/pqexpbuffer.c
> head: 1.1
> Seems addition of text files shows up in all branches, which I guess
> makes sense. No cause for alarm.
I've noticed that cvs log seems a little bogus in its handling of
branches, even though cvs status and cvs update know perfectly well
what belongs to the local branch and what doesn't. If you say
"cvs log" you get the "current" (tip revision's) log entries, even
if you are in a directory that's been checked out with a sticky
branch tag. If you say "cvs log -rBRANCH" you get the branch's
log entries, but *only* those applied since the branch was split;
there doesn't seem to be any way to get the full history as seen
in this branch. And, as above, it's quite confusing about files
that are not in the local branch at all.
Dunno if the cvs folk consider these behaviors bugs or features,
but they're definitely something to be wary of when working in
a branch...
regards, tom lane