Re: [Firebird-devel] A patch to submit

2014-07-05 Thread Dmitry Yemanov
19.05.2014 19:47, Dimitry Sibiryakov wrote: I would like to submit an attached patch. You would do everybody a favor if the patch was cleaned from the useless stuff (commented out code). Dmitry -- Open source

Re: [Firebird-devel] Plugin-specific database-wide configuration parameters

2014-07-03 Thread Dmitry Yemanov
03.07.2014 12:45, Alex Peshkoff wrote: In databases.conf one can use only present in firebird.conf fixed set of parameters. See config.cpp for details. I suppose we have no problems adding replication parameters in it. I don't think *plugin-specific* settings belong to our config. Dmitry

Re: [Firebird-devel] Plugin-specific database-wide configuration parameters

2014-07-03 Thread Dmitry Yemanov
03.07.2014 13:18, Dimitry Sibiryakov wrote: No. Do you have a suggestion? IMHO, databases.conf is an obvious (from end-user POV) and the best place. Or just pass the database name into plugin and allow it to store/parse its own config (database-wide or global) in whatever way the developer

Re: [Firebird-devel] When is unlocked an stored procedure in use

2014-06-30 Thread Dmitry Yemanov
30.06.2014 20:12, Jesus Garcia wrote: I'm experiencing one problem when trying to recompile stored procedures. Once I use one stored procedure from my application (that is not called from triggers and other procedures), the only way to recompile the procedure is to close user session. I

Re: [Firebird-devel] When is unlocked an stored procedure in use

2014-06-30 Thread Dmitry Yemanov
30.06.2014 22:37, Jesus Garcia wrote: But why If nobody is using it and it does not apear in mon$statements the object is in use? Because metadata locks are cached even if not explicitly used (to avoid repeating acquire/release overhead). Dmitry

Re: [Firebird-devel] When is unlocked an stored procedure in use

2014-06-30 Thread Dmitry Yemanov
30.06.2014 23:16, Jesus Garcia wrote: Then locks for triggers are different from locks from procedures, and both are metadata locks. I can alter triggers with nowait but no procedures. Triggers are bound to the cached tables, they're not locked separately. Dmitry

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-28 Thread Dmitry Yemanov
28.06.2014 11:01, Mark Rotteveel wrote: If a cursor is open, and the SQL-transaction in which the cursor was opened makes a significant change to SQL-data At the first glance, this is what we called cursor stability and have fixed in FB3. But in fact it covers other cases as well and I don't

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-28 Thread Dmitry Yemanov
28.06.2014 11:54, Mark Rotteveel wrote: As far as I understood, the cursor stability fix was about changes made by the statement to its own data (eg an UPDATE or DELETE). The fix was about changes made by statements located underneath the cursor (e.g. for select + insert/update/delete inside,

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-28 Thread Dmitry Yemanov
28.06.2014 12:47, Mark Rotteveel wrote: But as a datapoint, PostgreSQL does this: Read Committed is the default isolation level in PostgreSQL. When a transaction uses this isolation level, a SELECT query (without a FOR UPDATE/SHARE clause) sees only data committed before the query began; it

Re: [Firebird-devel] Using contents of status vector

2014-06-28 Thread Dmitry Yemanov
28.06.2014 12:38, Mark Rotteveel wrote: I am working on replacing the protocol implementation, and now I am running into a 'problem' with parsing the status vector (or actually with the result of that parse). Currently I treat each isc_arg_gds and isc_arg_warning as a separate exception

Re: [Firebird-devel] Phantom Transaction ID

2014-06-27 Thread Dmitry Yemanov
27.06.2014 16:52, Jesus Garcia wrote: The phantom TransactionID appears after one commit retaining of one transaction. Commit retaining internally creates a new transaction (with new ID), hence your phantoms. I think we should add the new ID to trace output for commit/rollback retaining.

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-25 Thread Dmitry Yemanov
25.06.2014 11:52, Roman Simakov wrote: present at the opening cursor. IMO it's bad style to open cursor. It may keep open transaction (it's also not good but RO+RC possible) but it should not keep open cursor. I do not understand why to open cursor at all if you are not going to fetch right

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-25 Thread Dmitry Yemanov
25.06.2014 15:28, Alex Peshkoff wrote: The problem with RC+RO consistent transaction blocking GC may be gone if the engine runs the query till the end and store it in temporary buffer. Dmitry, is this (more or less) what is already done to support bidirectional cursors? Yes, but this is

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-24 Thread Dmitry Yemanov
24.06.2014 17:35, Daniel Rail wrote: I don't think it takes out the non-blocking behavior, because the blocking is only performed at the statement level, not the transaction level. So, for a lookup dataset, it would not change a thing, since the query results will always pick up committed

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-24 Thread Dmitry Yemanov
24.06.2014 01:33, Nikolay Samofatov wrote: If this is what people want, it is possible to add new TPB parameter - isc_tpb_inconsistency, and permit it for READ_ONLY + READ COMMITTED transactions only. For as long you don't use returned data for anything important it is somewhat safe.

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-24 Thread Dmitry Yemanov
24.06.2014 22:12, Dmitry Yemanov wrote: (*) AFAIU, there's no other practical benefit in the sensitive mode except the performance. And the GC blockage in RC RO txns. Dmitry -- Open source business process

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Dmitry Yemanov
21.06.2014 01:52, Nikolay Samofatov wrote: I attach patch for this functionality to give you an idea of implementation. It depends on a couple other changes so it doesn't apply to FB2.5 cleanly. The first thing I'm interested in is the performance impact in OLTP tests similar to TPCC (with

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Dmitry Yemanov
23.06.2014 23:15, Leyne, Sean wrote: Actually, without the new behaviour, the engine results are not guaranteed to be correct. But the point is that their correctness depends on the application logic. Lots of applications using RC RO transactions will never be affected by the cursor

Re: [Firebird-devel] Plugin version number

2014-06-10 Thread Dmitry Yemanov
10.06.2014 19:37, Dimitry Sibiryakov wrote: Actually, yes. I don't understand what you call user types of plugins and their difference from system types, because support for any plugin type must be coded in engine code directly. I cannot imagine a way to work with plugin that provides

Re: [Firebird-devel] Plugin version number

2014-06-10 Thread Dmitry Yemanov
10.06.2014 21:54, Alex Peshkoff wrote: You are not completely right. Imagine someone adds own provider to firebird. And that provider except other features wants to load some modules to perform various user-specific code - that modules can be treated as firebird plugins, at least plugin

[Firebird-devel] [FB-Tracker] Created: (CORE-4460) Expressions containing some built-in functions may be badly optimized

2014-06-10 Thread Dmitry Yemanov (JIRA)
Type: Bug Components: Engine Affects Versions: 2.5.2 Update 1, 2.1.5 Update 1, 2.5.2, 2.1.5 Reporter: Dmitry Yemanov Test cases for predicates distributed into the union sub-parts: select * from ( select rdb$relation_name from rdb$relations union select rdb

[Firebird-devel] Default page/cache settings

2014-06-05 Thread Dmitry Yemanov
All, In FB3, we have increased the default page cache size for Classic (SharedCache = false) from 75 to 256 pages. I'd like to propose other changes as well: 1) Bump the default page cache size for SuperServer (SharedCache = true) from 2K to at least 8K pages. Personally, I'd go for ~20K

Re: [Firebird-devel] Default page/cache settings

2014-06-05 Thread Dmitry Yemanov
05.06.2014 14:56, Gabor Boros wrotes: 2) Rename DefaultDbCachePages config setting to something like PageCacheSize, as default-db-something setting looks weird in the customized per-database configuration. If I (a user) read Size associate bytes, kilobytes, etc. This worries me as well.

Re: [Firebird-devel] DDL Triggers, how to retrieve type?

2014-05-23 Thread Dmitry Yemanov
23.05.2014 10:24, Dimitry Sibiryakov wrote: Allow dialect 1 to have access to BIGINT fields. I have a feeling that Adriano already did that for v3. Dmitry -- Accelerate Dev Cycles with Automated Cross-Browser

Re: [Firebird-devel] Multiple WHEN handlers

2014-05-09 Thread Dmitry Yemanov
09.05.2014 16:45, Dimitry Sibiryakov wrote: 09.05.2014 14:37, Dmitry Yemanov wrote: They were always allowed, so we cannot even think about breaking this. The only thing that may be treated like a bug is CORE-3275. Ok. From your comment in the ticket I conclude that _every_ matching handler

Re: [Firebird-devel] Careful writes: data and index

2014-05-09 Thread Dmitry Yemanov
09.05.2014 20:08, Leyne, Sean wrote: I was referring to cases where the disk controller has ignored the engine careful write order, by collapsing disk sector writes and applying them in a sequence optimal for the disk but out of order from a FB perspective (Jim's comment about micro code

Re: [Firebird-devel] MET_scan_relation()

2014-05-09 Thread Dmitry Yemanov
09.05.2014 18:13, Dimitry Sibiryakov wrote: What following asserts are supposed to check? That the relation type is assigned properly and, additionally, that the proper flags are already set by the prior MET_lookup_* calls. My debug build is falling into them every time I try to check

Re: [Firebird-devel] Careful writes: data and index

2014-05-08 Thread Dmitry Yemanov
08.05.2014 18:13, Dimitry Sibiryakov wrote: If a record is inserted or modified, what will be order of page written: data page first then index page or vice versa? IIRC, there is no precedence dependency between these two pages, so they can be written in any order. Dmitry

Re: [Firebird-devel] WHEN handler and data state

2014-05-08 Thread Dmitry Yemanov
08.05.2014 18:44, Dimitry Sibiryakov wrote: Which data state is supposed to be seen in WHEN block? Before undoing changes or after it? Say, we have update t set f=1 then in begin-end block update set f=2 is done and then exception is thrown. What value should give select f from t in WHEN

Re: [Firebird-devel] Careful writes: data and index

2014-05-08 Thread Dmitry Yemanov
08.05.2014 21:49, Leyne, Sean wrote: IIRC, there is no precedence dependency between these two pages, so they can be written in any order. So, with FW=OFF, killing server in-between can produce both orphan nodes and missing entries depending on luck and parallel activity. True, but that is

Re: [Firebird-devel] Careful writes: data and index

2014-05-08 Thread Dmitry Yemanov
08.05.2014 22:01, Dimitry Sibiryakov wrote: True, but that is database corruption problem, not an order of precedence issue. Orphan nodes are harmless, missing entries are worse. We're talking about [missing] entries that should be pointing to invisible (garbage) record versions. What

Re: [Firebird-devel] Careful writes: data and index

2014-05-08 Thread Dmitry Yemanov
08.05.2014 22:08, Dimitry Sibiryakov wrote: In this case transaction won't be marked as committed and record will be garbage collected sooner or later. Ah, so you meant the case where both TIP and the data page were written to disk, but the index page was not? Here I agree that FW=OFF makes

Re: [Firebird-devel] BUGCHECK 290

2014-05-07 Thread Dmitry Yemanov
07.05.2014 13:12, Dimitry Sibiryakov wrote: Is line tra_flags |= TRA_invalidated enough for that or something more should be done for transaction invalidation? Enough, AFAIK. Dmitry -- Is your legacy SCM system

Re: [Firebird-devel] BUGCHECK 290

2014-05-07 Thread Dmitry Yemanov
06.05.2014 18:32, Dimitry Sibiryakov wrote: AFAICS further DML operations are allowed in invalidated transaction. Shouldn't ROLLBACK to be the only permitted action? I would say that it makes sense to reject further DML, as it cannot be committed anyway. I'm not insisting on that though.

Re: [Firebird-devel] Feature request discussion (Reply to Planning the post v3 development)

2014-05-06 Thread Dmitry Yemanov
05.05.2014 20:13, Jim Starkey wrote: AFAIR, int64 integers are not converted into double, they're compressed using their native format. If so, it's a bug. The purpose of the index encoding is that all numbers have the same representation, based on actual value rather than declaration. It

Re: [Firebird-devel] Feature request discussion (Reply to Planning the post v3 development)

2014-05-06 Thread Dmitry Yemanov
06.05.2014 12:35, Dimitry Sibiryakov wrote: Decreasing the scale is allowed and should work fine, AFAIU. Shouldn't it be contrary?.. If in table is value 1.234 and scale is changed from 3 to 2, this value will be displayed as 1.23, but cannot be found by eq. Vice versa it works: value

Re: [Firebird-devel] Running firebird.exe as application

2014-05-06 Thread Dmitry Yemanov
06.05.2014 22:32, Mark Rotteveel wrote: I have been having some problems running Firebird 3 correctly from a zip-kit (as Super Server). After much trial-and-error it looks like when running as an application, that I need to start Firebird.exe with -a -m (instead of only -a as documented in

Re: [Firebird-devel] Feature request discussion (Reply to Planning the post v3 development)

2014-05-05 Thread Dmitry Yemanov
05.05.2014 11:05, Molnár Attila wrote: I'm createing domains, and using TYPE OF. But as I write it's not enough. This is just for variable declaration but I need a pair in PSQL body. Maybe this example would help to understand. EXECUTE BLOCK AS DECLARE VARIABLE tmp TYPE OF COLUMN

Re: [Firebird-devel] Feature request discussion (Reply to Planning the post v3 development)

2014-05-05 Thread Dmitry Yemanov
05.05.2014 19:06, Jim Starkey wrote: My sole reservation is that there can be information lost when a large valued 64 integer is converted into a double to generate the index key. AFAIR, int64 integers are not converted into double, they're compressed using their native format. My second

Re: [Firebird-devel] Questions on External Sort logic

2014-05-03 Thread Dmitry Yemanov
03.05.2014 21:32, Leyne, Sean wrote: So, here are my questions: 1. A query’s operations (the reading of the data and sorting) execute in a single thread/process, correct? Correct. 2. Is Internal sorting performed by the ExecuteWriteTempSortBlock() step? Internal buffer is sorted as

Re: [Firebird-devel] Feature request discussion (Reply to Planning the post v3 development)

2014-05-03 Thread Dmitry Yemanov
03.05.2014 20:48, Leyne, Sean wrote: My statement was based on my memory of why the use of IS NOT NULL was disabled in earlier FB releases. If IS NOT NULL can be treated the same as any other condition, why isn't it now? Firebird (and many other DBMS) simply don't use indices for negated

Re: [Firebird-devel] Feature request discussion (Reply to Planning the post v3 development)

2014-05-03 Thread Dmitry Yemanov
03.05.2014 20:48, Leyne, Sean wrote: I don't see what statistics will tell the engine. Unlike index distribution statistics, which provides some details on the commonality of values, I don't see how stats on the orderedness of a primary key provide any meaningful details, when the stat is

Re: [Firebird-devel] Questions on External Sort logic

2014-05-03 Thread Dmitry Yemanov
03.05.2014 22:12, Vlad Khorsun wrote: Internal sort (quicksort, btw) does not move records, only pointers. Records are re-ordered in sort order before full run is written to disk (if necessary). Sorry, I was talking about external sorting in general, not quicksorting the internal buffer.

Re: [Firebird-devel] Feature request discussion (Reply to Planning the post v3 development)

2014-05-03 Thread Dmitry Yemanov
02.05.2014 23:25, Vlad Khorsun wrote: - also it allows to have index coverage (also requires to use such index key encoding which allows to recover original value from index key) Is the problem mostly in numeric-double conversion or does compress() mangle the key unrecoverrably in any

Re: [Firebird-devel] Feature request discussion (Reply to Planning the post v3 development)

2014-05-02 Thread Dmitry Yemanov
30.04.2014 13:50, Molnár Attila wrote: *SIZE OF CHAR/VARCHAR domain or variable name, SCALE OF NUMERIC domain or variable name* - SIZE OF : returns max CHAR/VARCHAR length or NUMERIC precision, SCALE OF : return scale of NUMERIC - gain : by defining a variable with DOMAIN or TYPE

Re: [Firebird-devel] Feature request discussion (Reply to Planning the post v3 development)

2014-05-02 Thread Dmitry Yemanov
02.05.2014 22:03, Leyne, Sean wrote: It depends. Primary key may be stored more-or-less in regard to physical disk location. And the measure how good is INDEX vs NATURAL scan can be available to the optimizer (index clustering factor). Without the knowledge of way that Primary Keys map to

Re: [Firebird-devel] Feature request discussion (Reply to Planning the post v3 development)

2014-05-01 Thread Dmitry Yemanov
01.05.2014 23:24, Leyne, Sean wrote: Optimization I. - VOLATILE (default) / DETERMINISTIC flag for UDF and FUNCTION (maybe lifecycle for deterministic : statement, transaction, connection) - gain : preformance (can cache DETERMINISTIC UDF/FUNCTION results) Actually, I think that

Re: [Firebird-devel] Planning the post v3 development

2014-04-29 Thread Dmitry Yemanov
29.04.2014 02:13, Thomas Beckmann wrote: Main focus should be in asynchronous multi master scenarios, as Carlos pointed out. Everything else seems to be as specialization... Dimitry Sibiryakov will surely correct me, but I always thought that multi-master replication can hardly work without

Re: [Firebird-devel] Planning the post v3 development

2014-04-29 Thread Dmitry Yemanov
28.04.2014 23:05, Carlos H. Cantu wrote: I think most of them needs basic asynchronous replication, covering single and multi-master scenarios. For those who needs more complex scenarios, there are third party comercial tools. Anyway, I'm not the right person to answer, since I didn't need

Re: [Firebird-devel] Planning the post v3 development

2014-04-29 Thread Dmitry Yemanov
28.04.2014 23:31, Dalton Calford wrote: Architecturally, Firebird database is not active without user connections. This slightly changes with the LINGER support, but not so much. So the question is who should be waiting for the timer events when nobody is connected. And if it

Re: [Firebird-devel] Planning the post v3 development

2014-04-29 Thread Dmitry Yemanov
29.04.2014 02:02, Dimitry Sibiryakov wrote: I may be wrong as often, but AFAIU this dream may be a reality if: 1) Eliminate DFW 2) Perform DDL (operations with system tables) in user transaction 3) Make garbage collector to handle system tables well And reimplement the undo log to handle

Re: [Firebird-devel] Planning the post v3 development

2014-04-29 Thread Dmitry Yemanov
29.04.2014 12:09, Mark Rotteveel wrote: If you look at SQL Server, there jobs themselves are not defined for a specific database (although they may depend on one or more databases). AFAIK they are stored in the master database. Execution requires an Agent service to be running. We neither

Re: [Firebird-devel] Planning the post v3 development

2014-04-29 Thread Dmitry Yemanov
29.04.2014 13:12, Dimitry Sibiryakov wrote: According to its isolation level, I'd say. So user snapshot transaction should not seen changes done by itself (as user thinks, as it executes DDL in the same transaction)? Of course it can be documented, but I'd rather avoid such a tricky behavior.

Re: [Firebird-devel] Planning the post v3 development

2014-04-29 Thread Dmitry Yemanov
29.04.2014 13:05, Vlad Khorsun wrote: Technically - it is possible. Practically - what generation of altered object user transaction should work with ? Statements already having the object cached - the old version. Statements to be [re]prepared - the new version, as the metadata cache will

Re: [Firebird-devel] Fwd: ARM64 port

2014-04-29 Thread Dmitry Yemanov
29.04.2014 20:40, marius adrian popa wrote: While you mention PDP maybe is time for a task to cleanup all VMS dead code and languages (Claudio ?) Is there any VMS code remaining? We had wiped it out a while ago, IIRC. Only a few pieces were kept, related to the DLM (in tra.cp and /lock).

Re: [Firebird-devel] Re Planning the post v3 development

2014-04-28 Thread Dmitry Yemanov
28.04.2014 01:04, Jesus Garcia wrote: Allways my customers require me features that oracle and sql server has Well, they should understand that Firebird will never have all those features from Oracle and MSSQL. The question is what they really need. 1. Built-in replication. Our customers

Re: [Firebird-devel] Planning the post v3 development

2014-04-28 Thread Dmitry Yemanov
28.04.2014 16:14, Simonov Denis wrote: My list is as follows. Thanks, but I seemed to explicitly state that plain wishlists don't count. Choose top five from your list, start separate thread per feature and argue why we should prefer these features over other ones. Dmitry

Re: [Firebird-devel] Planning the post v3 development

2014-04-28 Thread Dmitry Yemanov
28.04.2014 20:30, Carlos H. Cantu wrote: It seems that I also didn't understand that you wanted separated messages for each feature discussion :( Well, we may start with the features intermixed inside this thread and then separate them for a more detailed discussion, if necessary. I just ask

Re: [Firebird-devel] Planning the post v3 development

2014-04-28 Thread Dmitry Yemanov
28.04.2014 19:48, Dalton Calford wrote: Android and iOS native clients if not native servers, are extremely important given the market growth in those areas and the lack of a good solid database engine to work with. Isn't sqlite solid enough? ;-) At least for the tasks a tablet can run. A

Re: [Firebird-devel] Planning the post v3 development

2014-04-28 Thread Dmitry Yemanov
28.04.2014 18:29, Carlos H. Cantu wrote: Here is my list: Arrrgh! :-) I've skipped the items I have nothing to say about (mostly due to lack of interest, sorry for fairness). 2) I second Jesus Garcia request for native replication, since people at FDD and in FireBase's list are always

Re: [Firebird-devel] Planning the post v3 development

2014-04-28 Thread Dmitry Yemanov
28.04.2014 18:37, Scott Morgan wrote: This message is the invitation to both project members and users who closely follow the development. UTC time zone support. Vital for international work and handy even for general use. Nice reminder, although I don't think it's trivial to implement.

Re: [Firebird-devel] Planning the post v3 development

2014-04-28 Thread Dmitry Yemanov
28.04.2014 16:14, Simonov Denis wrote: optimizer 1. Enable use MERGE / HASH JOIN for OUTER JOINs 2. Performing EXISTS / IN SEMI JOIN as including using MERGE / HASH, and NESTED LOOP using index 3. HASH aggregation Add to an existing method using sorting I don't think the optimizer

[Firebird-devel] Planning the post v3 development

2014-04-24 Thread Dmitry Yemanov
All, We're getting closer to the v3.0 feature freeze which is going to happen this summer. Everything roadmapped for v3 but not implemented before the deadline will be postponed. The next-after-v3 release is likely to incorporate most of the postponed features, but there may be new features

[Firebird-devel] [FB-Tracker] Created: (CORE-4402) Add timing statistics to the monitoring tables

2014-04-24 Thread Dmitry Yemanov (JIRA)
Reporter: Dmitry Yemanov It would be useful to track timing for different operations and aggregate these values at request / transaction / connection / database levels as other runtime statsitics is maintained. In particular, I was thinking about total time spent, CPU time (maybe

[Firebird-devel] [FB-Tracker] Created: (CORE-4403) Allow referencing cursors as record variables in PSQL

2014-04-24 Thread Dmitry Yemanov (JIRA)
Components: Engine Reporter: Dmitry Yemanov Priority: Minor Either explicit (DECLARE AS CURSOR) or implicit (FOR SELECT) PSQL cursors could make their current record available via the cursor name similar to OLD/NEW trigger contexts, thus making the INTO clause optional

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-4403) Allow referencing cursors as record variables in PSQL

