[Firebird-devel] libedit update for 2.5.x
libedit will be updated and patched for 2.5.x branch also ? I ask this because in debian libedit2 i s already updated and it would be nice if also in the 2.5.x branch would be done so http://packages.debian.org/sid/libedit2 -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Reopened: (CORE-4185) FB craches with "invalid lock id (NNNNN), errno: 0" when all connects except one (that locks some record) are forcely killed
[ http://tracker.firebirdsql.org/browse/CORE-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Peshkov reopened CORE-4185: - Fix is incomplete and wrong > FB craches with "invalid lock id (N), errno: 0" when all connects except > one (that locks some record) are forcely killed > > > Key: CORE-4185 > URL: http://tracker.firebirdsql.org/browse/CORE-4185 > Project: Firebird Core > Issue Type: Bug > Components: Engine >Affects Versions: 3.0 Alpha 1 >Reporter: Pavel Zotov >Assignee: Alexander Peshkov > Fix For: 3.0 Alpha 2 > > Attachments: core_firebird_log_+_LT_rawdump.rar > > > Scenario: > === > 1. Database with table TLOCK(id int, f01 int) and single record in it (e.g > ID=1, F01=100). > 2. Machine #1. > Connect to this database via TCP and do: > SELECT * FROM TLOCK WHERE ID=1; > UPDATE TLOCK SET F01=RAND()*1 WHERE ID=1; > SELECT * FROM TLOCK WHERE ID=1; > 3. Machine #2. > Run batch (or shell) that: > 3.1. Opens simultaneously N test ISQLs (I've reproduced result on at least > N=10) which all should just stay quiet in "SQL>" prompt after being loaded; > 3.2. Waits ~10 seconds to insure that all ISQLs do establishe connect to > the database; > 3.3. Runs the utility from SysInternals package to kill all ISQL processes: > PSKILL.EXE ISQL; > 3.4. Waits again ~10 seconds to insure that all test windows and processes > are killed; > 3.5. Loop to step 3.1 > After some (short) time the Firebird daemon will craches with producing core > file, LockTable dump and the following message in it's log: > --- > vmoel63.local Tue Aug 20 13:37:35 2013 > Fatal lock manager error: invalid lock id (143960), errno: 0 > vmoel63.local Tue Aug 20 13:37:59 2013 > /opt/fb30cs/bin/fbguard: /opt/fb30cs/bin/firebird terminated abnormally > (-1) > vmoel63.local Tue Aug 20 13:37:59 2013 > /opt/fb30cs/bin/fbguard: guardian starting /opt/fb30cs/bin/firebird > -- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Unicode UTF-16 etc
>>> I'd prefer to have an option to use UTF-16 (treated as a 2-byte >>> character set with surrogate pairs) as that will only halve the >>> maximum allowed number of characters. The maximum allowed number of characters in Unicode is about 1 Million. Which can be perfectly represented by either UTF-8 or UTF-16. >> Nope. If you take into account surrogates, UTF-16 will have the >> same maximum of 4 bytes per character. You should think of that not as 4 bytes but as two 16-bit words. > You are missing my point. There are two ways to consider UTF-16, one is > your interpretation where each character is 2-4 bytes, or as 2 byte > 'characters', where some codepoints are built from a surrogate pair > (which essential means that some codepoints require two 'characters', > which in isolation don't make much sense). I don't get your point. UTF-16 is a standard that uses one or two 16-bit words to represent one Unicode character (code point). That's the only way to consider it. (UCS-2 uses one 16-bit word, which is only usable for BMP characters, making it completely useless today.) > As most languages don't need those surrogate pairs for their > codepoints/glyphs, it is easier to consider UTF-16 to be 2 byte. As far > as I know this is how most UTF-16 implementations handle it. You mix up words like "byte", "character", "codepoint", and "glyph". In the good old ASCII days we had a 1:1:1 relationship between "bytes", "characters" and "glyphs". Today there is no such relationship anymore. In the Unicode system, you usually need more than one byte to represent a character. You may need more than one character to represent a glyph. Regards Stefan -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Unicode UTF-16 etc
On Mon, Sep 02, 2013 at 03:30:26PM +0200, Stefan Heymann wrote: > >>> I'd prefer to have an option to use UTF-16 (treated as a 2-byte > >>> character set with surrogate pairs) as that will only halve the > >>> maximum allowed number of characters. > > The maximum allowed number of characters in Unicode is about 1 > Million. Which can be perfectly represented by either UTF-8 or UTF-16. If I understood correctly, Mark meant maximum possible length for char() and varchar() types, not the number of characters that can be represented. But as already pointed out, to be able to get to one half of the length available for 8-bit encodings, one would actually have to use UCS-2, not UTF-16. Michal Kubeček -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] libedit update for 2.5.x
On 09/02/13 16:06, marius adrian popa wrote: > libedit will be updated and patched for 2.5.x branch also ? > > I ask this because in debian libedit2 i s already updated and it would > be nice if also in the 2.5.x branch would be done so > I think that all distros, not debian only, support fresh editline library. And (provided they build --with-sustem-editline, in which I'm quite sure) they use it in firebird. What about backporting built-in library - I already have one negative response, rather fresh (and specific version automake-1.12. but not earlier than 1.12.6) was needed to build firebird. That does not seem to be a problem in trunk, but requires changing build environment for 2.5 in minor release, which is IMO not good. -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] For discussion: allowing multiple changes in ALTER COLUMN clause (ALTER TABLE)
OK, here's another "humble" suggestion that folks might want to consider for a future version: Support an "upgrade " syntactically parallel to "create ". The "upgrade" version, however, takes the existing object, compares it to the described object, and makes any changes necessary. If they are the same, nothing happens. I did this in the original Netfrastructure implementation. It was close to magical. The development GUI would generate SQL upgrade syntax in a command window when the table was double clicked. All you had to do was tweak the table definition and execute the statement. Very, very cool. And it meant that I never had to really learn the dreadful SQL "alter " syntax. Ugh. On 9/1/2013 7:43 AM, Robbert-Jan wrote: Hi, I like your opinion on the following sql improvement before I submit a JIRA request: For domains it is possible to alter multiple changes in one statement. For example: CREATE DOMAIN MyDomain INTEGER DEFAULT 0 NOT NULL ALTER DOMAIN MyDomain TO MyDomain2 TYPE BIGINT SET DEFAULT 1 NULL /* changes both name, type, default value and nullability */ For columns it is not possible to specify more than one change in the ALTER COLUMN clause. For example, this is *not* allowed: ALTER TABLE MyTable ADD MyColumn INTEGER DEFAULT 0 NOT NULL ALTER TABLE MyTable ALTER COLUMN MyColumn TO MyColumn2 TYPE BIGINT SET DEFAULT 1 NULL In stead, you have to use: ALTER TABLE MyTable ALTER COLUMN MyColumn To MyColumn2, ALTER COLUMN MyColumn2 TYPE BIGINT, ALTER COLUMN MyColumn2 SET DEFAULT 1, ALTER COLUMN MyColumn2 NULL or use separate statements (following pure SQL standard). I like to propose to allow multiple changes in one ALTER COLUMN clause. This is more consistent with the ALTER DOMAIN syntax and more compact (readable). What do you think? Kind regards, Robert NL -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrkFirebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Record Encoding, was Unicode UTF-16 etc
Let me offer another humble suggestion, though one that should not be a candidate for FB3: Ditch the concept of fixed length records, completely and forever. Let me sketch the scheme I used in Netfrastructure / Falcon, which originated from a suggestion on this list. The key elements are: 1. A record encoding that uses a single byte to encode type, type and value, type and length, or type and length of byte count. If anyone is interested, I could post the Falcon code for reference. There would be separate byte codes for, say, the integers from -10 to 30 (arbitrary), and integers with one to eight value bytes. Strings, in turn, might have codes for strings from zero to 40 bytes and codes for strings with 1 to 4 count bytes. Blobs are represented with blob id types. 2. The analog of the formats table represents only the mapping from logical field id to physical field sequence for a given record version number. 3. Parsing a record is cheap -- a single byte table that gives data length or the number of count bytes (which need to be decoded of course). 4. An active record in member has field offset record and high water mark to avoid re-parsing fields. The Netfrastructure implementation made provision for 8 bit, 16 kit, and 32 bit offsets depending on record length, so very long records could be accommodated. 5. Value decode is a simple switch statement on type. Using a large customer database, encoded records where on average 60% the size of Firebird run length encoding and about 30% of the Firebird record in memory. In both Falcon and NuoDB (I stuck with the Falcon code) the code was regularly profiled. Record encode and decode did show up, but in the range of 2 or 3% of cycles, all inclusive. But since records were much smaller and didn't require compression and decompression, the CPU cost was probably a wash and maybe even is small win. There are two other huge fringe benefits. One is that numbers are numbers -- to max size need be given. The other is that there is no declared max length of strings other than a 32 bit count (which could be trivially extended). There are SQL standard, language, and API issues and enforcement issues, of course. But these are easily worked through. Netfrastructure handled all official SQL types plus "number" (no magnitude) and "string" (no length). MySQL was so wedded to fixed length records that they couldn't even bring themselves to think about alternatives. The Rdb/ELN / Galaxy / Interbase / Firebird family has almost supported various length records in the ODS. Maybe it's almost time to take full advantage of this. On 8/31/2013 7:46 AM, Ann Harrison wrote: On Aug 31, 2013, at 4:55 AM, Mark Rotteveel wrote: On 29-8-2013 17:41, Jim Starkey wrote: Paradoxically, Japanese strings tend to be shorter in UTF-8 than 16 bit Unicode. The reason is simple: There are enough single byte characters -- punctuation, control characters, and digits -- stay as single bytes, double byte characters are a wash, and the single byte characters generally balance the number of three byte characters. UTF-16 is a mess with nasty problems of endians, multi-word characters, and illegal codepoints to worry about. Unfortunately the implementation of UTF-8 in Firebird is annoying because it reduces that maximum allowed number of characters to a 1/4 of that for single byte character sets making it necessary to switch to blobs sooner. A better solution is to change the implementation of CHAR and VARCHAR to accept longer strings. Cheers, Ann l -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrkFirebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Unicode UTF-16 etc
> Unfortunately the implementation of UTF-8 in Firebird is annoying > because it reduces that maximum allowed number of characters to a 1/4 of > that for single byte character sets making it necessary to switch to > blobs sooner. IIRC, old Interbase versions defined maximum Varchar length in *bytes*, which led to situation that *some* utf-8(then fss) strings could cause runtime error when storing them. To avoid this, later versions grant that *all* possible strings can be stored without raising error. It is done by limiting maximum declared length of varchar to accomodate the worst case = as if all characters in the string are 4 bytes (utf-8) or 3 bytes (fss). I think quite a lot of applications do not need such strong limit. E.g. application that I work on now is so depending on czech environment (laws, data suppliers, etc.) that it could never ever use more than 2 byte utf-8 character. I think it could be useful to allow to define own bytes/character constant for computing maximum varchar length (RDB$CHARACTER_SETS.RDB$BYTES_PER_CHARACTER) Ivan -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] libedit update for 2.5.x
On 02.09.2013 17:04, Alex Peshkoff wrote: > On 09/02/13 16:06, marius adrian popa wrote: >> libedit will be updated and patched for 2.5.x branch also ? >> >> I ask this because in debian libedit2 i s already updated and it would >> be nice if also in the 2.5.x branch would be done so >> > > I think that all distros, not debian only, support fresh editline > library. And (provided they build --with-sustem-editline, in which I'm > quite sure) they use it in firebird. Thats not enough to enable full UTF8 support, there is a small patch to editline needed and the editline library has to be build with --wide-char-enabled. > What about backporting built-in > library - I already have one negative response, rather fresh (and > specific version automake-1.12. but not earlier than 1.12.6) was needed > to build firebird. This could be fixed by either including editline to the autogen.sh script or adding calls to autoreconf etc. to Makefile.in.extern.editline. Frank -- "Fascinating creatures, phoenixes, they can carry immensely heavy loads, their tears have healing powers and they make highly faithful pets." - J.K. Rowling -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
