v7.1.1 branched and released on Tuesday ...

As Tom's mentioned the other day, we're looking at doing up v7.1.1 on
Tuesday, and starting in on v7.2 ...

Does anyone have any outstanding fixes for v7.1.x that they
want to see in *before* we do this release? Any points unresolved
that anyone knows about that we need to look at?

Hiroshi reported about startup problem yesterday - we should fix this
for 7.1.1...

Vadim

Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?

Is there a list of what IS getting changed? Can this be posted somewhere
or is the changelist enough?

- Brandon

b. palmer, bpalmer@crimelabs.net
pgp: www.crimelabs.net/bpalmer.pgp5

The Hermit Hacker wrote:

As Tom's mentioned the other day, we're looking at doing up v7.1.1 on
Tuesday, and starting in on v7.2 ...

Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?

The RI-oddness thing. Tom objected to my first trial and
hasn't responded to my last reply yet. Well, and noone else
lost a single word where I'd expected at least a *shrug* or
two.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?

Nothing serious, but I would like to apply a patch to allow IDENT
strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
accept those for date_part(), which is what EXTRACT() is translated to
by the parser, and it seems to be a reasonable to the standard.

- Thomas

Nothing serious, but I would like to apply a patch to allow IDENT
strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
accept those for date_part(), which is what EXTRACT() is translated to
by the parser, and it seems to be a reasonable to the standard.

... reasonable *extension* to the standard.

Thomas Lockhart writes:

Nothing serious, but I would like to apply a patch to allow IDENT
strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
accept those for date_part(), which is what EXTRACT() is translated to
by the parser, and it seems to be a reasonable to the standard.

But why does that need to go into 7.1.1?

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

Nothing serious, but I would like to apply a patch to allow IDENT
strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
accept those for date_part(), which is what EXTRACT() is translated to
by the parser, and it seems to be a reasonable to the standard.

But why does that need to go into 7.1.1?

Does not "need to". But it is non-invasive, extremely low risk, gets the
behavior to match the docs, and gets it off my desk and into the main
tree.

- Thomas

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Nothing serious, but I would like to apply a patch to allow IDENT
strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
accept those for date_part(), which is what EXTRACT() is translated to
by the parser, and it seems to be a reasonable to the standard.

But why does that need to go into 7.1.1?

Does not "need to". But it is non-invasive, extremely low risk, gets the
behavior to match the docs, and gets it off my desk and into the main
tree.

If the current behavior does not match the docs then it qualifies as a
bug fix ;-). I have no objections to this one.

Thomas, what do you think of the persistent reports of date conversion
problems at DST boundaries, eg, Ayal Leibowitz's report today in
pgsql-bugs? I cannot reproduce any such problem --- and my local
timezone database claims that MET DST transitions are the last week of
March, never the first week of April, anyway. There's something funny
going on there.

regards, tom lane

Thomas Lockhart writes:

Nothing serious, but I would like to apply a patch to allow IDENT
strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
accept those for date_part(), which is what EXTRACT() is translated to
by the parser, and it seems to be a reasonable to the standard.

But why does that need to go into 7.1.1?

Does not "need to". But it is non-invasive, extremely low risk, gets the
behavior to match the docs, and gets it off my desk and into the main
tree.

Hehe, match the docs? The docs used to be perfectly accurate until you
changed them.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

Thomas, what do you think of the persistent reports of date conversion
problems at DST boundaries, eg, Ayal Leibowitz's report today in
pgsql-bugs? I cannot reproduce any such problem --- and my local
timezone database claims that MET DST transitions are the last week of
March, never the first week of April, anyway. There's something funny
going on there.

Yes. I tried the example on 7.0.2 (and 7.1) and could not get it to
misbehave. I was guessing that it involves string->date conversion,
which may pass through timestamp to get there, but it looks like there
is an explicit text->date conversion function so time zone should just
never be involved. Really!

- Thomas

Hehe, match the docs? The docs used to be perfectly accurate until you
changed them.

;)