2014-04-24 Thread Dmitry Yemanov
Claudio, Is this feature being asked for? ;-) Yes and it's very handy for people with an Oracle background. I wished it was here in Firebird when I was its user back in 2000 ;-) What I see is that fields with the same name, even though they come from different tables, would need to be

Re: [Firebird-devel] isql v3 with older servers

2014-04-15 Thread Dmitry Yemanov
Claudio, People, what is position of the team regarding isql v3's ability to connect to older server versions? - isql v3 only supports FB3 - isql v3 only supports FB3 and FB2.5 - isql v3 should support the whole FB2.X series. I'd say ISQL should support *at least* those versions that the

Re: [Firebird-devel] isql v3 with older servers

2014-04-15 Thread Dmitry Yemanov
15.04.2014 19:59, Dimitry Sibiryakov wrote: The only version-depended part of isql is metadata extraction. I don't think that there is a point to worry about its compatibility. There's also another one - family of SHOW commands. And they're expected to work as long as you're able to connect

Re: [Firebird-devel] isql v3 with older servers

2014-04-15 Thread Dmitry Yemanov
15.04.2014 20:23, Dimitry Sibiryakov wrote: And they will work as long as one requests objects that existed in previous versions. If show.epp/extract.epp is cleaned up to support v3.0 / ODS12 only, then requesting objects existing in v2.0 / ODS11 may fail. This is the whole point of this

Re: [Firebird-devel] isql v3 with older servers

2014-04-15 Thread Dmitry Yemanov
15.04.2014 21:30, Dimitry Sibiryakov wrote: If show.epp/extract.epp is cleaned up to support v3.0 / ODS12 only, then requesting objects existing in v2.0 / ODS11 may fail. This is the whole point of this discussion. Do anybody have examples of what will fail and how?.. Supporting v3 / ODS12

Re: [Firebird-devel] garbage_collect_idx() doesn't work?..

2014-04-14 Thread Dmitry Yemanov
14.04.2014 20:21, Dimitry Sibiryakov wrote: In this case shouldn't vio.cpp:realoc_record() to be reworked as well to avoid allocations? It extends the record only when required (new format is longer than the prior one). It's not something happening often for a single table. Dmitry

[Firebird-devel] [FB-Tracker] Created: (CORE-4388) SELECT WITH LOCK may enter an infinite loop for a single record

2014-04-13 Thread Dmitry Yemanov (JIRA)
Components: Engine Affects Versions: 3.0 Alpha 2, 3.0 Alpha 1 Reporter: Dmitry Yemanov If a concurrent transaction has deleted (and committed) the record that our transaction is trying to lock, the engine keeps infinitely attempting to lock the deleted record

Re: [Firebird-devel] TRA_rollback() and 'force' flag

