Re: [Firebird-devel] Restoring DB into shutdown state

23.03.2016 10:28, Jiří Činčura wrote: > I can't even backup database in shutdown mode. There is few shutdown mode's. Default one is "multi-user maintenance" and it not prevents backup. If you need something non-default - specify it explicitly. Regards, Vlad

[Firebird-devel] Atomics

All, in new codebase (v4) we going to use atomic operations more intensively than before. The question is: could we use standard features of C++11 or should choose some 3rd party library (such as libatomic_ops) for it ? The main concern about C++11 atomics is - if all platforms where

Re: [Firebird-devel] Firebird 3 - Single CPU core fully utilized with Trace session

21.04.2016 13:35, Thomas Steinmaurer wrote: ... >>As you already found that fbtracemgr is OK, i guess something is not fully >> correct (or stepped on some another issue) at FB Trace Manager. Could you >> show >> how do you work with trace service ? > > The usage of the trace services in FBTM

Re: [Firebird-devel] Performance of fbclient.dll of recent snapshots

26.04.2016 14:12, Michal Kubecek wrote: > On Tue, Apr 26, 2016 at 12:05:44PM +0200, Dimitry Sibiryakov wrote: >> 26.04.2016 12:01, Stefan Heymann wrote: >>> So I think Michael's idea to expand the URL type database strings is a >>> good idea: >> >> No, it is just a workaround. >> Good solution

Re: [Firebird-devel] Performance of fbclient.dll of recent snapshots

28.04.2016 18:48, Stefan Heymann wrote: >> Sean, can you confirm that there is no delay when using 3.0 fbclient >> with remote 2.5 server? > > I can confirm that: using a 3.0 fbclient to connect to a *remote* 2.5 > server is quick. The problem seems to be related to the local machine > (I didn't

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5240) Restore database with large page buffer - connection lost to database

19.05.2016 1:05, Walter R. Ojeda Valiente wrote: > As I understand, the page buffers rank is 50 to 131072 This restriction is applied for 32-bit builds only. Vlad PS Never, NEVER put whole message at the bottom of your answer !!!

Re: [Firebird-devel] Firebird 3 - Single CPU core fully utilized with Trace session

20.04.2016 0:47, Thomas Steinmaurer wrote: ... > What else could I provide so that you can investigate the offending > thread? Full memory dump, please. Regards, Vlad -- Find and fix application performance issues

Re: [Firebird-devel] Firebird 3 - Single CPU core fully utilized with Trace session

21.04.2016 12:00, Thomas Steinmaurer wrote: >> Have you had time to look at it? Looking now, but seems you already on the way ;) >> Unfortunately this now also has happened in a production environment at >> a customer site. >> >> We did quite some testing in the trace area at Firebird 3

Re: [Firebird-devel] Double deallocation in btr.cpp:falst_load()

10.08.2016 3:35, Adriano dos Santos Fernandes wrote: > Em 09/08/2016 12:46, Dimitry Sibiryakov escreveu: >> Hello, All. >> >> With applied patch f532dda9d8207e0d8cfdcd55eb916121fefedcb4, debug build >> of current >> master fails on Win64 with following call stack. >> > > This in

[Firebird-devel] [SPAM] Re: Intl library compatibility

20.07.2016 17:43, Dimitry Sibiryakov wrote: > 20.07.2016 16:35, Alex Peshkoff wrote: >> Does it have any practical meaning? > >If I load Firebird 3 library in embedded mode and Firebird 2.5 Embedded > engine into the > same process space, I'd prefer them not to fight with each other for intl

Re: [Firebird-devel] fbembed.lib

20.07.2016 18:39, Dimitry Sibiryakov wrote: >Hello, All. > >Where can I get import library for embedded engine for MSVC? Is building > from sources > the only option to get it? Seems so >I wonder why it isn't included into package... Nobody ask for it Regards, Vlad

Re: [Firebird-devel] Intl library compatibility

20.07.2016 18:56, Dimitry Sibiryakov wrote: > 20.07.2016 17:51, Vlad Khorsun wrote: >>Looks like bad idea: ODS 11.x used ICU 3 (for index keys on strings with >> multibyte encoding) >> while ODS 12 used ICU 5.2. If both embedded engines will use same fbintl - >>