The Hermit Hacker <scrappy@hub.org> writes:

Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?

FWIW, I've finished committing all the bug fixes I have pending.

There are several worrisome unresolved bug reports, but AFAIK none are
for reproducible conditions, and I don't think we can make any more
progress on them without more information. I doubt we should hold up
the 7.1.1 release while waiting to see if we get any.

We do have that not-quite-done QNX4 port patch in hand. Perhaps we
should give Bernd another day to respond to the comments on that and
squeeze it into 7.1.1.

regards, tom lane

The Hermit Hacker <scrappy@hub.org> writes:

Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?

FWIW, I've finished committing all the bug fixes I have pending.

There are several worrisome unresolved bug reports, but AFAIK none are
for reproducible conditions, and I don't think we can make any more
progress on them without more information. I doubt we should hold up
the 7.1.1 release while waiting to see if we get any.

We do have that not-quite-done QNX4 port patch in hand. Perhaps we
should give Bernd another day to respond to the comments on that and
squeeze it into 7.1.1.

There will surely be a 7.1.2. I vote against waiting for 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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

We do have that not-quite-done QNX4 port patch in hand. Perhaps we
should give Bernd another day to respond to the comments on that and
squeeze it into 7.1.1.

There will surely be a 7.1.2. I vote against waiting for it.

Possibly, but one hopes 7.1.2 will be a few months away ...

Given the triviality of the objections to Bernd's patch, I expect he can
turn it around pretty quickly. I do not want to wait more than a day
for it.

regards, tom lane

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Thomas, what do you think of the persistent reports of date conversion
problems at DST boundaries, eg, Ayal Leibowitz's report today in
pgsql-bugs? I cannot reproduce any such problem --- and my local
timezone database claims that MET DST transitions are the last week of
March, never the first week of April, anyway. There's something funny
going on there.

Yes. I tried the example on 7.0.2 (and 7.1) and could not get it to
misbehave. I was guessing that it involves string->date conversion,
which may pass through timestamp to get there, but it looks like there
is an explicit text->date conversion function so time zone should just
never be involved. Really!

I dug through the conversions involved (basically date_in and date_out).
AFAICS the only place where timezone could possibly get involved is that
DecodeDateTime attempts to derive a timezone for the given date/time.
It does this by calling mktime() (line 878 in datetime.c in current
sources). If mktime() screws up and alters the tm->tm_mday field then
we'd see the reported behavior. I really don't see any other place that
it could be happening.

A platform-specific bug in mktime would do nicely to explain why we
can't reproduce the problem, too ... OTOH, it's hard to believe such a
bug would have persisted across several RedHat releases, which seems to
be necessary to explain the reports.

regards, tom lane

I dug through the conversions involved (basically date_in and date_out).
AFAICS the only place where timezone could possibly get involved is that
DecodeDateTime attempts to derive a timezone for the given date/time.
It does this by calling mktime() (line 878 in datetime.c in current
sources). If mktime() screws up and alters the tm->tm_mday field then
we'd see the reported behavior. I really don't see any other place that
it could be happening.

Yes. It is possible to call DecodeDateTime() so that it *never* tries to
derive a time zone (call with the last argument set to NULL), but that
also causes it to reject date/time strings which have an explicit time
zone. We certainly would want to accept something like

select date('1993-04-02 04:05:06 PST');

(even though for a date-only result it is overspecified), so calling
with NULL is not the right thing to do (I tried it, then realized the
bad effect).

A platform-specific bug in mktime would do nicely to explain why we
can't reproduce the problem, too ... OTOH, it's hard to believe such a
bug would have persisted across several RedHat releases, which seems to
be necessary to explain the reports.

It is also hard to see how such a bug would not be similarly manifested
in Mandrake, Debian, etc etc.

For this particular problem, I'd like to see the "DateStyle" setting,
the time zone setting, an example of the problem (does not require a
table, but just a date string conversion), and the output of "zdump -v"
for the timezone in question.