2014-04-13 Thread Dmitry Yemanov
13.04.2014 19:26, Dimitry Sibiryakov wrote: What is the meaning of 'force' parameter for TRA_rollback? Is it license to leave database in inconsistent state: with orphan pages/BLOBs/index nodes for the sake of instant end of transaction? Yes. The state of transaction is consistent (rolled

Re: [Firebird-devel] TRA_rollback() and 'force' flag

2014-04-13 Thread Dmitry Yemanov
13.04.2014 20:05, Dimitry Sibiryakov wrote: In this case I would say that calling VIO_verb_cleanup() at the beginning is overkill because inside it will do slow rollback for each savepoint. VIO_verb_cleanup() rolls back nothing unless sav_verb_count is non-zero. It shouldn't be the case

Re: [Firebird-devel] classes\InternalMessageBuffer.h

2014-04-09 Thread Dmitry Yemanov
09.04.2014 09:56, Alex wrote: On 04/09/2014 10:14 AM, Claudio Valderrama C. wrote: Folks, sorry for nitpicking, but I don't like this alias in classes\InternalMessageBuffer.h: typedef ArrayUCHAR Buffer; // May be it will become a class in the future, but now it is just a plain array

Re: [Firebird-devel] Regression: system generator RDB$BACKUP_HISTORY cannot be modified

2014-04-08 Thread Dmitry Yemanov
08.04.2014 11:54, Vlad Khorsun wrote: Personally, i not consider it as important, if nbackup v3 will not work with Firebird before v3... Me neither. But if it can be easily done, why not. Dmitry -- Put Bad

[Firebird-devel] User mapping changes

2014-04-08 Thread Dmitry Yemanov
Alex et al, May I ask to rethink namings, please? Things like RDB$MAP or /jrd/Mapping.cpp sound very confusing. What is mapped to what? Maybe Mapping.cpp is about memory mapped files? I'd suggest at least RDB$USER_MAP and UserMapping.cpp instead. Maybe someone else will have a better

Re: [Firebird-devel] garbage_collect_idx() doesn't work?..

2014-04-07 Thread Dmitry Yemanov
07.04.2014 14:31, Alex Peshkoff wrote: HalfStaticArray has no overhead as long as it works with statically allocated memory. But does not matter - as long as 3 elements is potential bug there is really no need in it. Please leave this ticket / patch up to me. Dmitry

Re: [Firebird-devel] Memory pools using

2014-04-07 Thread Dmitry Yemanov
07.04.2014 21:21, Dimitry Sibiryakov wrote: IIRC at the time of FB 1.5 this context things and call of SET_TDBB() at the beginning of every routine were considered as a temporary stubs till proper code cleanup for proper encapsulation and getting rid of side effects. Is my memory wrong or

[Firebird-devel] [FB-Tracker] Created: (CORE-4386) Report more details for object in use errors

2014-04-05 Thread Dmitry Yemanov (JIRA)
Reporter: Dmitry Yemanov Priority: Minor While a proper metadata naming convention surely helps, the engine could be polite enough to report not only the name of the used object but its type (table/index/procedure/etc) as well. Also, for used indices currently a string INDEX

[Firebird-devel] [FB-Tracker] Created: (CORE-4384) Problems when a table grows beyond 65535 pointer pages

2014-04-04 Thread Dmitry Yemanov (JIRA)
: Engine Affects Versions: 3.0 Alpha 2, 3.0 Alpha 1, 2.5.2 Update 1, 2.1.5 Update 1, 2.5.2, 2.1.5, 2.5.1, 2.1.4, 2.5.0, 2.1.3, 2.1.2, 2.1.1, 2.1.0 Reporter: Dmitry Yemanov The USHORT pp_sequence number wraps and it may lead to unexpected issues like an infinite loop inside

Re: [Firebird-devel] garbage_collect_idx() doesn't work?..

2014-04-03 Thread Dmitry Yemanov
03.04.2014 20:16, Dimitry Sibiryakov wrote: May I propose the attached fix that uses second approach?.. I'm not sure I like the extra load put on the memory manager. I'd rather think about replacing the original tra_undo_record buffer with a stack of record buffers ready for reuse. Dmitry

Re: [Firebird-devel] garbage_collect_idx() doesn't work?..

2014-04-03 Thread Dmitry Yemanov
03.04.2014 20:32, Dimitry Sibiryakov wrote: I'm not sure I like the extra load put on the memory manager. It is transaction-local memory pool. Even if there's no contention there, allocating/deallocating is always slower than not doing that at all. IMHO, this is unnecessary code

Re: [Firebird-devel] garbage_collect_idx() doesn't work?..

2014-04-03 Thread Dmitry Yemanov
03.04.2014 20:38, Dimitry Sibiryakov wrote: Take into account that the record content is copied from temporary storage (may be read from disk). Allocation from local pool is not a big deal in this case. From another side, the record data has enough chances to be copied from the TempSpace

Re: [Firebird-devel] garbage_collect_idx() doesn't work?..

2014-04-03 Thread Dmitry Yemanov
03.04.2014 20:59, Dimitry Sibiryakov wrote: I.e. duplicate code from memory pool in jrd_tra, except may be those couple of atomic ops mentioned by Alex. OMG. Get back and re-read what I was proposing. Dmitry --

Re: [Firebird-devel] VIO_erase() and update_in_place()

2014-04-02 Thread Dmitry Yemanov
02.04.2014 20:59, Dimitry Sibiryakov wrote: What is the reason why VIO_erase() always creates a new record version instead of using update_in_place() as it does VIO_modify()? Can you imagine the same record being deleted twice? Dmitry

Re: [Firebird-devel] VIO_erase() and update_in_place()

2014-04-02 Thread Dmitry Yemanov
02.04.2014 22:03, Dimitry Sibiryakov wrote: What is the reason why VIO_erase() always creates a new record version instead of using update_in_place() as it does VIO_modify()? Can you imagine the same record being deleted twice? No. But what it changes? VIO_update() calls

Re: [Firebird-devel] VIO_erase() and update_in_place()

2014-04-02 Thread Dmitry Yemanov
02.04.2014 22:16, Dimitry Sibiryakov wrote: VIO_erase() cannot delete some record twice in the same transaction, period. But it can delete updated record, no?.. Yes, but this is still going to be the last version in the chain. Perhaps nobody cared whether there will be two or three versions

Re: [Firebird-devel] DPM_get() and DPM_fetch()

2014-04-01 Thread Dmitry Yemanov
01.04.2014 20:38, Dimitry Sibiryakov wrote: Reading code, I see that in some cases DPM_get()+VIO_data() is used to get record data and in some other cases DPM_fetch()+VIO_data() is used for the same purpose. But I cannot understand what is the difference between these cases. I see that

Re: [Firebird-devel] garbage_collect_idx() doesn't work?..

2014-03-29 Thread Dmitry Yemanov
29.03.2014 23:06, Vlad Khorsun wrote: Record buffer is cached at the transaction level and exists in single instance. It is OK while we use just one instance of record buffer at the same time. What is meant here by record buffer -- tra_undo_record or what? Dmitry

Re: [Firebird-devel] Created: (CORE-4368) Provide name of TABLE / VIEW when some statement violates CHECK.

2014-03-28 Thread Dmitry Yemanov
28.03.2014 19:23, Adriano dos Santos Fernandes wrote: The only problem would be old server accessed with new client and message file. It will show: validation error for column Missing arg #3 - possibly status vector overflow.NAME, value ...' IIRC, the overflow protection (missing arg N)

Re: [Firebird-devel] Created: (CORE-4368) Provide name of TABLE / VIEW when some statement violates CHECK.

2014-03-28 Thread Dmitry Yemanov
28.03.2014 19:23, Adriano dos Santos Fernandes wrote: But AFAIK, value @2 is also new, which also causes problem, so I don't think this is a showstopper. Nope, value @2 is there for at least a decade. I see it in the v2.0 sources. Dmitry

Re: [Firebird-devel] Created: (CORE-4368) Provide name of TABLE / VIEW when some statement violates CHECK.

2014-03-27 Thread Dmitry Yemanov
27.03.2014 19:46, Adriano dos Santos Fernandes wrote: Do you think it's ok to output validation error for column TABLE.ID? Just for the record, I was thinking the same line. Dmitry -- Firebird-Devel mailing list,

Re: [Firebird-devel] Bug with JOIN/LEFT JOIN?

2014-03-26 Thread Dmitry Yemanov
26.03.2014 10:44, Thomas Beckmann wrote: Please consider the following example: with recursive CTE_CNT as (select 1 as I from RDB$DATABASE union all select I + 1 from CTE_CNT where I 20) select i.I, j.I, k.I from CTE_CNT i left join CTE_CNT j on i.I = j.I and j.I10 join CTE_CNT k on j.I

Re: [Firebird-devel] FB3 error in select with order by

2014-03-21 Thread Dmitry Yemanov
21.03.2014 19:31, Norbert wrote: WI-T6.3.0.30932 Firebird 3.0 Alpha 2 on CENTOS 6.5 and W7 create table test ( id integer generated by default as identity primary key, siteid integer not null); create index ix_test_siteid on test (siteid); insert into test ( siteid )

Re: [Firebird-devel] FB3 error in select with order by

2014-03-21 Thread Dmitry Yemanov
21.03.2014 20:32, Dmitry Yemanov wrote: Obviously a bug. Working on it, thanks. Fixed now, please test. Dmitry -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide

Re: [Firebird-devel] RFC: stop fiddling with sys tables

2014-03-20 Thread Dmitry Yemanov
21.03.2014 01:38, Claudio Valderrama C. wrote: - Linking user tables to sys tables (FK) should be forbidden (I didn't try, but if it works, it shouldn't). Sys tables don't have PK/UK constraints (only unique indices), so FKs cannot be created. - User code should not fiddle with sys

[Firebird-devel] [FB-Tracker] Created: (CORE-4365) Equality predicate distribution does not work for some complex queries

2014-03-15 Thread Dmitry Yemanov (JIRA)
Type: Bug Components: Engine Affects Versions: 3.0 Alpha 2, 3.0 Alpha 1, 2.5.2 Update 1, 2.1.5 Update 1, 2.5.2, 2.1.5, 2.5.1, 2.1.4, 2.5.0, 2.1.3, 2.1.2, 2.1.1, 2.1.0 Reporter: Dmitry Yemanov Artificial test case: set planonly; select * from ( select rdb$relation_id

Re: [Firebird-devel] MySQL versus Firebird

2014-03-11 Thread Dmitry Yemanov
11.03.2014 11:27, Vlad Khorsun wrote: Then post links to working sites ;) I can't access it whole yesterday and today nothing changed. Same here, although I managed to access that article via a different URL yesterday: http://www.tuicool.com/articles/qIvAra It also works badly, but the

Re: [Firebird-devel] MySQL versus Firebird

2014-03-11 Thread Dmitry Yemanov
11.03.2014 09:59, marius adrian popa wrote: I needed comments from developers also You'd better ask questions then. I don't care to comment what unknown people write about Firebird over the internet. Dmitry --

<    4   5   6   7   8   9   10   11   12   13   >