Re: [Firebird-devel] Unloading plugin

09.07.2016 13:36, Jiří Činčura wrote: > Hi *, > > can I force Firebird to unload an external engine plugin? No > Or when it happens automatically? 1 min after release of last reference Regards, Vlad -- Attend

[Firebird-devel] RFC: Timeouts

Hi All, There are user requests to implement statement, transaction and attachment timeouts: http://tracker.firebirdsql.org/browse/CORE-658 http://tracker.firebirdsql.org/browse/CORE-985 http://tracker.firebirdsql.org/browse/CORE-4238 More - it was decided by TTG to implement this

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 16:41, Dimitry Sibiryakov пишет: > 18.08.2016 15:33, Vlad Khorsun wrote: >>Do you intentionally mixed timeouts set by DBA and by app developer or >> you really not >> understand what is for what ? > >Yes, I don't understand. > >>Global

Re: [Firebird-devel] RFC: Timeouts

16.02.2017 12:59, Vlad Khorsun wrote: > > Hi All, > >The code is committed at separate branch: > > https://github.com/FirebirdSQL/firebird/tree/timeouts > > Documentation is there: > > > https://github.com/FirebirdSQL/firebird/blob/timeo

[Firebird-devel] [SPAM] Re: RFC: Timeouts

19.02.2017 5:21, Leyne, Sean wrote: > > >>> If I read the documentation correctly, a statement which performed >>> (say) a SELECT against a table that >> > follows a NATURAL scan, which is 'paused' awaiting the next Fetch, would >> run into the timeout, even > though there is no "cost" to the

Re: [Firebird-devel] RFC: Timeouts

25.02.2017 2:55, Leyne, Sean wrote: > Vlad, > > These connections perform only a few heavy weight SQL statements (taking max 3-4 of real execution time). > Most of the time is spent in the Firebird engine waiting for the next fetch, due to network latencies. In the

Re: [Firebird-devel] RFC: Timeouts

25.02.2017 11:47, Mark Rotteveel wrote: > On 25-2-2017 09:31, Vlad Khorsun wrote: >>If think a bit deeper, it will be clear that there is no other way as >> send big result sets >> in parts over the wire. Also, why don't you ask if they fully fetch >> r

Re: [Firebird-devel] RFC: Timeouts

24.02.2017 20:18, Mark Rotteveel wrote: > I agree, I do think fetch time should be included, but not the time the > engine is waiting for the next fetch. Excuse me but i consider it as terrible wrong and will not participate in it. Regards, Vlad

Re: [Firebird-devel] RFC: Timeouts

24.02.2017 20:14, Mark Rotteveel wrote: ... > It would be nice to know exactly what changes are involved in the wire > protocol for statement-specific timeouts without having to dive into the > implementation. Read, please, "Remote client implementation notes" at both

Re: [Firebird-devel] RFC: Timeouts

25.02.2017 21:15, Jiří Činčura wrote: >> But, client side already can set it own timer and cancel the statement. > > To add to what others said. Isn't this feature, also, about helping i.e. > DBA to keep bad queries slowing down the server (considering (s)he has > no control over the application's

Re: [Firebird-devel] Firebird 3 on MacOS not working as an embedded server

23.02.2017 19:33, Mark De Wit wrote: > Yes, the default firebird.conf (as produced by the build) is in the bin > folder together with fbclient library. > I have not changed any settings, however (so all settings are commented out) "plugins" folder is inside that "bin" folder, correct ? > I

Re: [Firebird-devel] RFC: Timeouts

23.02.2017 19:02, Leyne, Sean wrote: ... > Unfortunately, I doubt that the feature as implemented has any benefits for > our applications. > > We have a number of our clients that access our databases via ODBC/JDBC > connections to perform data extract. > > These connections perform only a few

Re: [Firebird-devel] RFC: Timeouts

Hi All, The code is committed at separate branch: https://github.com/FirebirdSQL/firebird/tree/timeouts Documentation is there: https://github.com/FirebirdSQL/firebird/blob/timeouts/doc/README.statement_timeouts

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

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 0:58, Adriano dos Santos Fernandes wrote: > Em 17/08/2016 15:44, Vlad Khorsun escreveu: > >> >> a) Statement execution timeout >> - timeout is set in milliseconds, there is no guarantee of exact precision >>(especially under high load). Th

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5493) Add context variable about transaction start timestamp

01.03.2017 9:33, Karol Bieniaszewski (JIRA) wrote: > Add context variable about transaction start timestamp > -- > > Key: CORE-5493 > URL: http://tracker.firebirdsql.org/browse/CORE-5493 > Project:

Re: [Firebird-devel] RFC: Timeouts

25.02.2017 21:40, Jiří Činčura wrote: > OK, after reading the thread again and again, I think I'm starting to > understand what was Vlad shooting for. And I think his implementation > makes sense (so I'm fine moving it forward). This also makes sense > reading some of Vlad's scenarios in docs

Re: [Firebird-devel] Problem cch / nbak

31.08.2016 22:26, Adriano dos Santos Fernandes wrote: > TCS test ISC_ER43_TRAN is causing this error in cch.cpp:1563: > > fb_assert(bdb->bdb_flags & BDB_nbak_state_lock); Assertions should be fixed now. Thanks, Vlad

Re: [Firebird-devel] Foreign key error even there should not be one (maybe, Weird problem in one database)

19.09.2016 14:06, Tommi Prami wrote: > Weird part was that I actually pumped the data to the empty database and it > behaved the same. > > This is more than less puzzling. > > And the Backup and restore did not help,. which also, I think, should > recreate the indexes and so on... Without

[Firebird-devel] [SPAM] Re: RFC: Timeouts

17.08.2016 22:07, Dimitry Sibiryakov wrote: > 17.08.2016 20:44, Vlad Khorsun wrote: >>- can't be greater than (non-zero) value at config > >I.e there is no way for DBA to make exceptions for some queries that are > known to be > good, but long, right? Right.

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 10:37, liviuslivius wrote: > > > W dniu 2016-08-18 09:26:22 użytkownik Vlad Khorsun <hv...@optima.com.ua> > napisał: >> 18.08.2016 10:08, liviuslivius пишет: >>> Hi Vlad, >>> >>>>> I.e interactive Delphi application that fetch o

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 10:08, liviuslivius пишет: > Hi Vlad, > >>> I.e interactive Delphi application that fetch only really shown records >>> will get error >>> when user press "Down" key, >> >> If user fetch one record per hour - yes, such application should be >> better rewritten > > Is this query in

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 13:04, liviuslivius wrote: > If i can start general discussion.. > > do you really use such feature in real systems? > I saw this in MSSQL environment and what was advice of DBA when someone reach > timeout? > Increase timeout settings... IIRC, default query timeout in MSSQL is 30

[Firebird-devel] [SPAM] Re: RFC: Timeouts

18.08.2016 18:08, Dimitry Sibiryakov wrote: > 18.08.2016 16:55, Vlad Khorsun wrote: >>Global timeout is a last line of defense for DBA against bad apps, wrong >> queries, >> developer mistakes, unlucky days (dropped some indices last week but now >> some q

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 18:59, Adriano dos Santos Fernandes wrote: > On 18/08/2016 11:55, Vlad Khorsun wrote: >>Global timeout is a last line of defense for DBA against bad apps, wrong >> queries, >> developer mistakes, unlucky days (dropped some indices last week but now >>

Re: [Firebird-devel] Stuck transaction in 2.5.6

26.09.2016 13:02, Jiří Činčura wrote: > Hi *, > > I've had quite a few occurrences of transaction being stuck on Firebird > 2.5.6 in last 7 days. Even trying to close the connection from > monitoring tables was not working. I had to kill the process. > > I was able to take a dump (actually 2, from

Re: [Firebird-devel] (CORE-4563): Add support for Windows 8/2012 fast/low-latency "TCP Loopback Fast Path" functionality

11.11.2016 11:06, Karsten Strobel wrote: > Hi Firebird Developers! > > > > I access Firebird frequently from Windows services running on the same > machine. I have a huge number of accesses each with small > impact, many updates and inserts rather than selects. Roundtrip time is very > critical.

Re: [Firebird-devel] Firebird 3.0.1 - SuperServer - Scalability

14.11.2016 16:09, Thomas Steinmaurer wrote: > Hello Simon, > >> Thomas Steinmaurer wrote Mon, 14 Nov 2016 15:03:41 >> +0300: >> >>> Hello, >>> >>> using Firebird-3.0.1.32609-0_x64_pdb.zip SuperServer on Windows 10 Prof. >>> with 16G RAM, spinning disk (7200K) and Xeon 1230

Re: [Firebird-devel] Fwd: [Firebird-checkins] [FirebirdSQL/firebird] 5aede1: Decimal floating point numbers - first draft

11.11.2016 17:20, Alex Peshkoff wrote: > Decimal floating point numbers - first draft Great ! > This is according to FB4 roadmap - enhancement of precision of > calculations in firebird. > You can read about decfloat datatype here: >

Re: [Firebird-devel] [FirebirdSQL/firebird] 5aede1: Decimal floating point numbers - first draft

13.11.2016 17:06, Dmitry Yemanov wrote: > 11.11.2016 18:26, Dimitry Sibiryakov wrote: > >>> - Added new datatypes: DECFLOAT(16) and DECFLOAT(34), using 64/128 bits >>> for numbers representation. >> >> What is the point of these new types? Cannot you just expand list of >> back-end storage >> for

Re: [Firebird-devel] Firebird 3.0.1 - SuperServer - Scalability

14.11.2016 20:27, Thomas Steinmaurer wrote: ... > So, with 16G RAM and an OLTP emul database with ~ 2,9G, it is still > recommended with Firebird 3 SS and the shared page cache, to rather use > a smaller number, lets say 50K and keep the FileSystemCacheThreshold at > 64K to have the file system

Re: [Firebird-devel] Firebird 3.0.1 - SuperServer - Scalability

14.11.2016 21:00, Thomas Steinmaurer wrote: > But still, IMHO it does not explain why additional connect request with > SS while running OLTP emul with 100 users are taking considerable time, > although they are almost instant with SC? This is not SS vs SC. This is absence vs presence of

Re: [Firebird-devel] Firebird 3.0.1 - SuperServer - Scalability

14.11.2016 21:26, Thomas Steinmaurer пишет: >> >>> But still, IMHO it does not explain why additional connect request with >>> SS while running OLTP emul with 100 users are taking considerable time, >>> although they are almost instant with SC? >> >>This is not SS vs SC. This is absence vs

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5419) Index garbage collection on varchar column causes server to hang

11.01.2017 16:01, Alex Peshkoff wrote: > On 01/11/17 16:19, Vlad Khorsun wrote: >> 11.01.2017 15:09, Alex Peshkoff wrote: >>> >>>>> Could you try fb2.5 (as i did) ? >>>> Will do. >>>> >>> On 2.5 I see approx 50% slowdown when GC i

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5419) Index garbage collection on varchar column causes server to hang

12.01.2017 10:24, Alex Peshkoff wrote: > On 01/11/17 23:35, Vlad Khorsun wrote: > >>>> I do it easily. AST thread is blocked at >>>> Database::Sync::lock on syncMutex.enter() despite of a lot of checkouts in >>>> worker >>>> thread. >&g

Re: [Firebird-devel] op_exit/op_disconnect in aux connection

12.01.2017 12:25, Jiří Činčura пишет: > Hi *, > > I'm looking at > https://github.com/FirebirdSQL/firebird/blob/master/src/remote/client/interface.cpp#L6007 > and wondering whether the server can ever send op_exit/op_disconnect on > aux connection? Is that possible? And I can somehow do it (for

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5419) Index garbage collection on varchar column causes server to hang

12.01.2017 12:10, Alex Peshkoff wrote: > On 01/12/17 13:00, Vlad Khorsun wrote: >> 12.01.2017 10:24, Alex Peshkoff wrote: >>> On 01/11/17 23:35, Vlad Khorsun wrote: >>> >>>>>> I do it easily. AST thread is blocked at >>>>>> Database