I'm not sure how to handle date/time bug reports which are not
reproducible on our machines. Certainly date/time issues are the most
problematic in terms of number of bug reports, but they are also
probably the most sensitive to machine configuration and user's
location, so all in all I think the types are doing very well. I don't
want to sound complacent, but it is probably sufficient to fix
reproducible problems to keep our date/time data types viable, and we
are doing far more than that over time :)

- Thomas

On Mon, 30 Apr 2001, Tom Lane wrote:

The Hermit Hacker <scrappy@hub.org> writes:

Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?

FWIW, I've finished committing all the bug fixes I have pending.

There are several worrisome unresolved bug reports, but AFAIK none are
for reproducible conditions, and I don't think we can make any more
progress on them without more information. I doubt we should hold up
the 7.1.1 release while waiting to see if we get any.

We do have that not-quite-done QNX4 port patch in hand. Perhaps we
should give Bernd another day to respond to the comments on that and
squeeze it into 7.1.1.

How about I do another end of week release? Give Bernd until Friday to
sort through the patch with everyone without it being rushed ...

Hi,

just noticed Marc has restarted postmaster at db.hub.org and
forget to specify -e option (European format!) for backend. That's why
fts.postgresql.org doesn't works properly. I've sent message to him
but probably better if somebody could talk with Marc or
restart corresponding postamaster at db.hub.rg.

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

I extracted from Ayal the info that he was using timezone
'Asia/Jerusalem'. That zone has the interesting property that
the DST transitions happen *at midnight*, not at a sane hour like 2AM.
I suspect that that is triggering various & sundry bugs in older
versions of mktime().

On a relatively recent Linux (LinuxPPC 2000/Q4) the worst misbehavior
I can find is

regression=# select timestamp('1993-04-02');
timestamp
------------------------
1993-04-02 01:00:00+03
(1 row)

which is about the best we can do, seeing as how midnight local time
just plain does not exist on that date in that timezone.

However on an older Linux (RedHat 5.1) I get:

regression=# select timestamp('1993-04-02');
timestamp
------------------------
2027-04-11 17:45:25+03
(1 row)

which is a tad startling. Tracing through DecodeDateTime tells the
tale:

