Thread: To be 7.1.3 or not to be 7.1.3?
Hi guys, Just wondering if we are going to release a version 7.1.3 or not? Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
I'm missing an email here somewhere, and apologize ... I'm just getting my mailboxes back in order now after moving to a dial-up link vs high speed (moved to a non-high-speed neighboorhood *sigh*) ... Tom, can you resend that list of changes you sent to me earlier? On Tue, 7 Aug 2001, Justin Clift wrote: > Hi guys, > > Just wondering if we are going to release a version 7.1.3 or not? > > Regards and best wishes, > > Justin Clift > > -- > "My grandfather once told me that there are two kinds of people: those > who work and those who take the credit. He told me to try to be in the > first group; there was less competition there." > - Indira Gandhi > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
"Marc G. Fournier" <scrappy@hub.org> writes:
> (moved to a non-high-speed neighboorhood *sigh*) ...
Ugh :-(
> Tom, can you resend that list of changes you sent to me earlier?
Attached is the updated list. Note there are a couple of changes listed
that aren't actually in REL7_1_STABLE yet, but if we are going to make
a release it would be easy and profitable to back-patch them. I will
be happy to take care of that gruntwork if we decide on a release.
regards, tom lane
2001-08-03 16:14 tgl
* src/bin/pg_dump/: pg_dump.c, pg_dump.h (REL7_1_STABLE):Back-patch fixes for dumping user-defined types and
dumpingcommentson views.
2001-07-31 14:39 tgl
* src/: backend/optimizer/path/allpaths.c,backend/optimizer/util/clauses.c,
backend/utils/adt/ruleutils.c,include/optimizer/clauses.h(REL7_1_STABLE): Fix optimizer tonot try to push WHEREclauses
downinto a sub-SELECT that has a DISTINCT ON clause, perbug report from Anthony Wood. While at it, improve
theDISTINCT-ON-clauserecognizer routine to not be fooled by out-of-order DISTINCT lists. Also, back-patch earlier fix
tonot pushdown into sub-SELECT with LIMIT.
2001-07-29 18:12 tgl
* src/bin/pg_dump/: pg_dump.c (REL7_1_STABLE), pg_dump.c: Arrangefor GRANT/REVOKE on a view to be dumped at the right
time,namelyafter the view definition rather than before it. Bug introduced in7.1 by changes to dump stuff in OID
ordering.
2001-07-16 13:57 tgl
* src/backend/optimizer/path/allpaths.c: Do not push down qualsinto subqueries that have LIMIT/OFFSET clauses, since
theaddedqual could change the set of rows that get past the LIMIT. Perdiscussion on pgsql-sql 7/15/01.
2001-07-11 17:53 momjian
* src/backend/commands/copy.c: Disable COPY TO/FROM on views.
2001-07-05 22:13 ishii
* doc/src/sgml/backup.sgml (REL7_1_STABLE): Fix typo. createdb -t--> createdb -T
2001-07-03 12:49 tgl
* src/backend/utils/init/miscinit.c: Don't go into infinite loop if/home/postgres/testversion/data directory is not
writable.
2001-07-02 15:31 tgl
* src/test/regress/expected/: abstime-solaris-1947.out,abstime.out: Update abstime expected results to
matchpost-30-June-2001reality. Probably the right fix is to remove'current' special value entirely, but I don't want
toseeregression test failures until that happens.
2001-06-29 12:34 tgl
* src/backend/commands/: vacuum.c (REL7_1_STABLE), vacuum.c: Fixlongstanding error in VACUUM: sometimes would examine a
bufferpageafter writing/unpinning it. An actual failure is unlikely, unlessthe system is tremendously short of buffers
...but a bug is a bug.
2001-06-12 21:02 tgl
* src/pl/plpgsql/src/pl_exec.c (REL7_1_STABLE): Back-patch fix forattempt to pfree a value that's not palloc'd (it's a
fieldof atuple). I see Jan has already fixed this in current sources, but7.1.* is pretty badly broken here.
2001-06-12 14:54 tgl
* src/backend/rewrite/: rewriteHandler.c (REL7_1_STABLE),rewriteHandler.c: Repair problem with multi-action rules
incombinationwith any nontrivial manipulation of rtable/jointree byplanner. Rewriter was generating actions that
sharedrtable/jointreesubstructure, which caused havoc when planner gotto the later actions that it'd already mucked
up.
2001-06-06 14:54 wieck
* src/pl/plpgsql/src/gram.y: Patch from Ian Lance Taylor fixingmultiple cursor arguments and buffer zero
termination.Jan
2001-06-06 13:18 tgl
* src/backend/access/transam/xlog.c (REL7_1_STABLE): Back-patchchange to not keep WAL segments just for UNDO
information.
2001-05-31 17:49 momjian
* doc/src/sgml/: release.sgml (REL7_1_STABLE), release.sgml: ForgotSGML section section id tag for 7.1.
2001-05-31 13:32 tgl
* src/backend/utils/adt/: ri_triggers.c (REL7_1_STABLE),ri_triggers.c: RI triggers would fail for datatypes using
old-styleequalfunction, because cached fmgr info contained reference to ashorter-lived data structure. Also guard
againstpossibility thatfmgr_info could fail, leaving an incomplete entry present in thehash table.
2001-05-27 21:00 ishii
* src/backend/utils/mb/: conv.c (REL7_1_STABLE), conv.c: Fix amessage error in utf_to_local
If we decide to release 7.1.3 I'd like to see our patch for contrib/intarray too. Oleg On Tue, 7 Aug 2001, Tom Lane wrote: > "Marc G. Fournier" <scrappy@hub.org> writes: > > (moved to a non-high-speed neighboorhood *sigh*) ... > > Ugh :-( > > > Tom, can you resend that list of changes you sent to me earlier? > > Attached is the updated list. Note there are a couple of changes listed > that aren't actually in REL7_1_STABLE yet, but if we are going to make > a release it would be easy and profitable to back-patch them. I will > be happy to take care of that gruntwork if we decide on a release. > > regards, tom lane > > > 2001-08-03 16:14 tgl > > * src/bin/pg_dump/: pg_dump.c, pg_dump.h (REL7_1_STABLE): > Back-patch fixes for dumping user-defined types and dumping > comments on views. > > 2001-07-31 14:39 tgl > > * src/: backend/optimizer/path/allpaths.c, > backend/optimizer/util/clauses.c, backend/utils/adt/ruleutils.c, > include/optimizer/clauses.h (REL7_1_STABLE): Fix optimizer to > not try to push WHERE > clauses down into a sub-SELECT that has a DISTINCT ON clause, per > bug report from Anthony Wood. While at it, improve the > DISTINCT-ON-clause recognizer routine to not be fooled by out- > of-order DISTINCT lists. Also, back-patch earlier fix to not push > down into sub-SELECT with LIMIT. > > 2001-07-29 18:12 tgl > > * src/bin/pg_dump/: pg_dump.c (REL7_1_STABLE), pg_dump.c: Arrange > for GRANT/REVOKE on a view to be dumped at the right time, namely > after the view definition rather than before it. Bug introduced in > 7.1 by changes to dump stuff in OID ordering. > > 2001-07-16 13:57 tgl > > * src/backend/optimizer/path/allpaths.c: Do not push down quals > into subqueries that have LIMIT/OFFSET clauses, since the added > qual could change the set of rows that get past the LIMIT. Per > discussion on pgsql-sql 7/15/01. > > 2001-07-11 17:53 momjian > > * src/backend/commands/copy.c: Disable COPY TO/FROM on views. > > 2001-07-05 22:13 ishii > > * doc/src/sgml/backup.sgml (REL7_1_STABLE): Fix typo. createdb -t > --> createdb -T > > 2001-07-03 12:49 tgl > > * src/backend/utils/init/miscinit.c: Don't go into infinite loop if > /home/postgres/testversion/data directory is not writable. > > 2001-07-02 15:31 tgl > > * src/test/regress/expected/: abstime-solaris-1947.out, > abstime.out: Update abstime expected results to match > post-30-June-2001 reality. Probably the right fix is to remove > 'current' special value entirely, but I don't want to see > regression test failures until that happens. > > 2001-06-29 12:34 tgl > > * src/backend/commands/: vacuum.c (REL7_1_STABLE), vacuum.c: Fix > longstanding error in VACUUM: sometimes would examine a buffer page > after writing/unpinning it. An actual failure is unlikely, unless > the system is tremendously short of buffers ... but a bug is a bug. > > 2001-06-12 21:02 tgl > > * src/pl/plpgsql/src/pl_exec.c (REL7_1_STABLE): Back-patch fix for > attempt to pfree a value that's not palloc'd (it's a field of a > tuple). I see Jan has already fixed this in current sources, but > 7.1.* is pretty badly broken here. > > 2001-06-12 14:54 tgl > > * src/backend/rewrite/: rewriteHandler.c (REL7_1_STABLE), > rewriteHandler.c: Repair problem with multi-action rules in > combination with any nontrivial manipulation of rtable/jointree by > planner. Rewriter was generating actions that shared > rtable/jointree substructure, which caused havoc when planner got > to the later actions that it'd already mucked up. > > 2001-06-06 14:54 wieck > > * src/pl/plpgsql/src/gram.y: Patch from Ian Lance Taylor fixing > multiple cursor arguments and buffer zero termination. > > Jan > > 2001-06-06 13:18 tgl > > * src/backend/access/transam/xlog.c (REL7_1_STABLE): Back-patch > change to not keep WAL segments just for UNDO information. > > 2001-05-31 17:49 momjian > > * doc/src/sgml/: release.sgml (REL7_1_STABLE), release.sgml: Forgot > SGML section section id tag for 7.1. > > 2001-05-31 13:32 tgl > > * src/backend/utils/adt/: ri_triggers.c (REL7_1_STABLE), > ri_triggers.c: RI triggers would fail for datatypes using old-style > equal function, because cached fmgr info contained reference to a > shorter-lived data structure. Also guard against possibility that > fmgr_info could fail, leaving an incomplete entry present in the > hash table. > > 2001-05-27 21:00 ishii > > * src/backend/utils/mb/: conv.c (REL7_1_STABLE), conv.c: Fix a > message error in utf_to_local > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl > 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
On Tue, 7 Aug 2001, Tom Lane wrote: > Oleg Bartunov <oleg@sai.msu.su> writes: > > If we decide to release 7.1.3 I'd like to see our patch for > > contrib/intarray too. > > Which one? Patch I've submitted last week. It's in current CVS http://fts.postgresql.org/db/mw/msg.html?mid=1028099 om, please apply attached patch to current CVS. 1. Fixed error with empty array ( '{}' ), test data changed to include such data 2. Test a dimension of an array ( we support only one-dimension) Regards, Oleg > > regards, tom lane > 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
The list looks good to me as far as doing a v7.1.3 ... anyone object to it? On Tue, 7 Aug 2001, Oleg Bartunov wrote: > If we decide to release 7.1.3 I'd like to see our patch for > contrib/intarray too. > > Oleg > On Tue, 7 Aug 2001, Tom Lane wrote: > > > "Marc G. Fournier" <scrappy@hub.org> writes: > > > (moved to a non-high-speed neighboorhood *sigh*) ... > > > > Ugh :-( > > > > > Tom, can you resend that list of changes you sent to me earlier? > > > > Attached is the updated list. Note there are a couple of changes listed > > that aren't actually in REL7_1_STABLE yet, but if we are going to make > > a release it would be easy and profitable to back-patch them. I will > > be happy to take care of that gruntwork if we decide on a release. > > > > regards, tom lane > > > > > > 2001-08-03 16:14 tgl > > > > * src/bin/pg_dump/: pg_dump.c, pg_dump.h (REL7_1_STABLE): > > Back-patch fixes for dumping user-defined types and dumping > > comments on views. > > > > 2001-07-31 14:39 tgl > > > > * src/: backend/optimizer/path/allpaths.c, > > backend/optimizer/util/clauses.c, backend/utils/adt/ruleutils.c, > > include/optimizer/clauses.h (REL7_1_STABLE): Fix optimizer to > > not try to push WHERE > > clauses down into a sub-SELECT that has a DISTINCT ON clause, per > > bug report from Anthony Wood. While at it, improve the > > DISTINCT-ON-clause recognizer routine to not be fooled by out- > > of-order DISTINCT lists. Also, back-patch earlier fix to not push > > down into sub-SELECT with LIMIT. > > > > 2001-07-29 18:12 tgl > > > > * src/bin/pg_dump/: pg_dump.c (REL7_1_STABLE), pg_dump.c: Arrange > > for GRANT/REVOKE on a view to be dumped at the right time, namely > > after the view definition rather than before it. Bug introduced in > > 7.1 by changes to dump stuff in OID ordering. > > > > 2001-07-16 13:57 tgl > > > > * src/backend/optimizer/path/allpaths.c: Do not push down quals > > into subqueries that have LIMIT/OFFSET clauses, since the added > > qual could change the set of rows that get past the LIMIT. Per > > discussion on pgsql-sql 7/15/01. > > > > 2001-07-11 17:53 momjian > > > > * src/backend/commands/copy.c: Disable COPY TO/FROM on views. > > > > 2001-07-05 22:13 ishii > > > > * doc/src/sgml/backup.sgml (REL7_1_STABLE): Fix typo. createdb -t > > --> createdb -T > > > > 2001-07-03 12:49 tgl > > > > * src/backend/utils/init/miscinit.c: Don't go into infinite loop if > > /home/postgres/testversion/data directory is not writable. > > > > 2001-07-02 15:31 tgl > > > > * src/test/regress/expected/: abstime-solaris-1947.out, > > abstime.out: Update abstime expected results to match > > post-30-June-2001 reality. Probably the right fix is to remove > > 'current' special value entirely, but I don't want to see > > regression test failures until that happens. > > > > 2001-06-29 12:34 tgl > > > > * src/backend/commands/: vacuum.c (REL7_1_STABLE), vacuum.c: Fix > > longstanding error in VACUUM: sometimes would examine a buffer page > > after writing/unpinning it. An actual failure is unlikely, unless > > the system is tremendously short of buffers ... but a bug is a bug. > > > > 2001-06-12 21:02 tgl > > > > * src/pl/plpgsql/src/pl_exec.c (REL7_1_STABLE): Back-patch fix for > > attempt to pfree a value that's not palloc'd (it's a field of a > > tuple). I see Jan has already fixed this in current sources, but > > 7.1.* is pretty badly broken here. > > > > 2001-06-12 14:54 tgl > > > > * src/backend/rewrite/: rewriteHandler.c (REL7_1_STABLE), > > rewriteHandler.c: Repair problem with multi-action rules in > > combination with any nontrivial manipulation of rtable/jointree by > > planner. Rewriter was generating actions that shared > > rtable/jointree substructure, which caused havoc when planner got > > to the later actions that it'd already mucked up. > > > > 2001-06-06 14:54 wieck > > > > * src/pl/plpgsql/src/gram.y: Patch from Ian Lance Taylor fixing > > multiple cursor arguments and buffer zero termination. > > > > Jan > > > > 2001-06-06 13:18 tgl > > > > * src/backend/access/transam/xlog.c (REL7_1_STABLE): Back-patch > > change to not keep WAL segments just for UNDO information. > > > > 2001-05-31 17:49 momjian > > > > * doc/src/sgml/: release.sgml (REL7_1_STABLE), release.sgml: Forgot > > SGML section section id tag for 7.1. > > > > 2001-05-31 13:32 tgl > > > > * src/backend/utils/adt/: ri_triggers.c (REL7_1_STABLE), > > ri_triggers.c: RI triggers would fail for datatypes using old-style > > equal function, because cached fmgr info contained reference to a > > shorter-lived data structure. Also guard against possibility that > > fmgr_info could fail, leaving an incomplete entry present in the > > hash table. > > > > 2001-05-27 21:00 ishii > > > > * src/backend/utils/mb/: conv.c (REL7_1_STABLE), conv.c: Fix a > > message error in utf_to_local > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 6: Have you searched our list archives? > > > > http://www.postgresql.org/search.mpl > > > > 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 > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
"Marc G. Fournier" <scrappy@hub.org> writes:
> The list looks good to me as far as doing a v7.1.3 ... anyone object to
> it?
Okay, I'll wrap up the last couple of back-patches this evening...
regards, tom lane
On Mié 08 Ago 2001 18:29, Tom Lane wrote:
> "Marc G. Fournier" <scrappy@hub.org> writes:
> > The list looks good to me as far as doing a v7.1.3 ... anyone object to
> > it?
>
> Okay, I'll wrap up the last couple of back-patches this evening...
When could 7.1.3 be out? I'm very interested in the patch to the
rewriteHandler.c file. I have just finished recompiling postgres wth the
patched version of the rewriteHandler.c, but would like to have a stable
7.1.3 version comiled on the main SQL server.
Saludos... ;-)
--
Cualquiera administra un NT.
Ese es el problema, que cualquiera administre.
-----------------------------------------------------------------
Martin Marques | mmarques@unl.edu.ar
Programador, Administrador | Centro de Telematica Universidad Nacional
del Litoral
-----------------------------------------------------------------
On Wed, 8 Aug 2001, Marc G. Fournier wrote: > > > The list looks good to me as far as doing a v7.1.3 ... anyone object to > it? Not me, but I'm curious as to how far away 7.2 is? Vince. > > On Tue, 7 Aug 2001, Oleg Bartunov wrote: > > > If we decide to release 7.1.3 I'd like to see our patch for > > contrib/intarray too. > > > > Oleg > > On Tue, 7 Aug 2001, Tom Lane wrote: > > > > > "Marc G. Fournier" <scrappy@hub.org> writes: > > > > (moved to a non-high-speed neighboorhood *sigh*) ... > > > > > > Ugh :-( > > > > > > > Tom, can you resend that list of changes you sent to me earlier? > > > > > > Attached is the updated list. Note there are a couple of changes listed > > > that aren't actually in REL7_1_STABLE yet, but if we are going to make > > > a release it would be easy and profitable to back-patch them. I will > > > be happy to take care of that gruntwork if we decide on a release. > > > > > > regards, tom lane > > > > > > > > > 2001-08-03 16:14 tgl > > > > > > * src/bin/pg_dump/: pg_dump.c, pg_dump.h (REL7_1_STABLE): > > > Back-patch fixes for dumping user-defined types and dumping > > > comments on views. > > > > > > 2001-07-31 14:39 tgl > > > > > > * src/: backend/optimizer/path/allpaths.c, > > > backend/optimizer/util/clauses.c, backend/utils/adt/ruleutils.c, > > > include/optimizer/clauses.h (REL7_1_STABLE): Fix optimizer to > > > not try to push WHERE > > > clauses down into a sub-SELECT that has a DISTINCT ON clause, per > > > bug report from Anthony Wood. While at it, improve the > > > DISTINCT-ON-clause recognizer routine to not be fooled by out- > > > of-order DISTINCT lists. Also, back-patch earlier fix to not push > > > down into sub-SELECT with LIMIT. > > > > > > 2001-07-29 18:12 tgl > > > > > > * src/bin/pg_dump/: pg_dump.c (REL7_1_STABLE), pg_dump.c: Arrange > > > for GRANT/REVOKE on a view to be dumped at the right time, namely > > > after the view definition rather than before it. Bug introduced in > > > 7.1 by changes to dump stuff in OID ordering. > > > > > > 2001-07-16 13:57 tgl > > > > > > * src/backend/optimizer/path/allpaths.c: Do not push down quals > > > into subqueries that have LIMIT/OFFSET clauses, since the added > > > qual could change the set of rows that get past the LIMIT. Per > > > discussion on pgsql-sql 7/15/01. > > > > > > 2001-07-11 17:53 momjian > > > > > > * src/backend/commands/copy.c: Disable COPY TO/FROM on views. > > > > > > 2001-07-05 22:13 ishii > > > > > > * doc/src/sgml/backup.sgml (REL7_1_STABLE): Fix typo. createdb -t > > > --> createdb -T > > > > > > 2001-07-03 12:49 tgl > > > > > > * src/backend/utils/init/miscinit.c: Don't go into infinite loop if > > > /home/postgres/testversion/data directory is not writable. > > > > > > 2001-07-02 15:31 tgl > > > > > > * src/test/regress/expected/: abstime-solaris-1947.out, > > > abstime.out: Update abstime expected results to match > > > post-30-June-2001 reality. Probably the right fix is to remove > > > 'current' special value entirely, but I don't want to see > > > regression test failures until that happens. > > > > > > 2001-06-29 12:34 tgl > > > > > > * src/backend/commands/: vacuum.c (REL7_1_STABLE), vacuum.c: Fix > > > longstanding error in VACUUM: sometimes would examine a buffer page > > > after writing/unpinning it. An actual failure is unlikely, unless > > > the system is tremendously short of buffers ... but a bug is a bug. > > > > > > 2001-06-12 21:02 tgl > > > > > > * src/pl/plpgsql/src/pl_exec.c (REL7_1_STABLE): Back-patch fix for > > > attempt to pfree a value that's not palloc'd (it's a field of a > > > tuple). I see Jan has already fixed this in current sources, but > > > 7.1.* is pretty badly broken here. > > > > > > 2001-06-12 14:54 tgl > > > > > > * src/backend/rewrite/: rewriteHandler.c (REL7_1_STABLE), > > > rewriteHandler.c: Repair problem with multi-action rules in > > > combination with any nontrivial manipulation of rtable/jointree by > > > planner. Rewriter was generating actions that shared > > > rtable/jointree substructure, which caused havoc when planner got > > > to the later actions that it'd already mucked up. > > > > > > 2001-06-06 14:54 wieck > > > > > > * src/pl/plpgsql/src/gram.y: Patch from Ian Lance Taylor fixing > > > multiple cursor arguments and buffer zero termination. > > > > > > Jan > > > > > > 2001-06-06 13:18 tgl > > > > > > * src/backend/access/transam/xlog.c (REL7_1_STABLE): Back-patch > > > change to not keep WAL segments just for UNDO information. > > > > > > 2001-05-31 17:49 momjian > > > > > > * doc/src/sgml/: release.sgml (REL7_1_STABLE), release.sgml: Forgot > > > SGML section section id tag for 7.1. > > > > > > 2001-05-31 13:32 tgl > > > > > > * src/backend/utils/adt/: ri_triggers.c (REL7_1_STABLE), > > > ri_triggers.c: RI triggers would fail for datatypes using old-style > > > equal function, because cached fmgr info contained reference to a > > > shorter-lived data structure. Also guard against possibility that > > > fmgr_info could fail, leaving an incomplete entry present in the > > > hash table. > > > > > > 2001-05-27 21:00 ishii > > > > > > * src/backend/utils/mb/: conv.c (REL7_1_STABLE), conv.c: Fix a > > > message error in utf_to_local > > > > > > ---------------------------(end of broadcast)--------------------------- > > > TIP 6: Have you searched our list archives? > > > > > > http://www.postgresql.org/search.mpl > > > > > > > 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 > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Oleg Bartunov <oleg@sai.msu.su> writes: > If we decide to release 7.1.3 I'd like to see our patch for > contrib/intarray too. >> >> Which one? > Patch I've submitted last week. It's in current CVS > http://fts.postgresql.org/db/mw/msg.html?mid=1028099 That patch doesn't apply cleanly at all to REL7_1_STABLE. While I can find the corresponding code, I'm not sure that making the changes is a good idea; perhaps the patch depends on some of the previous (quite extensive) fixes to work correctly? I'm inclined to leave 7.1 alone. regards, tom lane
I said:
> Okay, I'll wrap up the last couple of back-patches this evening...
Done. A couple of the patches that I had my eye on turned out not to be
relevant to 7.1 (they were fixes in new code). So attached is the
current list of 7.1.2 -> 7.1.3 changes. Bruce, are you going to handle
the documentation updates and release branding?
regards, tom lane
2001-08-08 18:32 tgl
* src/backend/commands/copy.c (REL7_1_STABLE): Back-patch fix todisallow COPY TO/FROM a view (or anything else that's
nota plainrelation).
2001-08-08 18:25 tgl
* src/backend/utils/init/miscinit.c (REL7_1_STABLE): Back-patch fixto prevent infinite loop when $PGDATA is not
writable.
2001-08-07 14:36 momjian
* src/: backend/port/beos/support.c, backend/port/dynloader/beos.c,include/port/beos.h (REL7_1_STABLE): Commit BEOS
patchto 7.1.X.
2001-08-03 16:14 tgl
* src/bin/pg_dump/: pg_dump.c, pg_dump.h (REL7_1_STABLE):Back-patch fixes for dumping user-defined types and
dumpingcommentson views.
2001-07-31 14:39 tgl
* src/: backend/optimizer/path/allpaths.c,backend/optimizer/util/clauses.c,
backend/utils/adt/ruleutils.c,include/optimizer/clauses.h(REL7_1_STABLE): Fix optimizer to nottry to push WHERE clauses
downinto a sub-SELECT that has aDISTINCT ON clause, per bug report from Anthony Wood. While at it,improve the
DISTINCT-ON-clauserecognizer routine to not be fooledby out- of-order DISTINCT lists. Also, back-patch earlier fix
tonotpush down into sub-SELECT with LIMIT.
2001-07-29 18:12 tgl
* src/bin/pg_dump/pg_dump.c (REL7_1_STABLE): Arrange forGRANT/REVOKE on a view to be dumped at the right time, namely
aftertheview definition rather than before it. Bug introduced in 7.1by changes to dump stuff in OID ordering.
2001-07-05 22:13 ishii
* doc/src/sgml/backup.sgml (REL7_1_STABLE): Fix typo. createdb -t--> createdb -T
2001-07-02 15:34 tgl
* src/test/regress/expected/: abstime-solaris-1947.out, abstime.out(REL7_1_STABLE): In any case, it seems the REL7_1
branchneeds theupdate too...
2001-06-29 12:34 tgl
* src/backend/commands/vacuum.c (REL7_1_STABLE): Fix longstandingerror in VACUUM: sometimes would examine a buffer page
afterwriting/unpinningit. An actual failure is unlikely, unless thesystem is tremendously short of buffers ... but a
bugis a bug.
2001-06-12 21:02 tgl
* src/pl/plpgsql/src/pl_exec.c (REL7_1_STABLE): Back-patch fix forattempt to pfree a value that's not palloc'd (it's a
fieldof atuple). I see Jan has already fixed this in current sources, but7.1.* is pretty badly broken here.
2001-06-12 14:54 tgl
* src/backend/rewrite/rewriteHandler.c (REL7_1_STABLE): Repairproblem with multi-action rules in combination with any
nontrivialmanipulationof rtable/jointree by planner. Rewriter wasgenerating actions that shared rtable/jointree
substructure,whichcaused havoc when planner got to the later actions that it'dalready mucked up.
2001-06-06 13:18 tgl
* src/backend/access/transam/xlog.c (REL7_1_STABLE): Back-patchchange to not keep WAL segments just for UNDO
information.
2001-05-31 17:50 momjian
* doc/src/sgml/release.sgml (REL7_1_STABLE): Forgot SGML sectionsection id tag for 7.1.
2001-05-31 13:33 tgl
* src/backend/utils/adt/ri_triggers.c (REL7_1_STABLE): RI triggerswould fail for datatypes using old-style equal
function,becausecached fmgr info contained reference to a shorter-lived datastructure. Also guard against possibility
thatfmgr_info couldfail, leaving an incomplete entry present in the hash table.
2001-05-27 21:01 ishii
* src/backend/utils/mb/conv.c (REL7_1_STABLE): Fix a message errorin utf_to_local
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> current list of 7.1.2 -> 7.1.3 changes. Bruce, are you going to handle
>> the documentation updates and release branding?
> Yes, just tell me when to start.
I don't know of any reason to wait... anyone else?
regards, tom lane
Vince Vielhaber <vev@michvhf.com> writes:
> Not me, but I'm curious as to how far away 7.2 is?
I'd like to go beta by the end of the month.
regards, tom lane
Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> current list of 7.1.2 -> 7.1.3 changes. Bruce, are you going to handle > >> the documentation updates and release branding? > > > Yes, just tell me when to start. > > I don't know of any reason to wait... anyone else? > I have to fix my old fault in TID handling. I am able to have a cvs access now and would commit the fix to 7.1 branch. regards, Hiroshi Inoue
go for it, and I'll try and do up a v7.1.3 during the day tomorrow ... On Wed, 8 Aug 2001, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> current list of 7.1.2 -> 7.1.3 changes. Bruce, are you going to handle > >> the documentation updates and release branding? > > > Yes, just tell me when to start. > > I don't know of any reason to wait... anyone else? > > regards, tom lane >
On Wed, 8 Aug 2001, Vince Vielhaber wrote: > On Wed, 8 Aug 2001, Marc G. Fournier wrote: > > > > > > > The list looks good to me as far as doing a v7.1.3 ... anyone object to > > it? > > Not me, but I'm curious as to how far away 7.2 is? Oct-ish sometime ... > > Vince. > > > > > On Tue, 7 Aug 2001, Oleg Bartunov wrote: > > > > > If we decide to release 7.1.3 I'd like to see our patch for > > > contrib/intarray too. > > > > > > Oleg > > > On Tue, 7 Aug 2001, Tom Lane wrote: > > > > > > > "Marc G. Fournier" <scrappy@hub.org> writes: > > > > > (moved to a non-high-speed neighboorhood *sigh*) ... > > > > > > > > Ugh :-( > > > > > > > > > Tom, can you resend that list of changes you sent to me earlier? > > > > > > > > Attached is the updated list. Note there are a couple of changes listed > > > > that aren't actually in REL7_1_STABLE yet, but if we are going to make > > > > a release it would be easy and profitable to back-patch them. I will > > > > be happy to take care of that gruntwork if we decide on a release. > > > > > > > > regards, tom lane > > > > > > > > > > > > 2001-08-03 16:14 tgl > > > > > > > > * src/bin/pg_dump/: pg_dump.c, pg_dump.h (REL7_1_STABLE): > > > > Back-patch fixes for dumping user-defined types and dumping > > > > comments on views. > > > > > > > > 2001-07-31 14:39 tgl > > > > > > > > * src/: backend/optimizer/path/allpaths.c, > > > > backend/optimizer/util/clauses.c, backend/utils/adt/ruleutils.c, > > > > include/optimizer/clauses.h (REL7_1_STABLE): Fix optimizer to > > > > not try to push WHERE > > > > clauses down into a sub-SELECT that has a DISTINCT ON clause, per > > > > bug report from Anthony Wood. While at it, improve the > > > > DISTINCT-ON-clause recognizer routine to not be fooled by out- > > > > of-order DISTINCT lists. Also, back-patch earlier fix to not push > > > > down into sub-SELECT with LIMIT. > > > > > > > > 2001-07-29 18:12 tgl > > > > > > > > * src/bin/pg_dump/: pg_dump.c (REL7_1_STABLE), pg_dump.c: Arrange > > > > for GRANT/REVOKE on a view to be dumped at the right time, namely > > > > after the view definition rather than before it. Bug introduced in > > > > 7.1 by changes to dump stuff in OID ordering. > > > > > > > > 2001-07-16 13:57 tgl > > > > > > > > * src/backend/optimizer/path/allpaths.c: Do not push down quals > > > > into subqueries that have LIMIT/OFFSET clauses, since the added > > > > qual could change the set of rows that get past the LIMIT. Per > > > > discussion on pgsql-sql 7/15/01. > > > > > > > > 2001-07-11 17:53 momjian > > > > > > > > * src/backend/commands/copy.c: Disable COPY TO/FROM on views. > > > > > > > > 2001-07-05 22:13 ishii > > > > > > > > * doc/src/sgml/backup.sgml (REL7_1_STABLE): Fix typo. createdb -t > > > > --> createdb -T > > > > > > > > 2001-07-03 12:49 tgl > > > > > > > > * src/backend/utils/init/miscinit.c: Don't go into infinite loop if > > > > /home/postgres/testversion/data directory is not writable. > > > > > > > > 2001-07-02 15:31 tgl > > > > > > > > * src/test/regress/expected/: abstime-solaris-1947.out, > > > > abstime.out: Update abstime expected results to match > > > > post-30-June-2001 reality. Probably the right fix is to remove > > > > 'current' special value entirely, but I don't want to see > > > > regression test failures until that happens. > > > > > > > > 2001-06-29 12:34 tgl > > > > > > > > * src/backend/commands/: vacuum.c (REL7_1_STABLE), vacuum.c: Fix > > > > longstanding error in VACUUM: sometimes would examine a buffer page > > > > after writing/unpinning it. An actual failure is unlikely, unless > > > > the system is tremendously short of buffers ... but a bug is a bug. > > > > > > > > 2001-06-12 21:02 tgl > > > > > > > > * src/pl/plpgsql/src/pl_exec.c (REL7_1_STABLE): Back-patch fix for > > > > attempt to pfree a value that's not palloc'd (it's a field of a > > > > tuple). I see Jan has already fixed this in current sources, but > > > > 7.1.* is pretty badly broken here. > > > > > > > > 2001-06-12 14:54 tgl > > > > > > > > * src/backend/rewrite/: rewriteHandler.c (REL7_1_STABLE), > > > > rewriteHandler.c: Repair problem with multi-action rules in > > > > combination with any nontrivial manipulation of rtable/jointree by > > > > planner. Rewriter was generating actions that shared > > > > rtable/jointree substructure, which caused havoc when planner got > > > > to the later actions that it'd already mucked up. > > > > > > > > 2001-06-06 14:54 wieck > > > > > > > > * src/pl/plpgsql/src/gram.y: Patch from Ian Lance Taylor fixing > > > > multiple cursor arguments and buffer zero termination. > > > > > > > > Jan > > > > > > > > 2001-06-06 13:18 tgl > > > > > > > > * src/backend/access/transam/xlog.c (REL7_1_STABLE): Back-patch > > > > change to not keep WAL segments just for UNDO information. > > > > > > > > 2001-05-31 17:49 momjian > > > > > > > > * doc/src/sgml/: release.sgml (REL7_1_STABLE), release.sgml: Forgot > > > > SGML section section id tag for 7.1. > > > > > > > > 2001-05-31 13:32 tgl > > > > > > > > * src/backend/utils/adt/: ri_triggers.c (REL7_1_STABLE), > > > > ri_triggers.c: RI triggers would fail for datatypes using old-style > > > > equal function, because cached fmgr info contained reference to a > > > > shorter-lived data structure. Also guard against possibility that > > > > fmgr_info could fail, leaving an incomplete entry present in the > > > > hash table. > > > > > > > > 2001-05-27 21:00 ishii > > > > > > > > * src/backend/utils/mb/: conv.c (REL7_1_STABLE), conv.c: Fix a > > > > message error in utf_to_local > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > > > TIP 6: Have you searched our list archives? > > > > > > > > http://www.postgresql.org/search.mpl > > > > > > > > > > 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 > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > > TIP 4: Don't 'kill -9' the postmaster > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > > > > -- > ========================================================================== > Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net > 56K Nationwide Dialup from $16.00/mo at Pop4 Networking > Online Campground Directory http://www.camping-usa.com > Online Giftshop Superstore http://www.cloudninegifts.com > ========================================================================== > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html >
I think we are on hold for Hiroshi, right? > > go for it, and I'll try and do up a v7.1.3 during the day tomorrow ... > > On Wed, 8 Aug 2001, Tom Lane wrote: > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > >> current list of 7.1.2 -> 7.1.3 changes. Bruce, are you going to handle > > >> the documentation updates and release branding? > > > > > Yes, just tell me when to start. > > > > I don't know of any reason to wait... anyone else? > > > > regards, tom lane > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@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 <pgman@candle.pha.pa.us> writes:
> I think we are on hold for Hiroshi, right?
Yes. I believe I know which patch he's referring to --- it's the only
change in src/backend/utils/adt/tid.c since 7.1. If he hasn't committed
in a few hours I can take care of back-patching it. It must be pushing
midnight in Japan by now...
regards, tom lane
> I said: > > Okay, I'll wrap up the last couple of back-patches this evening... > > Done. A couple of the patches that I had my eye on turned out not to be > relevant to 7.1 (they were fixes in new code). So attached is the > current list of 7.1.2 -> 7.1.3 changes. Bruce, are you going to handle > the documentation updates and release branding? Yes, just tell me when to start. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Tom Lane <tgl@sss.pgh.pa.us> writes: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I think we are on hold for Hiroshi, right? > > Yes. I believe I know which patch he's referring to --- it's the only > change in src/backend/utils/adt/tid.c since 7.1. If he hasn't committed > in a few hours I can take care of back-patching it. It must be pushing > midnight in Japan by now... That's a couple of days ago now... anything happening? -- Trond Eivind Glomsrød Red Hat, Inc.
> Tom Lane wrote: > > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > >> current list of 7.1.2 -> 7.1.3 changes. Bruce, are you going to handle > > >> the documentation updates and release branding? > > > > > Yes, just tell me when to start. > > > > I don't know of any reason to wait... anyone else? > > > > I have to fix my old fault in TID handling. > I am able to have a cvs access now and would > commit the fix to 7.1 branch. Hiroshi, are you done with changes you want in 7.1.3? -- Bruce Momjian | http://candle.pha.pa.us pgman@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
teg@redhat.com (Trond Eivind Glomsrød) writes:
> That's a couple of days ago now... anything happening?
Bruce is evidently waiting on Hiroshi's confirmation that he's done
applying his back-patches. I believe he is, though; he did apply
what I thought was the patch he had in mind.
Bruce, have you finished the documentation updates, or is that still
open? You could probably get that done while waiting for Hiroshi's
answer...
regards, tom lane
> teg@redhat.com (Trond Eivind Glomsrød) writes: > > That's a couple of days ago now... anything happening? > > Bruce is evidently waiting on Hiroshi's confirmation that he's done > applying his back-patches. I believe he is, though; he did apply > what I thought was the patch he had in mind. Yes, but I wanted him to state that. > Bruce, have you finished the documentation updates, or is that still > open? You could probably get that done while waiting for Hiroshi's > answer... All I need to do is go through CVS. -- Bruce Momjian | http://candle.pha.pa.us pgman@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: > > > Tom Lane wrote: > > > > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > >> current list of 7.1.2 -> 7.1.3 changes. Bruce, are you going to handle > > > >> the documentation updates and release branding? > > > > > > > Yes, just tell me when to start. > > > > > > I don't know of any reason to wait... anyone else? > > > > > > > I have to fix my old fault in TID handling. > > I am able to have a cvs access now and would > > commit the fix to 7.1 branch. > > Hiroshi, are you done with changes you want in 7.1.3? > Oops I missed your mail sorry. Unfortunately my mail server is down and I could access pgsql-hackers only by the news server. My answer is Yes. regards, Hiroshi Inoue
Oleg Bartunov <oleg@sai.msu.su> writes:
> If we decide to release 7.1.3 I'd like to see our patch for
> contrib/intarray too.
Which one?
regards, tom lane
I will get on this today. > teg@redhat.com (Trond Eivind Glomsrød) writes: > > That's a couple of days ago now... anything happening? > > Bruce is evidently waiting on Hiroshi's confirmation that he's done > applying his back-patches. I believe he is, though; he did apply > what I thought was the patch he had in mind. > > Bruce, have you finished the documentation updates, or is that still > open? You could probably get that done while waiting for Hiroshi's > answer... > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@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
let me know once you are complete, and i'll wrap her up ... On Tue, 14 Aug 2001, Bruce Momjian wrote: > > I will get on this today. > > > teg@redhat.com (Trond Eivind Glomsrød) writes: > > > That's a couple of days ago now... anything happening? > > > > Bruce is evidently waiting on Hiroshi's confirmation that he's done > > applying his back-patches. I believe he is, though; he did apply > > what I thought was the patch he had in mind. > > > > Bruce, have you finished the documentation updates, or is that still > > open? You could probably get that done while waiting for Hiroshi's > > answer... > > > > regards, tom lane > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@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 >
On Tuesday 07 August 2001 14:56, Tom Lane wrote: Ok. This is the second time I have seen this message -- but this one is delayed by a week. Marc? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> > > I have to fix my old fault in TID handling. > > > I am able to have a cvs access now and would > > > commit the fix to 7.1 branch. > > > > Hiroshi, are you done with changes you want in 7.1.3? > > > > Oops I missed your mail sorry. Unfortunately my mail server > is down and I could access pgsql-hackers only by the news server. > > My answer is Yes. OK, 7.1.3 is packaged and ready to go, date stamped Auguest 15. Can people with cvs 7.1 branches review it? -- Bruce Momjian | http://candle.pha.pa.us pgman@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
> OK, 7.1.3 is packaged and ready to go, date stamped Auguest 15. Can > people with cvs 7.1 branches review it? Compling/regression tests seems fine on my box (Linux kernel 2.2/egcs-2.91/glic 2.1.3). Documents are also compiled fine. -- Tatsuo Ishii
None of my Solaris boxes have direct internet access, but if someone is willing to make a snapshot tar.gz/tar.bz2 file, I can download and test on Solaris 8 SPARC/INTEL. :) Regards and best wishes, Justin Clift Tatsuo Ishii wrote: > > > OK, 7.1.3 is packaged and ready to go, date stamped Auguest 15. Can > > people with cvs 7.1 branches review it? > > Compling/regression tests seems fine on my box (Linux kernel > 2.2/egcs-2.91/glic 2.1.3). Documents are also compiled fine. > -- > Tatsuo Ishii > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Is it possible to include patch for libpgtcl & tcl >8.0 in this release? Regards, Mikhail Terekhov Bruce Momjian wrote: > > > > > I have to fix my old fault in TID handling. > > > > I am able to have a cvs access now and would > > > > commit the fix to 7.1 branch. > > > > > > Hiroshi, are you done with changes you want in 7.1.3? > > > > > > > Oops I missed your mail sorry. Unfortunately my mail server > > is down and I could access pgsql-hackers only by the news server. > > > > My answer is Yes. > > OK, 7.1.3 is packaged and ready to go, date stamped Auguest 15. Can > people with cvs 7.1 branches review it? > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@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 > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
By the way, Are we going to do the "official" testing-on-all-supported-platforms before making this (hopefully final 7.1.x) release? It'd be embarrasing if it failed on something it's supposed to work on... If so, do we make use of Vince's Regression Test form? http://www.ca.postgresql.org/~vev/regress/ Regards and best wishes, Justin Clift Mikhail Terekhov wrote: > > Is it possible to include patch for libpgtcl & tcl >8.0 > in this release? > > Regards, > Mikhail Terekhov > > Bruce Momjian wrote: > > > > > > > I have to fix my old fault in TID handling. > > > > > I am able to have a cvs access now and would > > > > > commit the fix to 7.1 branch. > > > > > > > > Hiroshi, are you done with changes you want in 7.1.3? > > > > > > > > > > Oops I missed your mail sorry. Unfortunately my mail server > > > is down and I could access pgsql-hackers only by the news server. > > > > > > My answer is Yes. > > > > OK, 7.1.3 is packaged and ready to go, date stamped Auguest 15. Can > > people with cvs 7.1 branches review it? > > > > -- > > Bruce Momjian | http://candle.pha.pa.us > > pgman@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 > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
> Is it possible to include patch for libpgtcl & tcl >8.0 > in this release? Much too risky. We don't know about compatibility with earlier tcl versions. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
> By the way, > > Are we going to do the "official" testing-on-all-supported-platforms > before making this (hopefully final 7.1.x) release? It'd be embarrasing > if it failed on something it's supposed to work on... > > If so, do we make use of Vince's Regression Test form? > http://www.ca.postgresql.org/~vev/regress/ Not usually. We didn't change that much. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
So... will current 7.1.1 databases upgrade without problems to 7.1.3?
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Are we going to do the "official" testing-on-all-supported-platforms
> Not usually. We didn't change that much.
More to the point, I don't believe there were any changes that had any
significance for portability...
regards, tom lane
The current CVS tree does not compile ODBC. All sorts of failure due to const and undefined variables. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The current CVS tree does not compile ODBC. All sorts of failure due to
> const and undefined variables.
I just got a ton of errors in odbc too, trying to build it with HP's cc.
I have not tried to build ODBC at all lately, so I'm not sure
how new the problem is.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > The current CVS tree does not compile ODBC. All sorts of failure due to > > const and undefined variables. > > I just got a ton of errors in odbc too, trying to build it with HP's cc. > I have not tried to build ODBC at all lately, so I'm not sure > how new the problem is. Don't bother. Some are const prototype, non-const definition, but others are undefined variable and possible variable used but not initialized. I think we have to wait for Hiroshi. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
> -----Original Message----- > From: Bruce Momjian > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > The current CVS tree does not compile ODBC. All sorts of > failure due to > > > const and undefined variables. > > > > I just got a ton of errors in odbc too, trying to build it with HP's cc. > > I have not tried to build ODBC at all lately, so I'm not sure > > how new the problem is. > > Don't bother. Some are const prototype, non-const definition, but > others are undefined variable and possible variable used but not > initialized. I think we have to wait for Hiroshi. OK I removed the errors on cygwin port and will commit the fix soon. However I couldn't check it on linux box now unfortunately. I'm very happy if you could check it on your environment. regards, Hiroshi Inoue
> > Don't bother. Some are const prototype, non-const definition, but > > others are undefined variable and possible variable used but not > > initialized. I think we have to wait for Hiroshi. > > OK I removed the errors on cygwin port and will commit > the fix soon. However I couldn't check it on linux box now > unfortunately. I'm very happy if you could check it on your > environment. OK, I will wait for your commit. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
> > -----Original Message----- > > From: Bruce Momjian > > > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > > The current CVS tree does not compile ODBC. All sorts of > > failure due to > > > > const and undefined variables. > > > > > > I just got a ton of errors in odbc too, trying to build it with HP's cc. > > > I have not tried to build ODBC at all lately, so I'm not sure > > > how new the problem is. > > > > Don't bother. Some are const prototype, non-const definition, but > > others are undefined variable and possible variable used but not > > initialized. I think we have to wait for Hiroshi. > > OK I removed the errors on cygwin port and will commit > the fix soon. However I couldn't check it on linux box now > unfortunately. I'm very happy if you could check it on your > environment. Looks great. Compiles cleanly. I moved updateCommons() into the Win32 block so I don't get a "function not used" warning. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The current CVS tree does not compile ODBC. All sorts of failure due to
> const and undefined variables.
I just got a ton of errors in odbc too, trying to build it with HP's cc.
I have not tried to build ODBC at all lately, so I'm not sure
how new the problem is.
regards, tom lane