Re: [Firebird-devel] Windows build of Firebird 3 is broken

15.01.2017 11:53, Mark Rotteveel wrote: > The windows build of Firebird 3 is broken (note: I haven't checked the > Firebird 4 build, might have the same problem). > > It fails when building gpre_boot, this failure is introduced in: > > commit 40f782ae3e918c4f3842571ff8064be1c4f54961 > Author:

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5419) Index garbage collection on varchar column causes server to hang

Hi all, I tried it on Windows and here is my observations: - SuperServer have no problem - for Classic and SuperClassic problem is confirmed of course, operations with another DB's are not affected - the reason is that attachment doing garbage collection doesn't react on AST's: yes, it

Re: [Firebird-devel] Aux connection closed with op_disconnect?

10.01.2017 19:22, Jiří Činčura wrote: > Hi *, > > when I call op_disconnect on main connection (the one from which I got > the aux connection details), the aux connection is closed as well. Is > that how it should be? Yes, of course Regards, Vlad

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5419) Index garbage collection on varchar column causes server to hang

11.01.2017 13:18, Alex Peshkoff wrote: > Vlad, I can not reproduce initial issue in master branch on linux. > GC does not affect ability to connect to database and execute simple > queries. Does you tried classic ? Could you try fb2.5 (as i did) ? Regards, Vlad

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5419) Index garbage collection on varchar column causes server to hang

11.01.2017 15:09, Alex Peshkoff wrote: > > >>> Could you try fb2.5 (as i did) ? >> Will do. >> > > On 2.5 I see approx 50% slowdown when GC is in progress. Same slowdown > is present when 'delete from test' is executed. Slowdown of what operation ? > Nothing special for GC, but must say that

Re: [Firebird-devel] Cancelling events

10.01.2017 21:29, Jiří Činčura wrote: >>Yes, you should got usual op_response > > I get a response on main connection, not on aux. There should be > something on aux as well? I was not clear. You send op_cancel_events on main conneciton and you get response at the same main connection. If

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5419) Index garbage collection on varchar column causes server to hang

11.01.2017 20:59, Alex Peshkoff wrote: > On 01/11/17 20:36, Vlad Khorsun wrote: ... >>> I.e. slowdown is obviously present but it's too far from being irresponsive. >> Thanks. Sad you can't reproduce it. > > I remember that long ago linux had some problems with pthread_

Re: [Firebird-devel] [B3_0_Release] Can't compile in VS2015.

Fixed Regards, Vlad -- 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

Re: [Firebird-devel] Wire protocol changes in Firebird 4?