(gdb) s
875 mktime(tm);
(gdb) p *tm
$2 = {tm_sec = 0, tm_min = 0, tm_hour = 0, tm_mday = 2, tm_mon = 3,
tm_year = 93, tm_wday = 0, tm_yday = 0, tm_isdst = -1,
tm_gmtoff = -1073745925, tm_zone = 0x81420c0 "\203�\ff�E�\001"}
(gdb) n
876 tm->tm_year += 1900;
(gdb) p *tm
$3 = {tm_sec = 0, tm_min = 0, tm_hour = 0, tm_mday = 2, tm_mon = 3,
tm_year = 93, tm_wday = 0, tm_yday = 0, tm_isdst = -1,
tm_gmtoff = -1073745925, tm_zone = 0x81420c0 "\203�\ff�E�\001"}
(gdb) s
877 tm->tm_mon += 1;
(gdb) s
880 *tzp = -(tm->tm_gmtoff); /* tm_gmtoff is

Ooops.

I recommend that all uses of tm->tm_gmtoff from mktime() be guarded
along the lines of
if (tm->tm_isdst >= 0)
believe gmtoff
else
assume GMT

However, this still does not account for the reported failure of date()
since that code path doesn't use the returned value of *tzp --- and
indeed I get the right thing from select date('1993-04-02'), despite
the failure of mktime(). Probably the behavior of mktime() in this
situation varies across different glibc releases. Would some other
folk try

set timezone to 'Asia/Jerusalem';
select timestamp('1993-04-02');
select date('1993-04-02');

and report what you see?

BTW, I also see

regression=# select timestamp(date('1993-04-02'));
ERROR: Unable to convert date to tm

which is just what you'd expect if mktime() fails for this input;
I suppose there's nothing we can do about that except advise people
to update to a less broken libc...

regards, tom lane

just noticed Marc has restarted postmaster at db.hub.org and
forget to specify -e option (European format!) for backend. That's why
fts.postgresql.org doesn't works properly. I've sent message to him
but probably better if somebody could talk with Marc or
restart corresponding postamaster at db.hub.rg.

Hmm. Might be a good time to consider using ISO time formats ;)

Could I help with something in that regard?

- Thomas

On Mon, Apr 30, 2001 at 07:12:16PM -0400, Tom Lane wrote:

There will surely be a 7.1.2. I vote against waiting for it.

Possibly, but one hopes 7.1.2 will be a few months away ...

Is there a chance for the %TYPE patch for PL/pgSQL to make it into
7.1.2?

	-Roberto
-- 
+----| http://fslc.usu.edu USU Free Software & GNU/Linux Club |------+
  Roberto Mello - Computer Science, USU - http://www.brasileiro.net 
       http://www.sdl.usu.edu - Space Dynamics Lab, Developer    
Junior, quit playing with your floppy!

Roberto Mello <rmello@cc.usu.edu> writes:

Is there a chance for the %TYPE patch for PL/pgSQL to make it into
7.1.2?

We are not in the habit of putting new features into dot-releases.
I'd have to vote against this, particularly seeing that the patch
in question is unreviewed and untested...

regards, tom lane

I extracted from Ayal the info that he was using timezone
'Asia/Jerusalem'. That zone has the interesting property that
the DST transitions happen *at midnight*, not at a sane hour like 2AM.
I suspect that that is triggering various & sundry bugs in older
versions of mktime().

Ahhh! So "GMT+2" was just an approximation, eh? :/

On a relatively recent Linux (LinuxPPC 2000/Q4) the worst misbehavior
I can find is

...

However on an older Linux (RedHat 5.1) I get:

...

I recommend that all uses of tm->tm_gmtoff from mktime() be guarded
along the lines of
if (tm->tm_isdst >= 0)
believe gmtoff
else
assume GMT

I'm not sure that tm_isdst == -1 is a legitimate indicator for mktime()
failure on all platforms; it indicates "don't know", but afaik there is
no defined behavior for the rest of the fields in that case. Can we be
assured that for all platforms the other fields are not damaged?

However, this still does not account for the reported failure of date()
since that code path doesn't use the returned value of *tzp --- and
indeed I get the right thing from select date('1993-04-02'), despite
the failure of mktime(). Probably the behavior of mktime() in this
situation varies across different glibc releases.

...

which is just what you'd expect if mktime() fails for this input;
I suppose there's nothing we can do about that except advise people
to update to a less broken libc...

Not sure how much code we should put in to guard for cases we can't even
test (RH 5.1 is pretty old).

- Thomas

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

I'm not sure that tm_isdst == -1 is a legitimate indicator for mktime()
failure on all platforms; it indicates "don't know", but afaik there is
no defined behavior for the rest of the fields in that case. Can we be
assured that for all platforms the other fields are not damaged?

We can't; further investigation showed that another form of the problem
was mktime() setting the y/m/d/h/m/s fields one hour earlier than what
it was given --- ie, pass it 00:00:00 of a DST forward transition date,
get back neither 00:00:00 nor 01:00:00 (either of which would be
plausible) but 23:00:00 of the day before!

What I did about this was to coalesce all of the three or four places
that use mktime just to probe for DST status into a single routine
(DetermineLocalTimeZone) that is careful to pass mktime a copy of the
original struct tm. No matter how brain dead the system mktime is,
it can't screw up the other fields that way ;-). Then we trust
tm_isdst and tm_gmtoff only if tm_isdst >= 0. Possibly we'll find
that it'd be a good idea to test also for return value == -1, but
the tm_isdst test seems to be sufficient for the known bug cases.

Not sure how much code we should put in to guard for cases we can't even
test (RH 5.1 is pretty old).

Yeah, but the above-described behavior is reported on RH 7.1 (by two
different people). I'm afraid we can't ignore that...

regards, tom lane