Re: [BUGS] failed to fetch tuple for EvalPlanQual recheck
Hello. I tried the test in PostgreSQL9.0 beta4. And it never reproduces the EvalPlanQual recheck error! Thank you for all reply!! >> When I tested in PostgreSQL9 beta3,I got an error. >> > >> == >> select * from part_bug where HIRENUM=4 for update; >> failed to fetch tuple for EvalPlanQual recheck >> == >> > This seems to be a simple oversight in the new EvalPlanQual logic --- > one place forgot to consider the possibility of inactive child tables. > I've committed a patch. Thanks for the report! > > regards, tom lane > > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5586: network installation
The following bug has been logged online: Bug reference: 5586 Logged by: franklyn Email address: ff-ferr...@hotmail.com PostgreSQL version: 8.4.4 Operating system: windows 7 Description:network installation Details: Output folder: C:\Program Files (x86)\RVG Software\Holdem Manager Is admin account Extract: AcePokerCoach.dll... 100% Extract: Acid Library.dll... 100% Extract: Acid Library.snk Extract: AxInterop.ShockwaveFlashObjects.dll... 100% Extract: Cards0.png... 100% Extract: ColorBar.dll... 100% Extract: Config.HEM Extract: Converter.dll... 100% Extract: CookComputing.XmlRpcV2.dll... 100% Extract: DBControlPanel.exe... 100% Extract: DeployLX.Licensing.v3.dll... 100% Extract: DevComponents.DotNetBar2.dll... 100% Extract: DundasWinChart.dll... 100% Extract: EasyHook.dll... 100% Extract: EasyHook32.dll... 100% Extract: EasyHook32Svc.exe... 100% Extract: EasyHook64.dll... 100% Extract: EasyHook64Svc.exe... 100% Extract: EnhancedWebBrowser.dll... 100% Extract: FTP6Max3.txt... 100% Extract: FishFinder.txt... 100% Extract: GlassButton.dll... 100% Extract: HEMGUI.dll... 100% Extract: HMArticles.exe... 100% Extract: HMBackup.exe... 100% Extract: HMClass.dll... 100% Extract: HMHud.exe... 100% Extract: HMImport.exe... 100% Extract: HSFtp.dll... 100% Extract: HSQt.dll... 100% Extract: HoldemManager.exe... 100% Extract: HoldemManager.exe.config... 100% Extract: HoldemVision.dll... 100% Extract: ICSharpCode.SharpZipLib.dll... 100% Extract: Interop.SHDocVw.dll... 100% Extract: Interop.ShockwaveFlashObjects.dll... 100% Extract: KeyGenerateClassLibrary.dll... 100% Extract: Leak Buster Limit Admin Guide.pdf... 100% Extract: Leak Buster Updater.exe... 100% Extract: Leak Buster V2 5 Administration Guide.pdf... 100% Extract: LeakBuster2.5 Limit.dll... 100% Extract: LeakBuster2.5.dll... 100% Extract: Library.dll... 100% Extract: License.rtf... 100% Extract: Microsoft.VisualBasic.PowerPacks.dll... 100% Extract: Mono.Security.dll... 100% Extract: Npgsql.dll... 100% Extract: Open Leak Buster V2 5 Administration Guide.pdf file.lnk... 100% Extract: PosConfig.HEM Extract: QtCore4.dll... 100% Extract: QtGui4.dll... 100% Extract: SitNGoWizard.1.1.exe... 100% Extract: SitNGoWizard.General.2.0.dll... 100% Extract: SitNGoWizard.Localization.2.0.dll... 100% Extract: SitNGoWizard.OpponentModel.2.0.dll... 100% Extract: SitNGoWizard.Poker.2.0.dll... 100% Extract: SitNGoWizard.UI.2.0.dll... 100% Extract: SitNGoWizard.chm... 100% Extract: Softelvdm.Controls.dll... 100% Extract: Softelvdm.SftTreeNET.dll... 100% Extract: System.Data.SQLite.dll... 100% Extract: System.Windows.Controls.Theming.ExpressionDark.dll... 100% Extract: System.Windows.Controls.Theming.dll... 100% Extract: TextboxHook.dll... 100% Extract: UninstallHoldemManager.exe... 100% Extract: WPFToolkit.dll... 100% Extract: WPFVisifire.Charts.dll... 100% Extract: ZedGraph.dll... 100% Extract: absolute.dll... 100% Extract: everest.dll... 100% Extract: ftp.dll... 100% Extract: ftpv2.dll... 100% Extract: hemff.dll... 100% Extract: ip.dll... 100% Extract: log4net.dll... 100% Extract: masks.txt... 100% Extract: mousehook.dll... 100% Extract: og.dll... 100% Extract: prima.dll... 100% Extract: pty.dll... 100% Extract: stars.dll... 100% Output folder: C:\Program Files (x86)\RVG Software\Holdem Manager\Assemblies Extract: DropDownPanel.dll... 100% Extract: PropertyGridEx.dll... 100% Extract: Syncfusion.Chart.Windows.dll... 100% Extract: Syncfusion.Core.dll... 100% Extract: Syncfusion.Grid.Base.dll... 100% Extract: Syncfusion.Grid.Grouping.Windows.dll... 100% Extract: Syncfusion.Grid.Windows.dll... 100% Extract: Syncfusion.Grid.grouping.Base.dll... 100% Extract: Syncfusion.Grouping.Base.dll... 100% Extract: Syncfusion.Grouping.Windows.dll... 100% Extract: Syncfusion.HTMLUI.Base.dll... 100% Extract: Syncfusion.HTMLUI.Windows.dll... 100% Extract: Syncfusion.Shared.Base.dll... 100% Extract: Syncfusion.Shared.Windows.dll... 100% Extract: Syncfusion.Tools.Base.dll... 100% Extract: Syncfusion.Tools.Windows.dll... 100% Extract: Syncfusion.chart.Base.dll... 100% Extract: log4net.dll... 100% Extract: zlib.net.dll... 100% Output folder: C:\Program Files (x86)\RVG Software\Holdem Manager\Config Extract: Closehud.txt Extract: Default_CBet.pop... 100% Extract: Default_Flop.pop... 100% Extract: Default_Postflop.pop... 100% Extract: Default_Preflop.pop... 100% Extract: Default_River.pop... 100% Extract: Default_Showdown.pop... 100% Extract: Default_Steal.pop... 100% Extract: Default_Turn.pop... 100% Extract: Default_VsPre.pop... 100% Extract: Default_Winrate.pop... 100% Extract: ExeNames.txt... 100% Extract: FTPRushTables.xml... 100% Extract: HandCategories.txt... 100% Extract: HoldemManager.config... 100% Extract: NL6Max.StatTrigger... 100% Extract: PosPref2.txt Extract: PosPref4.txt... 100% Extract: StatRanges.xml... 100% Extract: prefs.xml... 100% Extract: prefs.xml_1.04.13... 100% Extract: prefs.xml_1.05.08... 100% Extract: sample.pop... 100% Output folder: C:\Program
[BUGS] BUG #5587: Installer non-default file association problem
The following bug has been logged online: Bug reference: 5587 Logged by: Mike Parfitt Email address: m_parf...@hotmail.com PostgreSQL version: 8.4.4.1 Operating system: Windows XP SP3 Description:Installer non-default file association problem Details: When the installer halts showing "Initialising the database cluster (this may take a few minutes)" message it may be because that PC has a non-default .bat file association. In my case, I used Process Explorer and looked at the other processes it had spawned :- postgresql-8.4.4-1-windows.exe cscript.exe UEDIT32.exe UEDIT32.EXE (UltraEdit) is my text editor of choice. Either the installer should test whether the .bat file association is going to start the right program, or the right program should be included in the parameter passed to the .Run function. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5588: I use a lot of the "INHERITS", results of tests found that the performance is very low.
The following bug has been logged online: Bug reference: 5588 Logged by: runner.mei Email address: runner@gmail.com PostgreSQL version: 8.4.4 Operating system: windows Description:I use a lot of the "INHERITS", results of tests found that the performance is very low. Details: Hello, I try to build a cmdb database with using postgresql , I use a lot of the "INHERITS", results of tests found that the performance is very low, there are 2,000,000 pieces of data when the data when a data query, it was however spent 1672 ms, I was wrong it? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5590: undefined shift behavior
The following bug has been logged online: Bug reference: 5590 Logged by: John Regehr Email address: reg...@cs.utah.edu PostgreSQL version: head 8/2/10 Operating system: OSX Description:undefined shift behavior Details: During a "make check" the left-shift operator at tsquery_util.c 48:18 is passed a negative right-hand argument a number of times. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5591: Creating and using databases
The following bug has been logged online: Bug reference: 5591 Logged by: Divyaprakash Email address: divyaprakas...@celstream.com PostgreSQL version: postgresql-8.4. Operating system: Microsoft Windows XP Professional Version 2002 Service Pack 3 Description:Creating and using databases Details: hi, I am unable to create the databases after the successful installation of postgresql. please help me as early as possible. Regards YDP -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5590: undefined shift behavior
"John Regehr" writes: > Bug reference: 5590 > Logged by: John Regehr > Email address: reg...@cs.utah.edu > PostgreSQL version: head 8/2/10 > Operating system: OSX > Description:undefined shift behavior > Details: > During a "make check" the left-shift operator at tsquery_util.c 48:18 is > passed a negative right-hand argument a number of times. Hmm. valcrc is declared as signed int32, so depending on what your compiler thinks the semantics of % is, this clearly can potentially happen. I notice the same problem in makeTSQuerySign() in tsquery_op.c. The fix is presumably to cast the valcrc value to unsigned int before executing %. However, I'm a bit worried about whether this could change the results, and if it did whether that would invalidate any on-disk data structures. Oleg, Teodor, do either TSQuerySign or QTNode.sign ever get to disk? John: how did you detect this? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5591: Creating and using databases
"Divyaprakash" wrote: > I am unable to create the databases after the successful > installation of postgresql. please help me as early as possible. We need more information before we can be much help. Please read this and post again on the pgsql-general list. It really doesn't sound like a bug. http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5590: undefined shift behavior
Hi Tom, One of my students has hacked Clang to detect integer undefined behaviors in C, like this shift problem or signed overflows. This was the only problem that came up during a "make check" of a postgresql with this checking turned on, which is pretty cool. I'd expect to be able to find more problems if I could get hold of a good fuzz tester for postgresql, or at least some much larger test inputs. Are there any of these you folks would suggest that I use? Thanks, John On 08/02/2010 09:06 AM, Tom Lane wrote: > "John Regehr" writes: >> Bug reference: 5590 >> Logged by: John Regehr >> Email address: reg...@cs.utah.edu >> PostgreSQL version: head 8/2/10 >> Operating system: OSX >> Description:undefined shift behavior >> Details: > >> During a "make check" the left-shift operator at tsquery_util.c 48:18 is >> passed a negative right-hand argument a number of times. > > Hmm. valcrc is declared as signed int32, so depending on what your > compiler thinks the semantics of % is, this clearly can potentially > happen. I notice the same problem in makeTSQuerySign() in tsquery_op.c. > > The fix is presumably to cast the valcrc value to unsigned int before > executing %. However, I'm a bit worried about whether this could change > the results, and if it did whether that would invalidate any on-disk > data structures. Oleg, Teodor, do either TSQuerySign or QTNode.sign > ever get to disk? > > John: how did you detect this? > > regards, tom lane > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5590: undefined shift behavior
John Regehr writes: > On 08/02/2010 09:06 AM, Tom Lane wrote: >> John: how did you detect this? > One of my students has hacked Clang to detect integer undefined > behaviors in C, like this shift problem or signed overflows. Cool. > This was > the only problem that came up during a "make check" of a postgresql with > this checking turned on, which is pretty cool. Hrm, I'd have expected you to see a few integer overflows during the regression tests --- we do test that the overflow checks in places like int4pl work. You might be interested in this concurrent thread: http://archives.postgresql.org/pgsql-hackers/2010-08/msg00024.php particularly the comments about overflow. > I'd expect to be able to find more problems if I could get hold of a > good fuzz tester for postgresql, or at least some much larger test > inputs. Are there any of these you folks would suggest that I use? Yeah, the PG regression tests aren't amazingly good coverage-wise (although running the contrib tests as well as core helps --- did you do that?). I'm afraid I haven't got a good suggestion for you. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5590: undefined shift behavior
Hrm, I'd have expected you to see a few integer overflows during the regression tests --- we do test that the overflow checks in places like int4pl work. I saw no signed overflows. Our patch still has some rough edges, but this part is pretty well tested. Perhaps the int4pl checks fire before the overflowing operation can be performed, stopping them from happening? Anyway when I get a bit of time I'll stub out the checks and make sure that I see some checks firing. You might be interested in this concurrent thread: http://archives.postgresql.org/pgsql-hackers/2010-08/msg00024.php particularly the comments about overflow. Thanks. I've been corresponding with Neil about this a bit. Nice to hear that Clang has -fwrapv now, I hadn't known about that. Yeah, the PG regression tests aren't amazingly good coverage-wise (although running the contrib tests as well as core helps --- did you do that?). I'm afraid I haven't got a good suggestion for you. I haven't tried the contrib tests, I'll do that, thanks. Sooner or later we'll push our patch into LLVM and then anyone testing your code can help out. Just randomly: it's trivial to compile postgresql using clang on OSX. However, I cannot get it to work on Linux with or without Peter Eisentraut's patches. It's no big deal since I have a Mac sitting around but I could get stuff done faster on Linux! John -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5590: undefined shift behavior
Tom, on the list you said: "I would be ecstatic if we could write int4pl like this: if (sum_overflows(arg1, arg2)) elog(ERROR, "overflow"); else return arg1 + arg2; " This is effectively what our clang patch does (automatically, for all integer operations). Right now our stuff isn't very efficient (~20% slowdown in SPEC INT) but LLVM does support intrinsics for detecting overflows using processor flags. Currently we cannot use these because they're buggy but we're working to get them fixed. I'd expect our integer-checked binaries to be pretty efficient once this is all working. John On 8/2/2010 10:16 AM, Tom Lane wrote: John Regehr writes: On 08/02/2010 09:06 AM, Tom Lane wrote: John: how did you detect this? One of my students has hacked Clang to detect integer undefined behaviors in C, like this shift problem or signed overflows. Cool. This was the only problem that came up during a "make check" of a postgresql with this checking turned on, which is pretty cool. Hrm, I'd have expected you to see a few integer overflows during the regression tests --- we do test that the overflow checks in places like int4pl work. You might be interested in this concurrent thread: http://archives.postgresql.org/pgsql-hackers/2010-08/msg00024.php particularly the comments about overflow. I'd expect to be able to find more problems if I could get hold of a good fuzz tester for postgresql, or at least some much larger test inputs. Are there any of these you folks would suggest that I use? Yeah, the PG regression tests aren't amazingly good coverage-wise (although running the contrib tests as well as core helps --- did you do that?). I'm afraid I haven't got a good suggestion for you. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5590: undefined shift behavior
Aha-- the -fwrapv flag (which I had though was a nop) screws up our checks. Another rough edge to fix. Removing this flag caused us to find a bunch of integer overflows. I'll start reporting them later today. John -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5592: list of integer undefined behaviors
The following bug has been logged online: Bug reference: 5592 Logged by: John Regehr Email address: reg...@cs.utah.edu PostgreSQL version: head 8/1/10 Operating system: OSX Description:list of integer undefined behaviors Details: Below: a list of integer undefined behaviors that occur when running "make check" on yesterday's postgresql on an x86-64 Mac Mini. Here we're using the ANSI C rules for overflow. Of course many/most of these errors are not errors when the -fwrapv rules are in effect. The last error in the list I already reported, just leaving it in for completeness. If more details are needed please let me know. John Regehr : Op: -, Reason : Signed Subtraction Overflow, UNARY OPERATION: right (int32): -2147483648 : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483647 right (int32): 2 : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int32): 2147483647 right (int32): 2 : Op: +, Reason : Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647 right (int32): 2 : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): -2147483647 right (int32): 2 : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int32): 2147483647 right (int32): 2 : Op: +, Reason : Signed Addition Overflow, BINARY OPERATION: left (int32): 2147483647 right (int32): 2 : Op: +, Reason : Signed Addition Overflow, BINARY OPERATION: left (int64): 100 right (int64): 9223372036854775800 : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int64): -100 right (int64): 9223372036854775800 : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int64): 3908203590239580293 right (int64): 10 : Op: +, Reason : Signed Addition Overflow, BINARY OPERATION: left (int64): 9223372036854775800 right (int64): 9 : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int64): 100 right (int64): 9223372036854775800 : Op: -, Reason : Signed Subtraction Overflow, UNARY OPERATION: right (int64): -9223372036854775808 : Op: +, Reason : Signed Addition Overflow, BINARY OPERATION: left (int64): 9223372036854775800 right (int64): 9223372036854775800 : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int64): 9223372036854775800 right (int64): -9223372036854775800 : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int64): 4567890123456789 right (int64): 4567890123456789 : Op: -, Reason : Signed Subtraction Overflow, UNARY OPERATION: right (int64): -9223372036854775808 : Op: +, Reason : Signed Addition Overflow, BINARY OPERATION: left (int64): 9223372036854775800 right (int64): 100 : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int64): -9223372036854775800 right (int64): 100 : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int64): 9223372036854775800 right (int64): 100 : Op: +, Reason : Signed Addition Overflow, BINARY OPERATION: left (int64): 100 right (int64): 9223372036854775800 : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int64): -100 right (int64): 9223372036854775800 : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int64): 100 right (int64): 9223372036854775800 : Op: +, Reason : Signed Addition Overflow, BINARY OPERATION: left (int64): 9223372036854775800 right (int64): 100 : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int64): -9223372036854775800 right (int64): 100 : Op: *, Reason : Signed Multiplication Overflow, BINARY OPERATION: left (int64): 9223372036854775800 right (int64): 100 : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): 2147483644 right (int32): -2147483648 : Op: -, Reason : Signed Subtraction Overflow, BINARY OPERATION: left (int32): 2147483644 right (int32): -2147483648 : Op: <<, Reason : Signed Left Shift Error: Right operand is negative or is greater than or equal to the width of the promoted left operand, BINARY OPERATION: left (int32): 1 right (int32): -25 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5592: list of integer undefined behaviors
On Mon, Aug 2, 2010 at 7:16 PM, John Regehr wrote: > : Op: -, Reason : Signed Subtraction Overflow, > BINARY OPERATION: left (int32): 2147483644 right (int32): -2147483648 > > : Op: -, Reason : Signed Subtraction Overflow, > BINARY OPERATION: left (int32): 2147483644 right (int32): -2147483648 > These seem to imply that tinterval can contain a start point greater than its end point. I'm not familiar with the rep invariant of tinterval well enough to know if that's true or an indication of a bug elsewhere. I suppose it doesn't matter for cmp since it's still assigning an arbitrary position in the range to the interval. -- greg -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5590: undefined shift behavior
I wrote: > "John Regehr" writes: >> During a "make check" the left-shift operator at tsquery_util.c 48:18 is >> passed a negative right-hand argument a number of times. > Hmm. valcrc is declared as signed int32, so depending on what your > compiler thinks the semantics of % is, this clearly can potentially > happen. I notice the same problem in makeTSQuerySign() in tsquery_op.c. On further investigation, the reason makeTSQuerySign didn't show up in John's test is that it's coded like this: sign |= ((TSQuerySign) 1) << (ptr->qoperand.valcrc % TSQS_SIGLEN); where TSQS_SIGLEN is a macro that involves sizeof(TSQuerySign), and therefore will produce an unsigned result (on most machines anyway). So the % is done in unsigned arithmetic and there's no problem. I think it'd still be a good idea to cast valcrc to unsigned int explicitly here, but this is just for future-proofing not because there's a real bug ATM. Which is a good thing, because TSQuerySign does go to disk so we'd have a backwards-compatibility mess if we had to change this computation. The problem in QT2QTN() is real, on the other hand, because it's coded as node->sign = 1 << (in->qoperand.valcrc % 32); so the modulo is signed. Some investigation shows that Intel machines seem to give the right answer anyway, which has masked the problem for most people. But I find that on PPC, the result of the shift is *zero* if valcrc is negative --- haven't checked, but I wonder if that hardware interprets a negative left shift as a right shift. So on PPC the "sign" comes out as zero about half the time. As best I can tell at the moment, this only results in some inefficiency (because the Bloom filters don't work as intended) in some not-too- heavily-used operations; and the QTNode structures aren't written to disk so there's no compatibility issue from fixing the computation. To sum up: we should insert these casts in HEAD but at the moment I don't see a strong reason to back-patch, nor any indication that we'd be creating a need for a forced initdb. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5592: list of integer undefined behaviors
Greg Stark writes: > On Mon, Aug 2, 2010 at 7:16 PM, John Regehr wrote: >> : Op: -, Reason : Signed Subtraction Overflow, >> BINARY OPERATION: left (int32): 2147483644 right (int32): -2147483648 >> >> : Op: -, Reason : Signed Subtraction Overflow, >> BINARY OPERATION: left (int32): 2147483644 right (int32): -2147483648 > These seem to imply that tinterval can contain a start point greater > than its end point. Just to follow up: all the other ones seem to be non-problems. The one in bitmapset.c is an intentional trick (see the comment for the RIGHTMOST_ONE macro), and all the ones in int.c and int8.c have associated overflow checks. I'm actually a bit surprised that the regression tests seem to exercise all of those overflow checks ;-) Like Greg, I'm not sure about the tinterval_cmp_internal cases. tinterval is pretty much a dead legacy datatype anyway, but probably we oughta fix it if there are failures showing up in the regression tests. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5592: list of integer undefined behaviors
Greg Stark writes:
> On Mon, Aug 2, 2010 at 7:16 PM, John Regehr wrote:
>> : Op: -, Reason : Signed Subtraction Overflow,
>> BINARY OPERATION: left (int32): 2147483644 right (int32): -2147483648
>>
>> : Op: -, Reason : Signed Subtraction Overflow,
>> BINARY OPERATION: left (int32): 2147483644 right (int32): -2147483648
> These seem to imply that tinterval can contain a start point greater
> than its end point.
On closer investigation, the problem is just that you can't fit the
difference INT_MAX minus INT_MIN into an int :-(.
The particular values cited appear to be NOEND_ABSTIME and
NOSTART_ABSTIME, ie "infinity" and "-infinity" in the abstime datatype,
so this is coming from tinterval comparisons involving this value
in the regression tests:
INSERT INTO TINTERVAL_TBL (f1)
VALUES ('["-infinity" "infinity"]');
Although this is the worst case, you could easily get overflows from
intervals with ordinary endpoints that are sufficiently far apart.
Since this is a nearly-dead legacy datatype, I can't get excited about
spending a lot of time on it. What I suggest we do is do the difference
calculation in int64 arithmetic instead of int32.
Another complaint that could be leveled against this code is that
infinity and minus infinity behave way too much like ordinary mortal
timestamps. It would be very easy to select finite timestamps
a, b, c such that this code thinks [a b] is a longer interval than
[c infinity], which is surprising to say the least. However, I can't
get excited about fixing that for abstime/tinterval. It might be
something to consider if anyone ever reimplements this type in a way
that isn't going to fall over in 2038.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