19.12.2016 19:51, Mark Rotteveel wrote: > Are there any wire protocol changes in Firebird 4 (or planned for > Firebird 4). And if so, where can I find information on those changes? I could remember the only small change, bug fix for CORE-5296 by Alex (commit

Re: [Firebird-devel] x64 fblient.dll ISC_STATUS data type vs. lib version

23.03.2017 22:47, malloc meyer wrote: > > > Dear, > > I am developing with IBPP on x64 linux and windows hosts. Using IBPP on a x64 > windows LLP64 system leads to exceptions. > The reason is a wrong definition of ISC_STATUS in the IBPP headers. IBPP > defines ISC_STATUS for a LLP64 windows

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 7:53, Vlad Khorsun wrote: > 24.03.2017 1:29, Mark Rotteveel wrote: ... >> The column was created with a default, which means that existing rows will >> get that value, > >Engine doesn't assing values to a new field, i.e. there is no implicit > UPDATE o

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 1:29, Mark Rotteveel wrote: > To me the behavior described under "actual" intuitively sounds like the > correct behavior. Why do you expect that the column value > would change to 'ABC'? Because Firebird doesn't update old records when new field was created. > The column was

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 10:50, Svein Erling Tysvær wrote: > Being still on Fb 2.5, my voice is rather error-prone, but I'm definitely > outside the development team. Being long-time Firebird user your voice is very important for us > It would confuse me if things worked like Vlad expects. Suppose the

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 12:28, Dimitry Sibiryakov wrote: > 24.03.2017 10:29, Vlad Khorsun wrote: >>Not sure i understand what you mean but sweep never updates records. > >My knowledge of Firebird is overestimated, you know. Isn't there an > internal routine > that converts re

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 15:58, Adriano dos Santos Fernandes пишет: > Em 23/03/2017 20:29, Mark Rotteveel escreveu: > >> >> actual >> >> ID DESCRF1 >> >>1 No F1 field XYZ >>

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 17:57, Alex Peshkoff wrote: > On 03/24/17 17:53, Vlad Khorsun wrote: > >> So far we have no agreement on what is "correct result". Current >> implementation >> changed well known old behaviour not claiming it as a bug. I'd say it looks >>

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 17:12, Adriano dos Santos Fernandes wrote: ... > Looks like you do not understand how it works. Re-read thread "Adding > NOT NULL fields with DEFAULT" from 2009. That thread contains more details, thanks for recall it. >>> Correct result is priority, and current implementation

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 19:39, Alex Peshkoff wrote: > On 03/24/17 20:26, Vlad Khorsun wrote: >> 24.03.2017 17:57, Alex Peshkoff wrote: >>> On 03/24/17 17:53, Vlad Khorsun wrote: >>> >>>> So far we have no agreement on what is "correct result". Current

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 17:08, Adriano dos Santos Fernandes wrote: > Em 24/03/2017 11:58, Vlad Khorsun escreveu: >>> Well, actually seems we do not known why you started this topic mixing >>> implementation details with users behaviour. >> >>Because you left blr filter

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 14:02, Ann Harrison wrote: > It's been a long time, but I think that's an ancient behavior that Jim and I > argued about many years ago. > Maybe even in Rdb$ELN, InterBase's ancestor. > > Unless my memory fails me (again) the internal format rectifier doesn't go > through all

Re: [Firebird-devel] Event Parameter buffer (EPB)

27.03.2017 12:12, Paul Reeves wrote: > > The EPB is clearly documented as being limited to 15 events. I did a > fairly rough grep of the code and I failed to find where this > limitation is enforced. And I couldn't find anything in the release > notes to indicate that anything has changed since

Re: [Firebird-devel] blr_varying2 format

28.03.2017 16:57, Dimitry Sibiryakov wrote: >Hello, All. > >For blr_varying2 correct BLR format is <2 bytes charset><2 > bytes length> > and the length is expected to be _without_ additional 2 bytes, right? Right Vlad

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

25.03.2017 0:16, Lester Caine wrote: > On 24/03/17 21:42, Vlad Khorsun wrote: >> 24.03.2017 21:36, Lester Caine wrote: >>> On 24/03/17 17:57, Vlad Khorsun wrote: >>>>> What must be done is specified exactly. And we should suppose that in >>>>>

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 21:36, Lester Caine wrote: > On 24/03/17 17:57, Vlad Khorsun wrote: >>> What must be done is specified exactly. And we should suppose that in >>> all other aspects data stored in database should not be changed - >>What data is *stored* ? > > For a

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 16:03, Adriano dos Santos Fernandes wrote: > Em 24/03/2017 03:33, Vlad Khorsun escreveu: > >> >>Another example - i add not null column with wrong default value and >> going to correct this wrong default value. Should i update whole table >> to

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 16:31, Adriano dos Santos Fernandes wrote: > Or better, increase the record format count, which seems as a stupid limit. It is really better. Are you have smart idea ? > From another side, storing the default value inside the format is a > smart hack that allows to avoid

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 16:37, Adriano dos Santos Fernandes wrote: > Em 24/03/2017 11:15, Vlad Khorsun escreveu: >> 24.03.2017 15:58, Adriano dos Santos Fernandes пишет: >>> Em 23/03/2017 20:29, Mark Rotteveel escreveu: >>> >>>> >>>> actual >>

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5507) Wrong value of the new field at the old records, created before that new field was added.

24.03.2017 16:34, Adriano dos Santos Fernandes wrote: > Em 24/03/2017 06:44, Vlad Khorsun escreveu: > >> >>I prefer to see it works this way. Probably read-committed tx could >> return new default value. >> > > Not only it is in no way intuitive, i

[Firebird-devel] [SPAM] Re: NBAK simplification RFC

