Обсуждение: PostgreSQL 6.5.2
Are we going to release 6.5.2? If yes, then when? --- Tatsuo Ishii
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> Are we going to release 6.5.2? If yes, then when?
Marc proposed Sept 1 (back on 8/15), and there were no objections...
regards, tom lane
On Sun, 29 Aug 1999, Tom Lane wrote:
> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > Are we going to release 6.5.2? If yes, then when?
>
> Marc proposed Sept 1 (back on 8/15), and there were no objections...
And its still the date I'm planning around...So Wednesday this week :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
>On Sun, 29 Aug 1999, Tom Lane wrote: > >> Tatsuo Ishii <t-ishii@sra.co.jp> writes: >> > Are we going to release 6.5.2? If yes, then when? >> >> Marc proposed Sept 1 (back on 8/15), and there were no objections... > >And its still the date I'm planning around...So Wednesday this week :) Marc, Could you make a tarball of 6.5.2-beta or 6.5.2-release-candidate or whatever so that volunteers could get it by anon ftp for testing? -- Tatsuo Ishii
Try her out...just put up a release candidate now...
On Mon, 30 Aug 1999, Tatsuo Ishii wrote:
> >On Sun, 29 Aug 1999, Tom Lane wrote:
> >
> >> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> >> > Are we going to release 6.5.2? If yes, then when?
> >>
> >> Marc proposed Sept 1 (back on 8/15), and there were no objections...
> >
> >And its still the date I'm planning around...So Wednesday this week :)
>
> Marc,
>
> Could you make a tarball of 6.5.2-beta or 6.5.2-release-candidate or
> whatever so that volunteers could get it by anon ftp for testing?
> --
> Tatsuo Ishii
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> On Sun, 29 Aug 1999, Tom Lane wrote: > > > Tatsuo Ishii <t-ishii@sra.co.jp> writes: > > > Are we going to release 6.5.2? If yes, then when? > > > > Marc proposed Sept 1 (back on 8/15), and there were no objections... > > And its still the date I'm planning around...So Wednesday this week :) > May I ask that the patches I submitted two months ago for 6.5.0 are applied at least to 6.5.2? Here is the 6.5.1 version of my patches. -- Massimo Dal Zotto +----------------------------------------------------------------------+ | Massimo Dal Zotto email: dz@cs.unitn.it | | Via Marconi, 141 phone: ++39-0461534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: finger dz@tango.cs.unitn.it | +----------------------------------------------------------------------+
Massimo Dal Zotto <dz@wizard.net> writes:
> May I ask that the patches I submitted two months ago for 6.5.0 are applied
> at least to 6.5.2?
> Here is the 6.5.1 version of my patches.
I don't much care for QueryLimit (we got rid of that for a reason!)
nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe
enough... but are we in the business of adding features to 6.5.*,
even little ones? Maybe it should only go in current.
regards, tom lane
On Tue, 31 Aug 1999, Tom Lane wrote:
> Massimo Dal Zotto <dz@wizard.net> writes:
> > May I ask that the patches I submitted two months ago for 6.5.0 are applied
> > at least to 6.5.2?
> > Here is the 6.5.1 version of my patches.
>
> I don't much care for QueryLimit (we got rid of that for a reason!)
> nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe
> enough... but are we in the business of adding features to 6.5.*,
> even little ones? Maybe it should only go in current.
6.5.x is supposed to be *only* fixes, no new features...but I'm curious as
to why these never got into v6.5.0 in the first place...
Massimo?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> On Tue, 31 Aug 1999, Tom Lane wrote: > > > Massimo Dal Zotto <dz@wizard.net> writes: > > > May I ask that the patches I submitted two months ago for 6.5.0 are applied > > > at least to 6.5.2? > > > Here is the 6.5.1 version of my patches. > > > > I don't much care for QueryLimit (we got rid of that for a reason!) > > nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe > > enough... but are we in the business of adding features to 6.5.*, > > even little ones? Maybe it should only go in current. > > 6.5.x is supposed to be *only* fixes, no new features...but I'm curious as > to why these never got into v6.5.0 in the first place... Because they were submitted a few days before the realease date. Bruce told me they would go in 6.5.1 but apparently he has forgot them. I hope to see them in 6.5.2. -- Massimo Dal Zotto +----------------------------------------------------------------------+ | Massimo Dal Zotto email: dz@cs.unitn.it | | Via Marconi, 141 phone: ++39-0461534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: finger dz@tango.cs.unitn.it | +----------------------------------------------------------------------+
> Massimo Dal Zotto <dz@wizard.net> writes: > > May I ask that the patches I submitted two months ago for 6.5.0 are applied > > at least to 6.5.2? > > Here is the 6.5.1 version of my patches. > > I don't much care for QueryLimit (we got rid of that for a reason!) > nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe > enough... but are we in the business of adding features to 6.5.*, > even little ones? Maybe it should only go in current. The QueryLimit has been reintroduced because it can be used to set a global default limit for all queries instead of hacking manually some hundred queries. I admit that the LIMIT...OFFSET is a cleaner way to do it, but having the possibility to specify a global default doesn't hurt. The default can always be overriden with an explicit LIMIT on a single query. The patch uses the same mechanism of the LIMIT clause, so it's safe. It is only a different way to set the limit value. The FREE_TUPLE_MEMORY is a temporary fix to avoid huge memory growth in some common situations, until the memory management is rewritten in a better way. Being a little conditional code in a very few places of the sources it can be safely applied and left disabled. Those few people who need the feature, like me, can enable it at their own risk. I admit that this is a kludge but the alternative is in some cases a machine with some gigabyte of memory. -- Massimo Dal Zotto +----------------------------------------------------------------------+ | Massimo Dal Zotto email: dz@cs.unitn.it | | Via Marconi, 141 phone: ++39-0461534251 | | 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | | Italy pgp: finger dz@tango.cs.unitn.it | +----------------------------------------------------------------------+
Massimo Dal Zotto <dz@wizard.net> writes:
>> I don't much care for QueryLimit (we got rid of that for a reason!)
> The QueryLimit has been reintroduced because it can be used to set a global
> default limit for all queries instead of hacking manually some hundred
> queries. I admit that the LIMIT...OFFSET is a cleaner way to do it, but
> having the possibility to specify a global default doesn't hurt.
Yes it does: it creates the possibility of breaking (returning
incomplete answers to) queries inside rules, triggers, procedures, etc.
In the worst case it could be used by an unprivileged user to subvert
security checks built into a database by means of rules.
I think this "feature" is far too dangerous to put into the general
distribution.
What would be reasonably safe is a limit that applies *only* to data
being returned to the interactive user, but that would be a different
mechanism than the LIMIT clause; I'm not sure where it would need to
be implemented.
regards, tom lane
> >On Sun, 29 Aug 1999, Tom Lane wrote: > > > >> Tatsuo Ishii <t-ishii@sra.co.jp> writes: > >> > Are we going to release 6.5.2? If yes, then when? > >> > >> Marc proposed Sept 1 (back on 8/15), and there were no objections... > > > >And its still the date I'm planning around...So Wednesday this week :) > > Marc, > > Could you make a tarball of 6.5.2-beta or 6.5.2-release-candidate or > whatever so that volunteers could get it by anon ftp for testing? I am now back, and have not yet branded the release as 6.5.2. I can do it tonight. -- 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 Tue, 31 Aug 1999, Tom Lane wrote: > > > > > Massimo Dal Zotto <dz@wizard.net> writes: > > > > May I ask that the patches I submitted two months ago for 6.5.0 are applied > > > > at least to 6.5.2? > > > > Here is the 6.5.1 version of my patches. > > > > > > I don't much care for QueryLimit (we got rid of that for a reason!) > > > nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe > > > enough... but are we in the business of adding features to 6.5.*, > > > even little ones? Maybe it should only go in current. > > > > 6.5.x is supposed to be *only* fixes, no new features...but I'm curious as > > to why these never got into v6.5.0 in the first place... > > Because they were submitted a few days before the realease date. Bruce told > me they would go in 6.5.1 but apparently he has forgot them. I hope to see > them in 6.5.2. > Oh, I did? I forgot. Let me try 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
> On Tue, 31 Aug 1999, Tom Lane wrote: > > > Massimo Dal Zotto <dz@wizard.net> writes: > > > May I ask that the patches I submitted two months ago for 6.5.0 are applied > > > at least to 6.5.2? > > > Here is the 6.5.1 version of my patches. > > > > I don't much care for QueryLimit (we got rid of that for a reason!) > > nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe > > enough... but are we in the business of adding features to 6.5.*, > > even little ones? Maybe it should only go in current. > > 6.5.x is supposed to be *only* fixes, no new features...but I'm curious as > to why these never got into v6.5.0 in the first place... > I applied the safe ones, like the copy.c one. People objected to most of the others, for reasons I have forgotten. -- 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 Tue, 31 Aug 1999, Tom Lane wrote:
> >
> > > Massimo Dal Zotto <dz@wizard.net> writes:
> > > > May I ask that the patches I submitted two months ago for 6.5.0 are applied
> > > > at least to 6.5.2?
> > > > Here is the 6.5.1 version of my patches.
> > >
> > > I don't much care for QueryLimit (we got rid of that for a reason!)
> > > nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe
> > > enough... but are we in the business of adding features to 6.5.*,
> > > even little ones? Maybe it should only go in current.
> >
> > 6.5.x is supposed to be *only* fixes, no new features...but I'm curious as
> > to why these never got into v6.5.0 in the first place...
> >
>
> I applied the safe ones, like the copy.c one. People objected to most
> of the others, for reasons I have forgotten.
Most objections were beacause they were submitted just before the release
date of 6.5.0. Now three months have passed.
Which were the unsafe pathes? If an unsafe patch is one that can break
some essential piece of code I would classify them in the following way:
array safe, important bug fix to my contrib
contrib safe, changes to makefiles in my contrib
copy-cancel-query safe, it can't break anything unless you hit ^C
emacs-vars safe, only cosmetic changes required by emacs20
free-tuple-mem safe, it is under #ifdef and disabled by default. I won't recommend enabling it in a
production environment, but it could be the solution of many headaches for some people, like my old sinval
patch.
psql-readline safe, it just sets a readline documented variable
set-variable mostly safe, except the queryLimit stuff which can be removed if you don't trust it.
Thepg_options variable can be set only by the superuser.
If you don't like the queryLimit stuff I can send you a new patch for the
pg_options variable only.
--
Massimo Dal Zotto
+----------------------------------------------------------------------+
| Massimo Dal Zotto email: dz@cs.unitn.it |
| Via Marconi, 141 phone: ++39-0461534251 |
| 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ |
| Italy pgp: finger dz@tango.cs.unitn.it |
+----------------------------------------------------------------------+
> > On Sun, 29 Aug 1999, Tom Lane wrote: > > > > > Tatsuo Ishii <t-ishii@sra.co.jp> writes: > > > > Are we going to release 6.5.2? If yes, then when? > > > > > > Marc proposed Sept 1 (back on 8/15), and there were no objections... > > > > And its still the date I'm planning around...So Wednesday this week :) > > > > May I ask that the patches I submitted two months ago for 6.5.0 are applied > at least to 6.5.2? > > Here is the 6.5.1 version of my patches. I have applied these to 6.6. 6.5.* is only major bug fixes, not even minor fixes. I applied the contrib, copy-cancel, emacs-vars(for trace.* only), psql readline(already applied), and set_variable (pg_options only, query_limit was removed and I don't have agreement to re-add it.) I skipped the tuple-freemem because someone complained it was a hack. Hopefully we can address it properly before 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, Pennsylvania 19026
> Massimo Dal Zotto <dz@wizard.net> writes: > > May I ask that the patches I submitted two months ago for 6.5.0 are applied > > at least to 6.5.2? > > Here is the 6.5.1 version of my patches. > > I don't much care for QueryLimit (we got rid of that for a reason!) > nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe > enough... but are we in the business of adding features to 6.5.*, > even little ones? Maybe it should only go in current. Applied to 6.6 only, without tuple memory or query limit fix. -- 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
> Most objections were beacause they were submitted just before the release > date of 6.5.0. Now three months have passed. > Which were the unsafe pathes? If an unsafe patch is one that can break > some essential piece of code I would classify them in the following way: > > array safe, important bug fix to my contrib Applied. > > contrib safe, changes to makefiles in my contrib Applied. > > copy-cancel-query safe, it can't break anything unless you hit ^C Applied. > > emacs-vars safe, only cosmetic changes required by emacs20 Applied. > > free-tuple-mem safe, it is under #ifdef and disabled by default. > I won't recommend enabling it in a production > environment, but it could be the solution of many > headaches for some people, like my old sinval > patch. We would rather not add this code. > > psql-readline safe, it just sets a readline documented variable Applied. > set-variable mostly safe, except the queryLimit stuff which can > be removed if you don't trust it. > The pg_options variable can be set only by the > superuser. Applied, except query limit. > > If you don't like the queryLimit stuff I can send you a new patch for the > pg_options variable only. Removed manually. Thanks. I have been far behind in keeping up with patches. -- 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 wrote: > > > > > Removed manually. Thanks. I have been far behind in keeping up with > > patches. > > Looks like :) > > Well, actually running regression test emits alot of > > NOTICE: Auto-creating query reference to table <table-name> > > from inside the parser - which make most of the regression > tests fail. Not sure which of the patches introduced them > and why. Could you please take a look at it? On the things > I'm doing right now (adding fields + indices to system > catalogs and modifying code that's invoked during heap_open() > or the like) I feel much better if I get identical (+ > correct) regression results before'n'after. > Thomas, can you re-generate the regression output so my new NOTICE is in there? I tried, but there are too many errno messages differences to get just the new NOTICE stuff in there. -- 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 wrote: > > > > > Removed manually. Thanks. I have been far behind in keeping up with > > patches. > > Looks like :) > > Well, actually running regression test emits alot of > > NOTICE: Auto-creating query reference to table <table-name> > > from inside the parser - which make most of the regression > tests fail. Not sure which of the patches introduced them > and why. Could you please take a look at it? On the things > I'm doing right now (adding fields + indices to system > catalogs and modifying code that's invoked during heap_open() > or the like) I feel much better if I get identical (+ > correct) regression results before'n'after. I have backed this change out. I will re-enable it when things are quiet and the regression tests can be re-generated. -- 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 wrote:
> >
> > >
> > > Removed manually. Thanks. I have been far behind in keeping up with
> > > patches.
> >
> > Looks like :)
> >
> > Well, actually running regression test emits alot of
> >
> > NOTICE: Auto-creating query reference to table <table-name>
> >
> > from inside the parser - which make most of the regression
> > tests fail. Not sure which of the patches introduced them
> > and why. Could you please take a look at it? On the things
> > I'm doing right now (adding fields + indices to system
> > catalogs and modifying code that's invoked during heap_open()
> > or the like) I feel much better if I get identical (+
> > correct) regression results before'n'after.
>
> I have backed this change out. I will re-enable it when things are
> quiet and the regression tests can be re-generated.
[pgsql@hot] ~/devel/src/test/regress > ./checkresults
====== int2 ======
10c10
< ERROR: pg_atoi: error reading "100000": Numerical result out of range
---
> ERROR: pg_atoi: error reading "100000": Math result not representable
====== int4 ======
10c10
< ERROR: pg_atoi: error reading "1000000000000": Numerical result out of range
---
> ERROR: pg_atoi: error reading "1000000000000": Math result not representable
[pgsql@hot] ~/devel/src/test/regress >
Such a regression result while we're in the middle of feature
development.
I'm really impressed - if we only can keep it on this level!
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #