@(#)Mordred Labs advisory 0x0002: Buffer overflow in PostgreSQL
Seems like this one was lost or was filtered out...
//@(#)Mordred Labs advisory 0x0002
Release data: 19/08/02
Name: Buffer overflow in PostgreSQL
Versions affected: all versions
Risk: high
--[ Description:
There exists a buffer overflow in a SET TIME ZONE command, that
allows an attacker to execute malicious code.
--[ Details:
Upon executing the SET TIME ZONE 'STRING' command, parse_timezone()
function is invoked,
which will overwrite a static buffer tzbuf with the supplied string.
Look at the src/backend/commands/variable.c if you need something to laugh
at.
--[ How to reproduce:
psql> SET TIMEZONE to 'XXXXXX...very long string...XXXXX'
...
NOTICE: Buffer Leak: [27191] (freeNext=0, freePrev=0, rel=0/0, blockNum=0,
flags=0x0, refcount=0 128)
NOTICE: Buffer Leak: [27192] (freeNext=0, freePrev=0, rel=0/0, blockNum=0,
flags=0x0, refcount=0 1249)
NOTICE: Buffer Leak: [27193] (freeNext=0, freePrev=0, rel=0/0, blockNum=0,
flags=0x0, refcount=0 1651799137)
NOTICE: Buffer Leak: [27194] (freeNext=0, freePrev=0, rel=0/0, blockNum=0,
flags=0x0, refcount=0 1818326649)
...
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
--[ Solution:
Just wait...
________________________________________________________________________
This letter has been delivered unencrypted. We'd like to remind you that
the full protection of e-mail correspondence is provided by S-mail
encryption mechanisms if only both, Sender and Recipient use S-mail.
Register at S-mail.com: http://www.s-mail.com/inf/en
Sir Mordred The Traitor <mordred@s-mail.com> writes:
There exists a buffer overflow in a SET TIME ZONE command, that
allows an attacker to execute malicious code.
Here's a patch for the problem. I also fixed some other potential
buffer overruns nearby, and added a little paranoia to another routine
that uses a statically sized buffer.
Thanks for the report.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Attachments:
set_time_zone-3.patchtext/x-patchDownload
Index: src/backend/commands/variable.c
===================================================================
RCS file: /var/lib/cvs/pgsql-server/src/backend/commands/variable.c,v
retrieving revision 1.57
diff -c -r1.57 variable.c
*** src/backend/commands/variable.c 9 Dec 2001 04:37:50 -0000 1.57
--- src/backend/commands/variable.c 21 Aug 2002 16:07:54 -0000
***************
*** 274,299 ****
show_datestyle(void)
{
char buf[64];
- strcpy(buf, "DateStyle is ");
switch (DateStyle)
{
case USE_ISO_DATES:
! strcat(buf, "ISO");
break;
case USE_SQL_DATES:
! strcat(buf, "SQL");
break;
case USE_GERMAN_DATES:
! strcat(buf, "German");
break;
default:
! strcat(buf, "Postgres");
break;
! };
! strcat(buf, " with ");
! strcat(buf, ((EuroDates) ? "European" : "US (NonEuropean)"));
! strcat(buf, " conventions");
elog(NOTICE, buf, NULL);
--- 274,299 ----
show_datestyle(void)
{
char buf[64];
+ char *dstyle;
switch (DateStyle)
{
case USE_ISO_DATES:
! dstyle = "ISO";
break;
case USE_SQL_DATES:
! dstyle = "SQL";
break;
case USE_GERMAN_DATES:
! dstyle = "German";
break;
default:
! dstyle = "Postgres";
break;
! }
!
! snprintf(buf, sizeof(buf), "DateStyle is %s with %s conventions",
! dstyle, EuroDates ? "European" : "US (NonEuropean");
elog(NOTICE, buf, NULL);
***************
*** 442,456 ****
{
/* found something? then save it for later */
if ((defaultTZ = getenv("TZ")) != NULL)
! strcpy(TZvalue, defaultTZ);
/* found nothing so mark with an invalid pointer */
else
defaultTZ = (char *) -1;
}
! strcpy(tzbuf, "TZ=");
! strcat(tzbuf, tok);
if (putenv(tzbuf) != 0)
elog(ERROR, "Unable to set TZ environment variable to %s", tok);
--- 442,455 ----
{
/* found something? then save it for later */
if ((defaultTZ = getenv("TZ")) != NULL)
! strncpy(TZvalue, defaultTZ, sizeof(TZvalue));
/* found nothing so mark with an invalid pointer */
else
defaultTZ = (char *) -1;
}
! snprintf(tzbuf, sizeof(tzbuf), "TZ=%s", tok);
if (putenv(tzbuf) != 0)
elog(ERROR, "Unable to set TZ environment variable to %s", tok);
***************
*** 513,520 ****
/* time zone was set and original explicit time zone available? */
else if (defaultTZ != (char *) -1)
{
! strcpy(tzbuf, "TZ=");
! strcat(tzbuf, TZvalue);
if (putenv(tzbuf) != 0)
elog(ERROR, "Unable to set TZ environment variable to %s", TZvalue);
tzset();
--- 512,518 ----
/* time zone was set and original explicit time zone available? */
else if (defaultTZ != (char *) -1)
{
! snprintf(tzbuf, sizeof(tzbuf), "TZ=%s", TZvalue);
if (putenv(tzbuf) != 0)
elog(ERROR, "Unable to set TZ environment variable to %s", TZvalue);
tzset();
Neil Conway <neilc@samurai.com> writes:
Sir Mordred The Traitor <mordred@s-mail.com> writes:
There exists a buffer overflow in a SET TIME ZONE command, that
allows an attacker to execute malicious code.Here's a patch for the problem. I also fixed some other potential
buffer overruns nearby, and added a little paranoia to another routine
that uses a statically sized buffer.
The handling of the TZ environmental variable is subject to a buffer
overrun. To see the problem, try:
export TZ=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
postmaster -D /foo/bar&
psql
You get:
NOTICE: Buffer Leak: [26914] (freeNext=0, freePrev=0, rel=0/0, blockNum=0, flags=0x0, refcount=0 1)
[ lots more NOTICEs ]
psql: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
A revised patch is attached that fixes the problem.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Attachments:
set_time_zone-4.patchtext/x-patchDownload
Index: src/backend/commands/variable.c
===================================================================
RCS file: /var/lib/cvs/pgsql-server/src/backend/commands/variable.c,v
retrieving revision 1.57
diff -c -r1.57 variable.c
*** src/backend/commands/variable.c 9 Dec 2001 04:37:50 -0000 1.57
--- src/backend/commands/variable.c 21 Aug 2002 17:32:27 -0000
***************
*** 274,299 ****
show_datestyle(void)
{
char buf[64];
- strcpy(buf, "DateStyle is ");
switch (DateStyle)
{
case USE_ISO_DATES:
! strcat(buf, "ISO");
break;
case USE_SQL_DATES:
! strcat(buf, "SQL");
break;
case USE_GERMAN_DATES:
! strcat(buf, "German");
break;
default:
! strcat(buf, "Postgres");
break;
! };
! strcat(buf, " with ");
! strcat(buf, ((EuroDates) ? "European" : "US (NonEuropean)"));
! strcat(buf, " conventions");
elog(NOTICE, buf, NULL);
--- 274,299 ----
show_datestyle(void)
{
char buf[64];
+ char *dstyle;
switch (DateStyle)
{
case USE_ISO_DATES:
! dstyle = "ISO";
break;
case USE_SQL_DATES:
! dstyle = "SQL";
break;
case USE_GERMAN_DATES:
! dstyle = "German";
break;
default:
! dstyle = "Postgres";
break;
! }
!
! snprintf(buf, sizeof(buf), "DateStyle is %s with %s conventions",
! dstyle, EuroDates ? "European" : "US (NonEuropean");
elog(NOTICE, buf, NULL);
***************
*** 442,456 ****
{
/* found something? then save it for later */
if ((defaultTZ = getenv("TZ")) != NULL)
! strcpy(TZvalue, defaultTZ);
/* found nothing so mark with an invalid pointer */
else
defaultTZ = (char *) -1;
}
! strcpy(tzbuf, "TZ=");
! strcat(tzbuf, tok);
if (putenv(tzbuf) != 0)
elog(ERROR, "Unable to set TZ environment variable to %s", tok);
--- 442,455 ----
{
/* found something? then save it for later */
if ((defaultTZ = getenv("TZ")) != NULL)
! strncpy(TZvalue, defaultTZ, sizeof(TZvalue));
/* found nothing so mark with an invalid pointer */
else
defaultTZ = (char *) -1;
}
! snprintf(tzbuf, sizeof(tzbuf), "TZ=%s", tok);
if (putenv(tzbuf) != 0)
elog(ERROR, "Unable to set TZ environment variable to %s", tok);
***************
*** 513,520 ****
/* time zone was set and original explicit time zone available? */
else if (defaultTZ != (char *) -1)
{
! strcpy(tzbuf, "TZ=");
! strcat(tzbuf, TZvalue);
if (putenv(tzbuf) != 0)
elog(ERROR, "Unable to set TZ environment variable to %s", TZvalue);
tzset();
--- 512,518 ----
/* time zone was set and original explicit time zone available? */
else if (defaultTZ != (char *) -1)
{
! snprintf(tzbuf, sizeof(tzbuf), "TZ=%s", TZvalue);
if (putenv(tzbuf) != 0)
elog(ERROR, "Unable to set TZ environment variable to %s", TZvalue);
tzset();
Index: src/backend/utils/adt/nabstime.c
===================================================================
RCS file: /var/lib/cvs/pgsql-server/src/backend/utils/adt/nabstime.c,v
retrieving revision 1.91
diff -c -r1.91 nabstime.c
*** src/backend/utils/adt/nabstime.c 25 Oct 2001 05:49:44 -0000 1.91
--- src/backend/utils/adt/nabstime.c 21 Aug 2002 17:32:27 -0000
***************
*** 145,165 ****
* XXX is there a better way to get local timezone string w/o
* tzname? - tgl 97/03/18
*/
! strftime(CTZName, MAXTZLEN, "%Z", tm);
#endif
/*
* XXX FreeBSD man pages indicate that this should work - thomas
* 1998-12-12
*/
! strcpy(CTZName, tm->tm_zone);
#elif defined(HAVE_INT_TIMEZONE)
tm = localtime(&now);
CDayLight = tm->tm_isdst;
CTimeZone = ((tm->tm_isdst > 0) ? (TIMEZONE_GLOBAL - 3600) : TIMEZONE_GLOBAL);
! strcpy(CTZName, tzname[tm->tm_isdst]);
#else /* neither HAVE_TM_ZONE nor
* HAVE_INT_TIMEZONE */
CTimeZone = tb.timezone * 60;
--- 145,165 ----
* XXX is there a better way to get local timezone string w/o
* tzname? - tgl 97/03/18
*/
! strftime(CTZName, MAXTZLEN + 1, "%Z", tm);
#endif
/*
* XXX FreeBSD man pages indicate that this should work - thomas
* 1998-12-12
*/
! StrNCpy(CTZName, tm->tm_zone, MAXTZLEN + 1);
#elif defined(HAVE_INT_TIMEZONE)
tm = localtime(&now);
CDayLight = tm->tm_isdst;
CTimeZone = ((tm->tm_isdst > 0) ? (TIMEZONE_GLOBAL - 3600) : TIMEZONE_GLOBAL);
! StrNCpy(CTZName, tzname[tm->tm_isdst], MAXTZLEN + 1);
#else /* neither HAVE_TM_ZONE nor
* HAVE_INT_TIMEZONE */
CTimeZone = tb.timezone * 60;
***************
*** 169,175 ****
* XXX does this work to get the local timezone string in V7? -
* tgl 97/03/18
*/
! strftime(CTZName, MAXTZLEN, "%Z", localtime(&now));
#endif
}
--- 169,175 ----
* XXX does this work to get the local timezone string in V7? -
* tgl 97/03/18
*/
! strftime(CTZName, MAXTZLEN + 1, "%Z", localtime(&now));
#endif
}
***************
*** 227,247 ****
* XXX is there a better way to get local timezone string w/o
* tzname? - tgl 97/03/18
*/
! strftime(CTZName, MAXTZLEN, "%Z", tm);
#endif
/*
* XXX FreeBSD man pages indicate that this should work - thomas
* 1998-12-12
*/
! strcpy(CTZName, tm->tm_zone);
#elif defined(HAVE_INT_TIMEZONE)
tm = localtime(&now);
CDayLight = tm->tm_isdst;
CTimeZone = ((tm->tm_isdst > 0) ? (TIMEZONE_GLOBAL - 3600) : TIMEZONE_GLOBAL);
! strcpy(CTZName, tzname[tm->tm_isdst]);
#else /* neither HAVE_TM_ZONE nor
* HAVE_INT_TIMEZONE */
CTimeZone = tb.timezone * 60;
--- 227,247 ----
* XXX is there a better way to get local timezone string w/o
* tzname? - tgl 97/03/18
*/
! strftime(CTZName, MAXTZLEN + 1, "%Z", tm);
#endif
/*
* XXX FreeBSD man pages indicate that this should work - thomas
* 1998-12-12
*/
! StrNCpy(CTZName, tm->tm_zone, MAXTZLEN + 1);
#elif defined(HAVE_INT_TIMEZONE)
tm = localtime(&now);
CDayLight = tm->tm_isdst;
CTimeZone = ((tm->tm_isdst > 0) ? (TIMEZONE_GLOBAL - 3600) : TIMEZONE_GLOBAL);
! StrNCpy(CTZName, tzname[tm->tm_isdst], MAXTZLEN + 1);
#else /* neither HAVE_TM_ZONE nor
* HAVE_INT_TIMEZONE */
CTimeZone = tb.timezone * 60;
***************
*** 251,257 ****
* XXX does this work to get the local timezone string in V7? -
* tgl 97/03/18
*/
! strftime(CTZName, MAXTZLEN, "%Z", localtime(&now));
#endif
};
--- 251,257 ----
* XXX does this work to get the local timezone string in V7? -
* tgl 97/03/18
*/
! strftime(CTZName, MAXTZLEN + 1, "%Z", localtime(&now));
#endif
};
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Neil Conway wrote:
Sir Mordred The Traitor <mordred@s-mail.com> writes:
There exists a buffer overflow in a SET TIME ZONE command, that
allows an attacker to execute malicious code.Here's a patch for the problem. I also fixed some other potential
buffer overruns nearby, and added a little paranoia to another routine
that uses a statically sized buffer.Thanks for the report.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Neil Conway wrote:
Neil Conway <neilc@samurai.com> writes:
Sir Mordred The Traitor <mordred@s-mail.com> writes:
There exists a buffer overflow in a SET TIME ZONE command, that
allows an attacker to execute malicious code.Here's a patch for the problem. I also fixed some other potential
buffer overruns nearby, and added a little paranoia to another routine
that uses a statically sized buffer.The handling of the TZ environmental variable is subject to a buffer
overrun. To see the problem, try:export TZ=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
postmaster -D /foo/bar&
psqlYou get:
NOTICE: Buffer Leak: [26914] (freeNext=0, freePrev=0, rel=0/0, blockNum=0, flags=0x0, refcount=0 1)
[ lots more NOTICEs ]
psql: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.A revised patch is attached that fixes the problem.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Neil Conway <neilc@samurai.com> writes:
The handling of the TZ environmental variable is subject to a buffer
overrun.
This problem is long gone in current sources, no?
regards, tom lane
Tom Lane wrote:
Neil Conway <neilc@samurai.com> writes:
The handling of the TZ environmental variable is subject to a buffer
overrun.This problem is long gone in current sources, no?
The patch looks like it does prevent some problems.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
Tom Lane wrote:
Neil Conway <neilc@samurai.com> writes:
The handling of the TZ environmental variable is subject to a buffer
overrun.This problem is long gone in current sources, no?
I quickly tested current sources, and it seems the bug is fixed. I
only fixed it to begin with because I saw it while fixing the reported
problem.
The patch looks like it does prevent some problems.
Yes: namely, it fixes the bug in REL7_2_STABLE.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
What would you like done with the patch you submitted?
---------------------------------------------------------------------------
Neil Conway wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Tom Lane wrote:
Neil Conway <neilc@samurai.com> writes:
The handling of the TZ environmental variable is subject to a buffer
overrun.This problem is long gone in current sources, no?
I quickly tested current sources, and it seems the bug is fixed. I
only fixed it to begin with because I saw it while fixing the reported
problem.The patch looks like it does prevent some problems.
Yes: namely, it fixes the bug in REL7_2_STABLE.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
What would you like done with the patch you submitted?
I'd like to see it applied to CVS HEAD and REL7_2_STABLE.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Neil Conway <neilc@samurai.com> writes:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
What would you like done with the patch you submitted?
I'd like to see it applied to CVS HEAD and REL7_2_STABLE.
Uh, sorry -- wrote that without thinking. I'd like to see the patch
applied to REL7_2_STABLE. I'll prepare a revised patch for CVS HEAD.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Neil Conway <neilc@samurai.com> writes:
Neil Conway <neilc@samurai.com> writes:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
What would you like done with the patch you submitted?
I'd like to see it applied to CVS HEAD and REL7_2_STABLE.
Uh, sorry -- wrote that without thinking. I'd like to see the patch
applied to REL7_2_STABLE. I'll prepare a revised patch for CVS HEAD.
I'm pretty certain that no such patch is necessary for HEAD.
regards, tom lane
OK, I have applied this to 7.2.X.
I have applied the lpad/rpad/repeat patch to CVS head. I assume you do
not want the others applied to CVS head because the fixes are already present.
---------------------------------------------------------------------------
Neil Conway wrote:
Neil Conway <neilc@samurai.com> writes:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
What would you like done with the patch you submitted?
I'd like to see it applied to CVS HEAD and REL7_2_STABLE.
Uh, sorry -- wrote that without thinking. I'd like to see the patch
applied to REL7_2_STABLE. I'll prepare a revised patch for CVS HEAD.Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Are we all caught up now on the known bugs/fixes? Would it be reasonably
safe to do up a quick v7.2.2 Security Fix Release tomorrow afternoon?
On Thu, 22 Aug 2002, Bruce Momjian wrote:
Show quoted text
OK, I have applied this to 7.2.X.
I have applied the lpad/rpad/repeat patch to CVS head. I assume you do
not want the others applied to CVS head because the fixes are already present.---------------------------------------------------------------------------
Neil Conway wrote:
Neil Conway <neilc@samurai.com> writes:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
What would you like done with the patch you submitted?
I'd like to see it applied to CVS HEAD and REL7_2_STABLE.
Uh, sorry -- wrote that without thinking. I'd like to see the patch
applied to REL7_2_STABLE. I'll prepare a revised patch for CVS HEAD.Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
"Marc G. Fournier" <scrappy@hub.org> writes:
Are we all caught up now on the known bugs/fixes? Would it be reasonably
safe to do up a quick v7.2.2 Security Fix Release tomorrow afternoon?
Still need to do a release-history entry and version-stamp, of course.
I will do a diff of the 7.2 branch tree this afternoon and make sure
the code looks good.
regards, tom lane
I was going to ask that too. I need to make up a list of 7.2.2 changes,
and there are quite a number of them. I will get the list together today.
---------------------------------------------------------------------------
Marc G. Fournier wrote:
Are we all caught up now on the known bugs/fixes? Would it be reasonably
safe to do up a quick v7.2.2 Security Fix Release tomorrow afternoon?On Thu, 22 Aug 2002, Bruce Momjian wrote:
OK, I have applied this to 7.2.X.
I have applied the lpad/rpad/repeat patch to CVS head. I assume you do
not want the others applied to CVS head because the fixes are already present.---------------------------------------------------------------------------
Neil Conway wrote:
Neil Conway <neilc@samurai.com> writes:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
What would you like done with the patch you submitted?
I'd like to see it applied to CVS HEAD and REL7_2_STABLE.
Uh, sorry -- wrote that without thinking. I'd like to see the patch
applied to REL7_2_STABLE. I'll prepare a revised patch for CVS HEAD.Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Thanks, Tom. That is a big help. I will do the release history and
version stamping.
---------------------------------------------------------------------------
Tom Lane wrote:
"Marc G. Fournier" <scrappy@hub.org> writes:
Are we all caught up now on the known bugs/fixes? Would it be reasonably
safe to do up a quick v7.2.2 Security Fix Release tomorrow afternoon?Still need to do a release-history entry and version-stamp, of course.
I will do a diff of the 7.2 branch tree this afternoon and make sure
the code looks good.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) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Hi everyone,
It probably makes sense to wait about a week until releasing 7.2.2, even
if we get assembled anything else that is needed. Sir Mordred appears
to be taking a look through our 7.2.x code about now and that probably
means there's a good chance we'll hear of other patches that will need
to be applied to the 7.2.x branch.
:-)
Regards and best wishes,
Justin Clift
Oleg Bartunov wrote:
Tom,
I think it's worth to include patch for query planner which
fixes using indices with predicates for join plans. We found it's
quite useful.http://fts.postgresql.org/db/mw/msg.html?mid=1018153
Oleg
--
"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
Import Notes
Reference msg id not found: Pine.GSO.4.44.0208221813050.17263-100000@ra.sai.msu.su | Resolved by subject fallback
Justin Clift <justin@postgresql.org> writes:
It probably makes sense to wait about a week until releasing 7.2.2, even
if we get assembled anything else that is needed.
I think we should go ahead and push it out; by the end of next week
we'll be trying to wrap 7.3 beta, and the confusion factor for pushing
out two releases at the same time will be much too high.
I think it is fairly unlikely that we will find anything else in the
next week that is exploitable indirectly through a web-app in the same
way that the date buffer overrun bug could be. Most of the sorts of
bugs that I'm expecting to hear about will require being able to issue
SQL commands --- and if someone can issue arbitrary SQL commands, there
are plenty of ways to create a DOS situation.
regards, tom lane
Tom,
I think it's worth to include patch for query planner which
fixes using indices with predicates for join plans. We found it's
quite useful.
http://fts.postgresql.org/db/mw/msg.html?mid=1018153
Oleg
On Thu, 22 Aug 2002, Tom Lane wrote:
"Marc G. Fournier" <scrappy@hub.org> writes:
Are we all caught up now on the known bugs/fixes? Would it be reasonably
safe to do up a quick v7.2.2 Security Fix Release tomorrow afternoon?Still need to do a release-history entry and version-stamp, of course.
I will do a diff of the 7.2 branch tree this afternoon and make sure
the code looks good.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)
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 Thu, 22 Aug 2002, Tom Lane wrote:
Justin Clift <justin@postgresql.org> writes:
It probably makes sense to wait about a week until releasing 7.2.2, even
if we get assembled anything else that is needed.I think we should go ahead and push it out; by the end of next week
we'll be trying to wrap 7.3 beta, and the confusion factor for pushing
out two releases at the same time will be much too high.I think it is fairly unlikely that we will find anything else in the
next week that is exploitable indirectly through a web-app in the same
way that the date buffer overrun bug could be. Most of the sorts of
bugs that I'm expecting to hear about will require being able to issue
SQL commands --- and if someone can issue arbitrary SQL commands, there
are plenty of ways to create a DOS situation.
And, worse comes to worse, we *can* issue a v7.2.3 if further security
issues are found before v7.3 is fully released ...
Done, but Tom.
---------------------------------------------------------------------------
Oleg Bartunov wrote:
Tom,
I think it's worth to include patch for query planner which
fixes using indices with predicates for join plans. We found it's
quite useful.http://fts.postgresql.org/db/mw/msg.html?mid=1018153
Oleg
On Thu, 22 Aug 2002, Tom Lane wrote:"Marc G. Fournier" <scrappy@hub.org> writes:
Are we all caught up now on the known bugs/fixes? Would it be reasonably
safe to do up a quick v7.2.2 Security Fix Release tomorrow afternoon?Still need to do a release-history entry and version-stamp, of course.
I will do a diff of the 7.2 branch tree this afternoon and make sure
the code looks good.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)Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Thursday 22 August 2002 10:32 am, Justin Clift wrote:
It probably makes sense to wait about a week until releasing 7.2.2, even
if we get assembled anything else that is needed. Sir Mordred appears
to be taking a look through our 7.2.x code about now and that probably
means there's a good chance we'll hear of other patches that will need
to be applied to the 7.2.x branch.
FWIW, it will be Monday at the earliest before I can dedicate the time to
build a 7.2.2 release RPMset. If a preliminary tarball was available
Saturday, I might could have an RPM uploaded Monday morning.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
I said:
Still need to do a release-history entry and version-stamp, of course.
I will do a diff of the 7.2 branch tree this afternoon and make sure
the code looks good.
Code checked, regression tests run. Bruce, the ball's in your court ...
regards, tom lane
Tom Lane wrote:
I said:
Still need to do a release-history entry and version-stamp, of course.
I will do a diff of the 7.2 branch tree this afternoon and make sure
the code looks good.Code checked, regression tests run. Bruce, the ball's in your court ...
OK, I am getting autoconf warnings with the 7.2.2 configure.in. This is
with autoconf 2.53. Do I need a different version for this release?
---------------------------------------------------------------------------
(3) autoconf
configure.in:139: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:146: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:149: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:158: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:168: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:200: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:212: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:223: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:236: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:246: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:253: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:261: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:311: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:320: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:360: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:367: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:378: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:383: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:389: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:397: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:411: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:442: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:465: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:484: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:495: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:517: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:533: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:534: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:535: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:558: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:621: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:972: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:292: error: possibly undefined macro: AC_PROG_CC_WORKS
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073We're still using 2.53 on the main server:
%autoconf --version
autoconf (GNU Autoconf) 2.53
Written by David J. MacKenzie and Akim Demaille.
Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
And I just autoconf'd after removing the odbc stuff for the HEAD branch ...
On Thu, 22 Aug 2002, Bruce Momjian wrote:
Show quoted text
Tom Lane wrote:
I said:
Still need to do a release-history entry and version-stamp, of course.
I will do a diff of the 7.2 branch tree this afternoon and make sure
the code looks good.Code checked, regression tests run. Bruce, the ball's in your court ...
OK, I am getting autoconf warnings with the 7.2.2 configure.in. This is
with autoconf 2.53. Do I need a different version for this release?---------------------------------------------------------------------------
(3) autoconf
configure.in:139: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:146: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:149: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:158: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:168: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:200: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:212: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:223: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:236: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:246: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:253: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:261: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:311: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:320: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:360: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:367: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:378: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:383: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:389: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:397: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:411: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:442: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:465: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:484: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:495: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:517: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:533: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:534: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:535: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:558: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:621: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:972: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:292: error: possibly undefined macro: AC_PROG_CC_WORKS-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
No, the problem is with the 7.2.2 branch, REL7_2_STABLE.
---------------------------------------------------------------------------
Marc G. Fournier wrote:
We're still using 2.53 on the main server:
%autoconf --version
autoconf (GNU Autoconf) 2.53
Written by David J. MacKenzie and Akim Demaille.Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.And I just autoconf'd after removing the odbc stuff for the HEAD branch ...
On Thu, 22 Aug 2002, Bruce Momjian wrote:
Tom Lane wrote:
I said:
Still need to do a release-history entry and version-stamp, of course.
I will do a diff of the 7.2 branch tree this afternoon and make sure
the code looks good.Code checked, regression tests run. Bruce, the ball's in your court ...
OK, I am getting autoconf warnings with the 7.2.2 configure.in. This is
with autoconf 2.53. Do I need a different version for this release?---------------------------------------------------------------------------
(3) autoconf
configure.in:139: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:146: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:149: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:158: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:168: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:200: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:212: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:223: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:236: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:246: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:253: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:261: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:311: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:320: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:360: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:367: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:378: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:383: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:389: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:397: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:411: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:442: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:465: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:484: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:495: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:517: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:533: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:534: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:535: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:558: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:621: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:972: /usr/contrib/bin/gm4: Non-numeric argument to built-in `divert'
configure.in:292: error: possibly undefined macro: AC_PROG_CC_WORKS-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
OK, I am getting autoconf warnings with the 7.2.2 configure.in. This is
with autoconf 2.53. Do I need a different version for this release?
7.2 was built with autoconf 2.13. Simple answer: don't re-autoconf.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
OK, I am getting autoconf warnings with the 7.2.2 configure.in. This is
with autoconf 2.53. Do I need a different version for this release?7.2 was built with autoconf 2.13. Simple answer: don't re-autoconf.
Good idea.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Done.
---------------------------------------------------------------------------
Tom Lane wrote:
I said:
Still need to do a release-history entry and version-stamp, of course.
I will do a diff of the 7.2 branch tree this afternoon and make sure
the code looks good.Code checked, regression tests run. Bruce, the ball's in your court ...
regards, tom lane
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
Done.
I've attached some improvements to HISTORY: fixed some obvious typos,
added info on Tom's partial index backpatch, and elaborated on the
nature of the fixed security problems.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Attachments:
relnotes.patchtext/x-patchDownload
Index: HISTORY
===================================================================
RCS file: /var/lib/cvs/pgsql-server/HISTORY,v
retrieving revision 1.153.2.6
diff -c -r1.153.2.6 HISTORY
*** HISTORY 22 Aug 2002 23:26:23 -0000 1.153.2.6
--- HISTORY 23 Aug 2002 00:21:43 -0000
***************
*** 4,10 ****
Release date: 2002-08-23
! This has a variety of fixes from 7.2.1.
----------------------------------------------------------------------
--- 4,11 ----
Release date: 2002-08-23
! This has a variety of fixes from 7.2.1, including the security
! problems reported on BUGTRAQ.
----------------------------------------------------------------------
***************
*** 19,35 ****
Allow EXECUTE of "CREATE TABLE AS ... SELECT" in PL/PgSQL (Tom)
Fix for compressed transaction log id wraparound (Tom)
Fix PQescapeBytea/PQunescapeBytea so that they handle bytes > 0x7f (Tatsuo)
! Fix for psql and pg_dump crashing when invoked with non-existand long
options (Tatsuo)
Fix crash when invoking geometric operators (Tom)
Allow OPEN cursor(args) (Tom)
Fix for rtree_gist index build (Teodor)
Fix for dumping user-defined aggregates (Tom)
Contrib/intarray fixes (Oleg)
Fix for complex UNION/EXCEPT/INTERSECT queries using parens (Tom)
Fix to pg_convert (Tatsuo)
! Fix for crash with long DATA strings (Thomes, Neil)
! Fix for repeat(), lpad(), rpad() and long strings (Neil)
----------------------------------------------------------------------
--- 20,40 ----
Allow EXECUTE of "CREATE TABLE AS ... SELECT" in PL/PgSQL (Tom)
Fix for compressed transaction log id wraparound (Tom)
Fix PQescapeBytea/PQunescapeBytea so that they handle bytes > 0x7f (Tatsuo)
! Fix for psql and pg_dump crashing when invoked with non-existent long
options (Tatsuo)
Fix crash when invoking geometric operators (Tom)
Allow OPEN cursor(args) (Tom)
Fix for rtree_gist index build (Teodor)
+ Fix for usage of partial indexes for relations other than first in
+ joins (Tom)
Fix for dumping user-defined aggregates (Tom)
Contrib/intarray fixes (Oleg)
Fix for complex UNION/EXCEPT/INTERSECT queries using parens (Tom)
Fix to pg_convert (Tatsuo)
! Fix for buffer overrun in handling long datetime input (Thomas, Neil)
! Fix for buffer overrun in repeat() (Neil)
! Fix for buffer overrun in lpad() and rpad() with multibyte (Neil)
! Fix for buffer overrun in SET TIME ZONE and TZ env var (Neil)
----------------------------------------------------------------------
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Done.
Looks good here, except I think you should accept Neil's edits of the
history entries. Also, don't forget to forward-patch the 7.2.2 release
info into the CVS tip version of release.sgml.
Is it appropriate to back-patch the current state of the FAQ into 7.2.2?
regards, tom lane
On Thu, 22 Aug 2002, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Done.
Looks good here, except I think you should accept Neil's edits of the
history entries.
Agreed, that's what I was waiting on :)
On Thu, 22 Aug 2002, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Done.
Looks good here, except I think you should accept Neil's edits of the
history entries.Agreed, that's what I was waiting on :)
Doing a test build of 7.2.2 on FreeBSD/Alpha atm...
Chris
Patch applied. Thanks.
---------------------------------------------------------------------------
Neil Conway wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Done.
I've attached some improvements to HISTORY: fixed some obvious typos,
added info on Tom's partial index backpatch, and elaborated on the
nature of the fixed security problems.Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Done.
Looks good here, except I think you should accept Neil's edits of the
history entries. Also, don't forget to forward-patch the 7.2.2 release
info into the CVS tip version of release.sgml.
Done. I actually took a break from the computer for a few hours to
clear my head.
Is it appropriate to back-patch the current state of the FAQ into 7.2.2?
Already done.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073All 79 tests passed on FreeBSD/Alpha. Good to go :)
Chris
Show quoted text
On Thu, 22 Aug 2002, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Done.
Looks good here, except I think you should accept Neil's edits of the
history entries.Agreed, that's what I was waiting on :)
Doing a test build of 7.2.2 on FreeBSD/Alpha atm...
Builds and runs fine under HP/Compaq Tru64 aka Digital Unix aka OSF/1
(this is getting difficult...) version 4.0f/g using standard cc:
template1=# SELECT version();
version
----------------------------------------------------------------
PostgreSQL 7.2.2 on alphaev56-dec-osf4.0g, compiled by cc -std
$ gmake check
======================
All 79 tests passed.
======================
Same using GCC:
======================
All 79 tests passed.
======================
--
Alessio F. Bragadini alessio@albourne.com
APL Financial Services http://village.albourne.com
Nicosia, Cyprus phone: +357-22-755750
"It is more complicated than you think"
-- The Eighth Networking Truth from RFC 1925