20.03.2017 17:49, Nikolay Samofatov wrote: > Hello, All! > > It appears I now have some time to look into old issues. > > I know for a long time that it is possible to optimize NBAK module: > Currently, difference file page is allocated inside CCH_mark and this is > sub-optimal. > > This has not

Re: [Firebird-devel] 3.0.2 "leaking" memory while 2.5.7 is fine

05.04.2017 9:56, Jiří Činčura wrote: >>Could you, please, test today's snapshot build of fb4 ? It contains >> fix for CORE-5416 which looks exactly as you describe above. Or wait >> for tomorrow's snapshot build of fb3 (i plan to backport the fix today). > > Works fine with FB3 snapshot build.

Re: [Firebird-devel] Concurrency bugs in posting events?

09.04.2017 13:00, Mark Rotteveel wrote: > On 2-4-2017 15:23, Vlad Khorsun wrote: >> 02.04.2017 14:59, Mark Rotteveel wrote: ... >>> Any thoughts or ideas on this, or is it better if I just create a bug >>> report? >> >> Ideally, reproducible test case n

Re: [Firebird-devel] 3.0.2 "leaking" memory while 2.5.7 is fine

04.04.2017 11:39, Jiří Činčura wrote: > Hi *, > > I have a pretty simple code that only creates a transaction, executes > statement, commits and releases the transaction and releases the > statement. All in a loop. On Firebird 2.5.7 x64 the memory consumption > of Firebird is rock steady. On 3.0.2

Re: [Firebird-devel] Concurrency bugs in posting events?

02.04.2017 14:59, Mark Rotteveel wrote: > To come back to this again, there seems to be a concurrency bug in > events posted by Firebird to the client. It looks like it overwrites > local event ids (shared buffer, race condition?). > > This is triggered by running the entire Jaybird test suite.

[Firebird-devel] [SPAM] Re: Concurrency bugs in posting events?

02.04.2017 18:07, Mark Rotteveel wrote: > On 2-4-2017 16:48, Vlad Khorsun wrote: ... >>So, we have following packets exchange >> >> 1. op_que_event TEST_EVENT_A, cnt = 0xF5 (245), id = 0xD4 (212) >> 2. op_event TEST_EVENT_B, cnt = 0x7C (124), id = 0xD3 (211) >

Re: [Firebird-devel] Concurrency bugs in posting events?

02.04.2017 17:15, Mark Rotteveel wrote: > On 2-4-2017 15:23, Vlad Khorsun wrote: >>Ideally, reproducible test case needed. As simple, as possible. Also, we >> could log every packet related to events on server side. >> >>> Other example: both A and B are a

Re: [Firebird-devel] Concurrency bugs in posting events?

