Thread: 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?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> 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 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 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, 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, Pennsylvania19026
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
Re: date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)
From
Thomas Lockhart
Date:
> 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 ...
Re: Re: date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)
From
Tom Lane
Date:
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 ofif (tm->tm_isdst >= 0) believe gmtoffelse 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
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
> 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
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
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!
Re: Re: date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)
From
Thomas Lockhart
Date:
> 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
Re: Re: date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)
From
Tom Lane
Date:
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