[Firebird-devel] [FB-Tracker] Created: (CORE-5456) Migrating Firebird 2.5.2 to 3.0.1 gbak restore crashes at the end always
Migrating Firebird 2.5.2 to 3.0.1 gbak restore crashes at the end always Key: CORE-5456 URL: http://tracker.firebirdsql.org/browse/CORE-5456 Project: Firebird Core Issue Type: Bug Components: GBAK Affects Versions: 2.5.2 Environment: Code editor Delphi XE4+. Component Firedac or IBSQL, OS:Windows XP+ Reporter: erkan kurtaga Priority: Blocker When Migrating Firebird 2.5.2 to 3.0.1 gbak restore crashes at the end always. We use Delphi XE4 and over and our database components IBSQL and Firedac, I tried restore with command prompt, components restore api and IBExpert restore at its editor manually. Always the same error : gbak:creating indexes gbak:committing metadata gbak:fixing views dbkey length gbak:updating ownership of packages, procedures and tables gbak:adding missing privileges gbak:fixing system generators IBE: Unsuccessful execution caused by a system error that precludes successful execution of subsequent statements. Error reading data from the connection. -- 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 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
Yet another case: Transaction creates a new format, stores some records using this new format, then the server dies. After restart, changes in RDB$FORMATS/RDB$RELATIONS are occasionally backed out. Then it could be impossible to garbage collect the new record versions due to their format being unknown. Dmitry -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
16.01.2017 22:48, Dimitry Sibiryakov wrote: > >> But what about low-level logic like >> VIO_get_current() which must see uncommitted changes? > > If format is created at the end of DDL execution (instead of DFW), it > can/must be > written into database before any DML can write any record with new format. You miss my point. It's written into RDB$FORMATS/RDB$RELATIONS but not committed because transaction is still active. So concurrent transactions cannot see these changes, accordingly to your versioning approach. But VIO_get_current() must see them. Do you suggest to use "dirty read" in such cases? Dmitry -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
16.01.2017 23:08, Adriano dos Santos Fernandes wrote: > > DML changes in the same transaction uses real metadata, i.e., DDL being > changed does not affect DML or metadata cache. I.e. one cannot add a field and populate it with data within a single transaction. This sounds too much restrictive. Dmitry -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
16.01.2017 23:39, Dimitry Sibiryakov wrote: > Then your schema won't solve problem with mixing DDL and DML. Users still > won't be able > to create table and fill it with data in one transaction. How does your idea address this? Between CREATE TABLE and INSERT page space (PP, IRP) must be allocated and initialized. And this cannot be reverted via the undo log in the case of rollback. Dmitry -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
Em 16/01/2017 19:42, Dimitry Sibiryakov escreveu: > 16.01.2017 22:26, Adriano dos Santos Fernandes wrote: >> The semantics of this is even unthinkable, and I doubt anyone is doing >> it in database world. > >PostgreSQL does IIRC. > > Seems to allow to insert data after DDL in the same transaction, but also seems to lock the objects for DML vs DDL and DDL vs DDL in concurrent transaction, so much less megalomaniac than what was vaguely said about versioned metadata. Adriano -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5455) DefaultDbCachePages seems ignored
DefaultDbCachePages seems ignored -- Key: CORE-5455 URL: http://tracker.firebirdsql.org/browse/CORE-5455 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0.2 Environment: Debian 8, kernel: 3.16.0-4-amd64, FB build: 3.0.2.32669-0.amd64, server mode: Super, RAM memory: 32 Gb Reporter: Cristiano Ferrari FB 3.0 release notes tell me that the maximum number of pages that can be configured for the database cache running under 64-bit environment is (2^31)-1 pages, so, 2,147,483,647 pages. I have an database with 5.5 GB (page size 8192, 709504 pages allocated) and want to put all database pages on cache. So, I've set the DefaultDbCachePages parameter in firebird.conf to 800,000 pages. Restarted service via "systemctl restart firebird-superserver.service" (checked from firebird.log). However, gstat show me that page cache still in default values Database "/opt/safebd/dados/base.fdb" Database header page information: Flags 0 Generation 335725 System Change Number0 Page size 8192 ODS version 12.0 Oldest transaction 3389 Oldest active 3390 Oldest snapshot 3390 Next transaction335681 Sequence number 0 Next attachment ID 125 Implementation HW=AMD/Intel/x64 little-endian OS=Linux CC=gcc Shadow count0 Page buffers4096 Next header page0 Database dialect3 Creation date Jan 16, 2017 18:23:01 Attributes Variable header data: Sweep interval: 2 *END* Before that service restart, I've set this parameters on firebird.conf (no one per database): DefaultDbCachePages = 80 AuthServer = Legacy_Auth, Srp, Win_Sspi ## because using 2.5 fbclient.dll RelaxedAliasChecking = 1 ## just in case ConnectionTimeout = 60 WireCrypt = Disabled ## because using 2.5 fbclient.dll LockMemSize = 10M LockHashSlots = 65521 ServerMode = Super -- 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 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
16.01.2017 22:26, Adriano dos Santos Fernandes wrote: > The semantics of this is even unthinkable, and I doubt anyone is doing > it in database world. PostgreSQL does IIRC. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
Em 16/01/2017 18:58, Dimitry Sibiryakov escreveu: > 16.01.2017 21:52, Adriano dos Santos Fernandes wrote: >> It wasn't in my requirements, but it would be possible. >> >> create table ... >> as >> select ... >> >> Would run the select and fill the table at commit time. > >Oh, then I misread your suggestion. I read it as "let's create > table/view/sp in memory > virtually and let user interact with it as it was real, then validate all > changes on > commit and drop them into real database". If you had on mind something > different, I'm sorry. > What you seem to try to fix (mix DML changed in uncommitted tables) is a no-go. It would never work even in single thread considering prepared statement that may be prepared in one transaction and used in another. The semantics of this is even unthinkable, and I doubt anyone is doing it in database world. Adriano -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
16.01.2017 21:52, Adriano dos Santos Fernandes wrote: > It wasn't in my requirements, but it would be possible. > > create table ... > as > select ... > > Would run the select and fill the table at commit time. Oh, then I misread your suggestion. I read it as "let's create table/view/sp in memory virtually and let user interact with it as it was real, then validate all changes on commit and drop them into real database". If you had on mind something different, I'm sorry. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
Em 16/01/2017 18:39, Dimitry Sibiryakov escreveu: > 16.01.2017 21:08, Adriano dos Santos Fernandes wrote: >> DML changes in the same transaction uses real metadata, i.e., DDL being >> changed does not affect DML or metadata cache. >> >> Virtual metadata is specific to DDL. >> >> Record format will be generated when applying the changes in commit. > >Then your schema won't solve problem with mixing DDL and DML. Users still > won't be able > to create table and fill it with data in one transaction. > It wasn't in my requirements, but it would be possible. create table ... as select ... Would run the select and fill the table at commit time. I can't comment on the "versioned metadata" as I never read its specification. It always appears vaguely when I write some specs to the problem. Adriano -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
16.01.2017 21:08, Adriano dos Santos Fernandes wrote: > DML changes in the same transaction uses real metadata, i.e., DDL being > changed does not affect DML or metadata cache. > > Virtual metadata is specific to DDL. > > Record format will be generated when applying the changes in commit. Then your schema won't solve problem with mixing DDL and DML. Users still won't be able to create table and fill it with data in one transaction. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Code style - right margin
Dne 16. 1. 2017 v 18:13 Alex Peshkoff napsal(a): > A few years ago I had to replace my old Sun tube cause it stopped to > work. I wanted to buy 4:3 monitor but there was nothing available with > appropriate matrix (can't work with something worse than IPS/SFT - > problem with eyes). I could not find one and had to start working with > 16:9 monitor. If you do not need widescreen monitor, you can use it oriented vertically ;) -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
Em 16/01/2017 16:42, Dmitry Yemanov escreveu: > 15.01.2017 21:49, Dimitry Sibiryakov wrote: >> >>> When a DDL command is issued, it will not change metadata directly. It >>> will change metadata in a memory structure tied to the current transaction. >> >> I would prefer other approach: DDL command change metadata in database >> directly and >> immediately. Every other transaction use ordinary versioning mechanics to >> see database >> (including metadata) in consistent state according to TIL. Metadata cache is >> either >> reduced or expanded to follow metadata versions in database. DFW is reduced >> to simple >> check for object valid state which is performed on base of ordinary undo log. > > Both ideas could work for views, procedures/functions, triggers -- > they're just objects in memory. But I fail to see how these ideas are > going to work for table format changes. How would records be stored > accordingly to the "virtual" formats? How are formats going to be > uniquely (but without gaps!) numbered across uncommitted transactions? > How concurrent readers should access/skip physically stored records if > their format is unknown/invisible for them? > DML changes in the same transaction uses real metadata, i.e., DDL being changed does not affect DML or metadata cache. Virtual metadata is specific to DDL. Record format will be generated when applying the changes in commit. Adriano -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
16.01.2017 20:23, Dmitry Yemanov wrote: > But what about low-level logic like > VIO_get_current() which must see uncommitted changes? If format is created at the end of DDL execution (instead of DFW), it can/must be written into database before any DML can write any record with new format. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
16.01.2017 22:04, Dimitry Sibiryakov wrote: > > Why "without gaps"? In my vision the first step is to modify garbage > collector/sweeper > to clean unused formats out. OK, it wasn't obvious from your message. >> How concurrent readers should access/skip physically stored records if >> their format is unknown/invisible for them? > > If they can read records, they can read formats. This is the easy case, no problems. But what if they cannot? I don't mean regular readers -- they see active txn id and shouldn't even try to decode these versions. But what about low-level logic like VIO_get_current() which must see uncommitted changes? Dmitry -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
16.01.2017 19:42, Dmitry Yemanov wrote: > But I fail to see how these ideas are > going to work for table format changes. How would records be stored > accordingly to the "virtual" formats? How are formats going to be > uniquely (but without gaps!) numbered across uncommitted transactions? Why "without gaps"? In my vision the first step is to modify garbage collector/sweeper to clean unused formats out. In this case new formats can fill the gaps the same way as this can be done with ordinary records in ordinary table: try first free - get conflict - try next. DDL is not so frequent operation to get high tension here. > How concurrent readers should access/skip physically stored records if > their format is unknown/invisible for them? If they can read records, they can read formats. Careful writes should take care to write format before any data - no difference from ordinary master-detail relationship. Garbage collector should be clever enough to wipe data before metadata. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
15.01.2017 21:49, Dimitry Sibiryakov wrote: > >> When a DDL command is issued, it will not change metadata directly. It >> will change metadata in a memory structure tied to the current transaction. > > I would prefer other approach: DDL command change metadata in database > directly and > immediately. Every other transaction use ordinary versioning mechanics to see > database > (including metadata) in consistent state according to TIL. Metadata cache is > either > reduced or expanded to follow metadata versions in database. DFW is reduced > to simple > check for object valid state which is performed on base of ordinary undo log. Both ideas could work for views, procedures/functions, triggers -- they're just objects in memory. But I fail to see how these ideas are going to work for table format changes. How would records be stored accordingly to the "virtual" formats? How are formats going to be uniquely (but without gaps!) numbered across uncommitted transactions? How concurrent readers should access/skip physically stored records if their format is unknown/invisible for them? Dmitry -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
On 16/01/2017 15:40, Alex Peshkoff wrote: > On 01/15/17 21:00, Adriano dos Santos Fernandes wrote: > I like the suggestion in general but some details worth thinking more. Sure. It's yet more an general idea than a proposal. What I like about it, it's much simple in relation to what we have now while fixing the problems. Another gray area is how to support AFTER DDL triggers, who are supposed to see changes in RDB$ tables. > If it will cause serious troubles - well, we can deny DDL in read > committed transactions. For me it's acceptable. > Returning to 'allow concurrent transactions to change the same objects'. > What if both transactions create same objects or any other phase 1 > conflict? > First committed wins? Yes. > PS. We had more or less same suggestion from Jim >10 years ago (well, no > word 'Virtual' was said that time) but it did not go out of generic > discussion phaze. I don't remember it. Adriano -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Code style - right margin
On 01/16/17 20:19, Adriano dos Santos Fernandes wrote: > PS: finally receiving your emails again > Nice to know, hope big guys in mail.ru / google solved some problems. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
On 01/15/17 21:00, Adriano dos Santos Fernandes wrote: > All, > > First, must say this is based on state-of-the-art modern architecture of > a different field: web libraries/frameworks, using the Virtual DOM. > > First, the (Firebird) problem, but I'll abstain to comment internal > details of DFW. > > About multiple Firebird metadata update (DDL commands) in the same > transaction: > - Is not recommended (at least by me) > - Difficult (if not impossible) to develop right (without bugs) > - Leaves things inconsistently (maybe with corruptions) if DDL and DML > changes same objects > - Is very restrictive on the allowed changes for the users > > At the same time, Firebird adopts the model of not leaving database with > invalidated objects, so allow a single DDL command in auto-commit mode, > more than restrictive, is a no option. > > When users want to change, say, a view, it needs in most cases help from > tools that drop and recreate dependencies. > > Update metadata in production is very problematic. And in todays > business, update in production is necessary. > > So what I call virtual metadata and how would it solve the problems: > > When a DDL command is issued, it will not change metadata directly. It > will change metadata in a memory structure tied to the current transaction. > > It may read metadata from database as needed and change it (in memory > structures). > > At commit time, changed metadata is validated (including validation with > dependencies) and changes are applied to database. > > We may even allow concurrent transactions to change the same objects, as > at commit time we validate and apply changes against the latest > committed metadata. It's a simple approach, diif against initial state > (same transaction), validate and applies to latest committed state. I like the suggestion in general but some details worth thinking more. > (This proposal does not deal with potential problems with metadata > changes in read committed transactions.) If it will cause serious troubles - well, we can deny DDL in read committed transactions. > It will allow database to go from a good state to a good state without > restrictions, inconsistencies, corruptions and few locks. > > To make this work, we need to have two type of validations, validation > phase 1 (v1, when DDL command is executed), and validation phase 2 (v2, > at commit). > > At v1 we validate things like: > - Cannot DROP a non existent object > - Cannot ALTER a non existent object > - Cannot CREATE an object that already exist Returning to 'allow concurrent transactions to change the same objects'. What if both transactions create same objects or any other phase 1 conflict? First committed wins? > At v2 we validate everything else: > - No disallowed circular dependencies > - State of changed objects are good > - State of objects depending on the changed ones are good > PS. We had more or less same suggestion from Jim >10 years ago (well, no word 'Virtual' was said that time) but it did not go out of generic discussion phaze. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Code style - right margin
On 16/01/2017 14:39, Alex Peshkoff wrote: > On 01/15/17 18:32, Dmitry Yemanov wrote: >> 15.01.2017 17:50, Adriano dos Santos Fernandes wrote: >> >>> What is our maximum code right margin? >>> >>> AFAIK it used to be 100 and I remember some discussion to increase it. >>> >>> Some people is thinking it's infinite. >>> >>> I think currently 100 is too low and 120 would be better. >> It used to be 80 and Claudio had suggested to raise it up to 100 (since >> FB3, IIRC). >> >> Perhaps I could live with 120, but it's pretty close to the limit of my >> personal comfort. Let's see what others think. > 80 was reasonable in the epoch of 14" EGA or even better - blackNgreen > non-graphical ttys ;) > > With today 22-24" 16:9 screens use of small width limits cause only one > effect - most of that screen remains empty. Even with my eyes requiring > rather large font to work comfortably I have 145 symbols in width in > favorite text editor. I.e. I would say - 120-140, and if Dmitry prefers > 120 let it be so. > 120 is good for me too, it almost fit side by side sources with not large font when reviewing. Adriano PS: finally receiving your emails again -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Code style - right margin
On 01/16/17 19:58, Dmitry Yemanov wrote: > 16.01.2017 19:39, Alex Peshkoff wrote: >> With today 22-24" 16:9 screens > 20" 4:3 is still enough for me ;-) A few years ago I had to replace my old Sun tube cause it stopped to work. I wanted to buy 4:3 monitor but there was nothing available with appropriate matrix (can't work with something worse than IPS/SFT - problem with eyes). I could not find one and had to start working with 16:9 monitor. Well, I've thought that it's only me who preferred old format screens ;) -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Code style - right margin
16.01.2017 19:39, Alex Peshkoff wrote: > > With today 22-24" 16:9 screens 20" 4:3 is still enough for me ;-) Dmitry -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Code style - right margin
On 01/15/17 18:32, Dmitry Yemanov wrote: > 15.01.2017 17:50, Adriano dos Santos Fernandes wrote: > >> What is our maximum code right margin? >> >> AFAIK it used to be 100 and I remember some discussion to increase it. >> >> Some people is thinking it's infinite. >> >> I think currently 100 is too low and 120 would be better. > It used to be 80 and Claudio had suggested to raise it up to 100 (since > FB3, IIRC). > > Perhaps I could live with 120, but it's pretty close to the limit of my > personal comfort. Let's see what others think. 80 was reasonable in the epoch of 14" EGA or even better - blackNgreen non-graphical ttys ;) With today 22-24" 16:9 screens use of small width limits cause only one effect - most of that screen remains empty. Even with my eyes requiring rather large font to work comfortably I have 145 symbols in width in favorite text editor. I.e. I would say - 120-140, and if Dmitry prefers 120 let it be so. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Virtual metadata
15.01.2017 19:00, Adriano dos Santos Fernandes wrote: > So what I call virtual metadata and how would it solve the problems: > > When a DDL command is issued, it will not change metadata directly. It > will change metadata in a memory structure tied to the current transaction. > > It may read metadata from database as needed and change it (in memory > structures). > > At commit time, changed metadata is validated (including validation with > dependencies) and changes are applied to database. In fact, you are suggesting to create a new in-memory DBMS built into every transaction which collects all transaction changes and drop them into the main database on commit. It may work, but it will have all in-memory databases' disadvantages and is a very dramatic change in Firebird architecture. -- WBR, SD. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] rare segfault in fb_shutdown()
On 01/16/17 13:40, Stephan Bergmann wrote: > On 01/15/2017 07:26 PM, Alex Peshkoff wrote: >> On 01/15/17 12:24, Damyan Ivanov wrote: >>> -=| Alex Peshkoff, 13.01.2017 14:32:09 +0300 |=- On 01/03/17 00:38, Damyan Ivanov wrote: > I've been chasing this for some time, and finally I've come (with help > from others) to a environment which makes the segfault relatively easy > to reproduce, although it still requires patience. > > I browsed the commits in the B3_0_Release branch, but none seemed to > touch any > code that seems relevant to me. Not strange that you've missed that commit - races when thread is closing are present since interbase times, but presence of provider architecture in FB3 made them more often visible. Should be fixed, see http://tracker.firebirdsql.org/browse/CORE-5452 >>> Thank you, Alex. >>> >>> I have added the patch to the Debian package and the specially-crafted >>> single-core environment seems to no longer expose the crash. >>> >>> >> Wow, that's great that it's successfully tested it in initial >> environment. Artificial tricks I've used to reproduce on local box do >> not always give correct result. > Is there a patch that I could apply to our build of Firebird within > LibreOffice? I didn't find any from the CORE-5452 link above. Please use this one: https://github.com/FirebirdSQL/firebird/commit/d88c5ac3cbce2420e4cf38dd9b9dfdf756408840 It slightly differs from final edition but absolutely OK for tests. -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] rare segfault in fb_shutdown()
16.01.2017 15:49, Stephan Bergmann wrote: > On 01/16/2017 02:18 PM, liviuslivius wrote: >> http://www.firebirdsql.org/en/snapshot-builds/ >> or >> you can build it from code >> https://github.com/FirebirdSQL/firebird/commits/B3_0_Release > > Ah, I was looking/hoping for a reasonably small and self contained > source code patch that I could apply to LibreOffice's copy of the > firebird-3.0.0 sources for now, without having to bump that copy as a > whole to anything more recent (let alone a snapshot). Is it what you are looking for ? master https://github.com/FirebirdSQL/firebird/commit/d88c5ac3cbce2420e4cf38dd9b9dfdf756408840 B3_0_Release https://github.com/FirebirdSQL/firebird/commit/40f782ae3e918c4f3842571ff8064be1c4f54961 Regards, Vlad PS Don't overquote, please -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] rare segfault in fb_shutdown()
here it is https://github.com/FirebirdSQL/firebird/commit/40f782ae3e918c4f3842571ff8064be1c4f54961 same in debian git https://anonscm.debian.org/cgit/pkg-firebird/3.0.git/commit/?id=84021ce684210475ec44f6c3e7a8fc04c612b5a0 On Mon, Jan 16, 2017 at 3:49 PM, Stephan Bergmann wrote: > On 01/16/2017 02:18 PM, liviuslivius wrote: > > http://www.firebirdsql.org/en/snapshot-builds/ > > or > > you can build it from code > > https://github.com/FirebirdSQL/firebird/commits/B3_0_Release > > Ah, I was looking/hoping for a reasonably small and self contained > source code patch that I could apply to LibreOffice's copy of the > firebird-3.0.0 sources for now, without having to bump that copy as a > whole to anything more recent (let alone a snapshot). > > > W dniu 2017-01-16 11:40:23 użytkownik Stephan Bergmann < > sberg...@redhat.com> napisał: > >> On 01/15/2017 07:26 PM, Alex Peshkoff wrote: > >>> On 01/15/17 12:24, Damyan Ivanov wrote: > -=| Alex Peshkoff, 13.01.2017 14:32:09 +0300 |=- > > On 01/03/17 00:38, Damyan Ivanov wrote: > >> I've been chasing this for some time, and finally I've come (with > help > >> from others) to a environment which makes the segfault relatively > easy > >> to reproduce, although it still requires patience. > >> > > > >> I browsed the commits in the B3_0_Release branch, but none seemed > to touch any > >> code that seems relevant to me. > > Not strange that you've missed that commit - races when thread is > > closing are present since interbase times, but presence of provider > > architecture in FB3 made them more often visible. > > > > Should be fixed, see http://tracker.firebirdsql.org/browse/CORE-5452 > Thank you, Alex. > > I have added the patch to the Debian package and the specially-crafted > single-core environment seems to no longer expose the crash. > > > >>> > >>> Wow, that's great that it's successfully tested it in initial > >>> environment. Artificial tricks I've used to reproduce on local box do > >>> not always give correct result. > >> > >> Is there a patch that I could apply to our build of Firebird within > >> LibreOffice? I didn't find any from the CORE-5452 link above. > > > -- > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphiFirebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5454) INSERT into updatable view without explicit field list failed
INSERT into updatable view without explicit field list failed - Key: CORE-5454 URL: http://tracker.firebirdsql.org/browse/CORE-5454 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0.1, 2.5.6, 3.0.0 Reporter: Roman Simakov CREATE DATABASE 'upd_view.fdb' PAGE_SIZE 16384; CREATE TABLE DOC1 (ID INTEGER NOT NULL, NAME VARCHAR(1024), DATA VARCHAR(1024), PRIMARY KEY (ID)); CREATE TABLE DOC2 (ID INTEGER NOT NULL, NAME VARCHAR(1024), DATA VARCHAR(1024), PRIMARY KEY (ID)); CREATE VIEW V (ID, NAME, DATA) AS SELECT * FROM DOC1 UNION ALL SELECT * FROM DOC2; SET TERM ^; CREATE TRIGGER V_INS FOR V BEFORE INSERT AS DECLARE VARIABLE I INTEGER; BEGIN I = MOD(NEW.ID, 2); if (I = 0) THEN INSERT INTO DOC1 VALUES (NEW.ID, NEW.NAME, NEW.DATA); else if (I = 1) THEN INSERT INTO DOC2 VALUES (NEW.ID, NEW.NAME, NEW.DATA); END^ SET TERM ;^ COMMIT WORK; INSERT INTO V (ID, NAME, DATA) VALUES (0, '0', '0'); INSERT INTO DOC1 VALUES (1, '1', '1'); INSERT INTO V VALUES (2, '2', '2'); -- << failed -- 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 -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] rare segfault in fb_shutdown()
On 01/16/2017 02:18 PM, liviuslivius wrote: > http://www.firebirdsql.org/en/snapshot-builds/ > or > you can build it from code > https://github.com/FirebirdSQL/firebird/commits/B3_0_Release Ah, I was looking/hoping for a reasonably small and self contained source code patch that I could apply to LibreOffice's copy of the firebird-3.0.0 sources for now, without having to bump that copy as a whole to anything more recent (let alone a snapshot). > W dniu 2017-01-16 11:40:23 użytkownik Stephan Bergmann > napisał: >> On 01/15/2017 07:26 PM, Alex Peshkoff wrote: >>> On 01/15/17 12:24, Damyan Ivanov wrote: -=| Alex Peshkoff, 13.01.2017 14:32:09 +0300 |=- > On 01/03/17 00:38, Damyan Ivanov wrote: >> I've been chasing this for some time, and finally I've come (with help >> from others) to a environment which makes the segfault relatively easy >> to reproduce, although it still requires patience. >> > >> I browsed the commits in the B3_0_Release branch, but none seemed to >> touch any >> code that seems relevant to me. > Not strange that you've missed that commit - races when thread is > closing are present since interbase times, but presence of provider > architecture in FB3 made them more often visible. > > Should be fixed, see http://tracker.firebirdsql.org/browse/CORE-5452 Thank you, Alex. I have added the patch to the Debian package and the specially-crafted single-core environment seems to no longer expose the crash. >>> >>> Wow, that's great that it's successfully tested it in initial >>> environment. Artificial tricks I've used to reproduce on local box do >>> not always give correct result. >> >> Is there a patch that I could apply to our build of Firebird within >> LibreOffice? I didn't find any from the CORE-5452 link above. -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] rare segfault in fb_shutdown()
Hi, http://www.firebirdsql.org/en/snapshot-builds/ or you can build it from code https://github.com/FirebirdSQL/firebird/commits/B3_0_Release regards, Karol Bieniaszewski W dniu 2017-01-16 11:40:23 użytkownik Stephan Bergmann napisał: > On 01/15/2017 07:26 PM, Alex Peshkoff wrote: > > On 01/15/17 12:24, Damyan Ivanov wrote: > >> -=| Alex Peshkoff, 13.01.2017 14:32:09 +0300 |=- > >>> On 01/03/17 00:38, Damyan Ivanov wrote: > I've been chasing this for some time, and finally I've come (with help > from others) to a environment which makes the segfault relatively easy > to reproduce, although it still requires patience. > > >>> > I browsed the commits in the B3_0_Release branch, but none seemed to > touch any > code that seems relevant to me. > >>> Not strange that you've missed that commit - races when thread is > >>> closing are present since interbase times, but presence of provider > >>> architecture in FB3 made them more often visible. > >>> > >>> Should be fixed, see http://tracker.firebirdsql.org/browse/CORE-5452 > >> Thank you, Alex. > >> > >> I have added the patch to the Debian package and the specially-crafted > >> single-core environment seems to no longer expose the crash. > >> > >> > > > > Wow, that's great that it's successfully tested it in initial > > environment. Artificial tricks I've used to reproduce on local box do > > not always give correct result. > > Is there a patch that I could apply to our build of Firebird within > LibreOffice? I didn't find any from the CORE-5452 link above. > > > -- > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] rare segfault in fb_shutdown()
On 01/15/2017 07:26 PM, Alex Peshkoff wrote: > On 01/15/17 12:24, Damyan Ivanov wrote: >> -=| Alex Peshkoff, 13.01.2017 14:32:09 +0300 |=- >>> On 01/03/17 00:38, Damyan Ivanov wrote: I've been chasing this for some time, and finally I've come (with help from others) to a environment which makes the segfault relatively easy to reproduce, although it still requires patience. >>> I browsed the commits in the B3_0_Release branch, but none seemed to touch any code that seems relevant to me. >>> Not strange that you've missed that commit - races when thread is >>> closing are present since interbase times, but presence of provider >>> architecture in FB3 made them more often visible. >>> >>> Should be fixed, see http://tracker.firebirdsql.org/browse/CORE-5452 >> Thank you, Alex. >> >> I have added the patch to the Debian package and the specially-crafted >> single-core environment seems to no longer expose the crash. >> >> > > Wow, that's great that it's successfully tested it in initial > environment. Artificial tricks I've used to reproduce on local box do > not always give correct result. Is there a patch that I could apply to our build of Firebird within LibreOffice? I didn't find any from the CORE-5452 link above. -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