09.04.2017 22:33, Adriano dos Santos Fernandes wrote: > Vlad, > > I think have found the problem in server. > > Look at this: > > > ISC_STATUS rem_port::que_events(P_EVENT * stuff, PACKET* sendL) > { > ... > > Rvnt* event; > for (event = rdb->rdb_events; event; event =

Re: [Firebird-devel] Concurrency bugs in posting events?

11.04.2017 2:33, Adriano dos Santos Fernandes wrote: > Here is a better description of the problem and a possible fix that Vlad > can use and discard, as he surely better understand this part. > > Sorry for some imprecision in my previous description. > > Jaybird synchronized the op_queue_events

Re: [Firebird-devel] Concurrency bugs in posting events?

11.04.2017 12:27, Mark Rotteveel wrote: > On 2017-04-11 09:15, Vlad Khorsun wrote: >> PS Mark, snapshot build of v4 contains a fix and could be tested > > Thanks, > > I will try to test it tonight if I have time, otherwise tomorrow > evening. Is this something that

Re: [Firebird-devel] Parallel execution

20.04.2017 17:50, Dimitry Sibiryakov wrote: > 20.04.2017 16:20, Vlad Khorsun wrote: >>> even in the simplest cases like "select f from t1 union select f from t2"? >> This case nor simplest nor better for parallel execution than "ordinary" >> "

[Firebird-devel] [SPAM] Re: Start transaction from base transaction

20.04.2017 10:12, Molnár Attila wrote: > +1 for this feature. I would be very happy for this. Also it would be > awesmone if this consistent view were accessible later in time (this > woudl mean garbage collection blocking). Blocking of GC is the easiest part of this task. One need also to

[Firebird-devel] [SPAM] Re: Start transaction from base transaction

19.04.2017 16:35, Dimitry Sibiryakov wrote: > 19.04.2017 14:12, Vlad Khorsun wrote: >> It give nothig to readers > > Not quite so. When array binding used with select, client can send > request for new > packet before it start tossing record values into user buffers

Re: [Firebird-devel] Concurrency bugs in posting events?

12.04.2017 23:00, Mark Rotteveel wrote: > On 11-4-2017 12:25, Vlad Khorsun wrote: >> 11.04.2017 12:27, Mark Rotteveel wrote: >>> On 2017-04-11 09:15, Vlad Khorsun wrote: >> >>>> PS Mark, snapshot build of v4 contains a fix and could be tested >>> >

[Firebird-devel] [SPAM] Re: Start transaction from base transaction

20.04.2017 9:36, Jiří Činčura wrote: >> Could you explain, please ? > > Sure. There's a part of our system that reads data and sends these over > the internet. Given the deployments on the customer side the internet is > often very very slow (<100kBps sometimes), so we decided to not keep >

Re: [Firebird-devel] Start transaction from base transaction

19.04.2017 17:12, Dimitry Sibiryakov wrote: > 19.04.2017 15:56, Vlad Khorsun wrote: >> And it does it already for a many years when fetching records in a batch >> (default mode) > > Really? I see in sources that it send op_fetch only when in REM_fetch() > it run

Re: [Firebird-devel] Start transaction from base transaction

19.04.2017 20:43, Jiří Činčura wrote: >> once. If they all are started without any commit between them (which can >> be ensured by a >> number of different ways), they will give you completely the same view of >> data. > > I'm listening. That would make my life lot easier in certain scenarios,

Re: [Firebird-devel] Parallel execution

20.04.2017 13:04, Dimitry Sibiryakov wrote: > 19.04.2017 14:12, Vlad Khorsun wrote: >> Engine can't run more than one statement in attachment at same time. >> This will not be >> changed. > > Does it also mean that Firebird will never be able to execu

Re: [Firebird-devel] Concurrency bugs in posting events?

15.04.2017 11:08, Mark Rotteveel wrote: > On 14-4-2017 09:47, Vlad Khorsun wrote: >> 12.04.2017 23:00, Mark Rotteveel wrote: >>> In other words: fix confirmed :) Thanks! >> >> Thank you for confirmation. Fix is backported into v3. Could you create >&

Re: [Firebird-devel] Start transaction from base transaction

18.04.2017 19:28, Adriano dos Santos Fernandes wrote: > Hi! > > In distributed systems there is a problem to use Firebird and maintains > read consistency. > > Imagine follow situations: > > 1) A server (not database server) receives a request and dispatch it to > others servers for extra

Re: [Firebird-devel] Start transaction from base transaction

18.04.2017 21:21, Adriano dos Santos Fernandes wrote: > On 18/04/2017 15:01, Vlad Khorsun wrote: >> 18.04.2017 20:21, Adriano dos Santos Fernandes wrote: >>> On 18/04/2017 13:43, Vlad Khorsun wrote: >>>> Some time ago there was discussion about shar

Re: [Firebird-devel] Start transaction from base transaction

19.04.2017 13:34, Dimitry Sibiryakov wrote: > 19.04.2017 12:23, Vlad Khorsun wrote: >>> As in Sean's scenario: you pumped data into 5 tables via 5 connections >>> using 5 derived >>> transactions. Now you need atomically commit all these transactions in all

Re: [Firebird-devel] Changing IRoutineMetadata in Plugin::makeProcedure

19.04.2017 13:43, Jiří Činčura wrote: >> Very strange. My test with UDR was with embedded. >> >> Even more strange because external procedures and remote/embedded layer >> has nothing related. > > I tried padding the CHAR with different character than 32 (space) - to > see whether it changes on

<    1   2   3   4   5   6   7   8   9   10   >