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

Tue, 07 Aug 2001 14:03:44 +1000
Justin Clift <justin@postgresql.org>
To be 7.1.3 or not to be 7.1.3?

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
>


Tue, 7 Aug 2001 09:54:49 -0400 (EDT)
"Marc G. Fournier" <scrappy@hub.org>
Re: To be 7.1.3 or not to be 7.1.3?
"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

Tue, 07 Aug 2001 10:47:40 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: To be 7.1.3 or not to be 7.1.3? 
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


Tue, 7 Aug 2001 21:25:52 +0300 (GMT)
Oleg Bartunov <oleg@sai.msu.su>
Re: To be 7.1.3 or not to be 7.1.3? 
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

Tue, 07 Aug 2001 14:56:02 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: To be 7.1.3 or not to be 7.1.3? 
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


Tue, 7 Aug 2001 22:10:57 +0300 (GMT)
Oleg Bartunov <oleg@sai.msu.su>
Re: To be 7.1.3 or not to be 7.1.3? 


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
>


Wed, 8 Aug 2001 14:07:50 -0400 (EDT)
"Marc G. Fournier" <scrappy@hub.org>
Re: To be 7.1.3 or not to be 7.1.3? 
"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

Wed, 08 Aug 2001 17:29:32 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: To be 7.1.3 or not to be 7.1.3? 
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 at Pop4 Networking
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Wed, 8 Aug 2001 18:34:22 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: To be 7.1.3 or not to be 7.1.3? 
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
-----------------------------------------------------------------

Wed, 8 Aug 2001 19:38:25 -0300
=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar>
Re: To be 7.1.3 or not to be 7.1.3?
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

Wed, 08 Aug 2001 18:39:15 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: To be 7.1.3 or not to be 7.1.3? 
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 to
	disallow COPY TO/FROM a view (or anything else that's not a plain
	relation).

2001-08-08 18:25  tgl

	* src/backend/utils/init/miscinit.c (REL7_1_STABLE): Back-patch fix
	to 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 patch to 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 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): 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-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 branch needs the
	update too...

2001-06-29 12:34  tgl

	* src/backend/commands/vacuum.c (REL7_1_STABLE): 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): 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 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:50  momjian

	* doc/src/sgml/release.sgml (REL7_1_STABLE): Forgot SGML section
	section id tag for 7.1.

2001-05-31 13:33  tgl

	* src/backend/utils/adt/ri_triggers.c (REL7_1_STABLE): 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:01  ishii

	* src/backend/utils/mb/conv.c (REL7_1_STABLE): Fix a message error
	in utf_to_local

Wed, 08 Aug 2001 19:35:42 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: To be 7.1.3 or not to be 7.1.3? 
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

Wed, 08 Aug 2001 22:20:15 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: To be 7.1.3 or not to be 7.1.3? 
> 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, Pennsylvania 19026

Wed, 8 Aug 2001 22:36:56 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: To be 7.1.3 or not to be 7.1.3?
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

Wed, 08 Aug 2001 23:01:14 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: To be 7.1.3 or not to be 7.1.3? 
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

Thu, 09 Aug 2001 14:06:56 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: To be 7.1.3 or not to be 7.1.3?
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
>


Thu, 9 Aug 2001 08:28:39 -0400 (EDT)
"Marc G. Fournier" <scrappy@hub.org>
Re: To be 7.1.3 or not to be 7.1.3? 

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
>


Thu, 9 Aug 2001 08:29:42 -0400 (EDT)
"Marc G. Fournier" <scrappy@hub.org>
Re: To be 7.1.3 or not to be 7.1.3? 

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, Pennsylvania 19026

Thu, 9 Aug 2001 10:45:55 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: To be 7.1.3 or not to be 7.1.3?
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

Thu, 09 Aug 2001 10:51:03 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: To be 7.1.3 or not to be 7.1.3? 
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.

12 Aug 2001 21:03:43 -0400
teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
Re: To be 7.1.3 or not to be 7.1.3?
> 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, Pennsylvania 19026

Mon, 13 Aug 2001 11:25:33 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: To be 7.1.3 or not to be 7.1.3?
teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) 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

Mon, 13 Aug 2001 16:02:51 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: To be 7.1.3 or not to be 7.1.3? 
> teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) 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, Pennsylvania 19026

Mon, 13 Aug 2001 16:49:16 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: To be 7.1.3 or not to be 7.1.3?
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

Tue, 14 Aug 2001 06:25:35 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: To be 7.1.3 or not to be 7.1.3?

I will get on this today.

> teg@redhat.com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) 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

Tue, 14 Aug 2001 11:46:39 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: To be 7.1.3 or not to be 7.1.3?

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 =?iso-8859-1?q?Glomsr=F8d?=) 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
>


Tue, 14 Aug 2001 11:55:04 -0400 (EDT)
"Marc G. Fournier" <scrappy@hub.org>
Re: To be 7.1.3 or not to be 7.1.3?
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

Tue, 14 Aug 2001 14:40:41 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: To be 7.1.3 or not to be 7.1.3?
> > > 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

Tue, 14 Aug 2001 18:17:23 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: To be 7.1.3 or not to be 7.1.3?
> 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

Wed, 15 Aug 2001 18:35:00 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: Re: To be 7.1.3 or not to be 7.1.3?
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

Wed, 15 Aug 2001 09:10:00 -0400
Mikhail Terekhov <terekhov@emc.com>
Re: To be 7.1.3 or not to be 7.1.3?
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

Wed, 15 Aug 2001 23:14:30 +1000
Justin Clift <justin@postgresql.org>
Re: Re: To be 7.1.3 or not to be 7.1.3?
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

Wed, 15 Aug 2001 23:55:47 +1000
Justin Clift <justin@postgresql.org>
Re: Re: To be 7.1.3 or not to be 7.1.3?
> 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, Pennsylvania 19026

Wed, 15 Aug 2001 11:42:29 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: To be 7.1.3 or not to be 7.1.3?
> 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, Pennsylvania 19026

Wed, 15 Aug 2001 11:43:01 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: To be 7.1.3 or not to be 7.1.3?
So... will current 7.1.1 databases upgrade without problems to 7.1.3?


Wed, 15 Aug 2001 14:50:41 -0400
Dwayne Miller <dmiller@espgroup.net>
Re: Re: To be 7.1.3 or not to be 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

Wed, 15 Aug 2001 17:23:22 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: To be 7.1.3 or not to be 7.1.3? 
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

Fri, 7 Sep 2001 12:10:30 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
CVS ODBC does not compile
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

Fri, 07 Sep 2001 13:06:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: CVS ODBC does not compile 
> 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

Fri, 7 Sep 2001 13:08:33 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: CVS ODBC does not compile
> -----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


Sat, 8 Sep 2001 11:26:30 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
Re: CVS ODBC does not compile
> > 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

Fri, 7 Sep 2001 22:40:29 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: CVS ODBC does not compile
> > -----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

Fri, 7 Sep 2001 22:52:05 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: CVS ODBC does not compile