Re: [Firebird-devel] Crypto Performance

Jim, > I don't know of any known problems with AES/CBC. It is simply the most > trusted crypto algorithm in the history of computing. It isn't possible prove > that something can't be broken, but many, many very smart people have > spent many years searching for an attack over 15+ years without

Re: [Firebird-devel] Crypto Performance

Jim, > 1. As Sean pointed out, the AES instructions are common on Intel > processors.  Not so for AMD, however, which only supports AES in their high > end server chips.  My HP AMD mini-tower, for example, doesn't have the > AES instruction set. It seems that AMD might be exaggerating their

Re: [Firebird-devel] Crypto Performance

> None of these suggest that there is an attack -- read the comments. They refer to a possible attack and provide links to other sites. One of the sites has a link to the following: http://www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.pdf which (at least to my scanned reading)

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-4936) Reduce internal contention in background garbage collector

> Reduce internal contention in background garbage collector > -- > > Key: CORE-4936 > URL: http://tracker.firebirdsql.org/browse/CORE-4936 > Project: Firebird Core > Issue Type:

Re: [Firebird-devel] Replacing `instsvc`

> > reading Paul's "instsvc and ServerMode" got me thinking whether we > > even need the `instsvc` executable? The installer can install the > > services directly and for batch files we can use PowerShell and the > > New-Service etc. cmdlets. This will save some kB from the package. And > > also

Re: [Firebird-devel] instsvc and ServerMode

> > While I have no objections to the config API in general, I'd note that: > > (1) it's not instsvc business, (2) cpl applet must die, (3) I'm not > > sure we need any tool for this task. > > Out of interest - why do you think the cpl applet must die? What purpose do you think it fulfills?

Re: [Firebird-devel] Speed of 2.5.4 vs 2.5.5

Dmitry, This seems worthy of a Tracker case, no? Sean From: Dmitry Yemanov [mailto:firebi...@yandex.ru] Sent: December 6, 2015 5:51 AM To: For discussion among Firebird Developers Subject: Re: [Firebird-devel] Speed of 2.5.4 vs 2.5.5 Already known, but

Re: [Firebird-devel] Literals in CASE expression

Dmitry, > > In Pavel's use case "color" is a VarChar as such any value/string/variable > which is assigned to it should be cast as a VarChar, regardless of the > intermediate datatype. > > > > The current outcome is wrong! > > The SQL committee respectfully disagrees. Actually, given that MS

Re: [Firebird-devel] Literals in CASE expression

Dmitry, > > To sum it up, standard dictates that literals are CHARs, aggregated > > values has length of longest one and because CHARs are padded with > > spaces to declared length, we have such stupid output in CASE. Sure, > > it could be easily "fixed" with CAST or TRIM, but it's extremely > >

Re: [Firebird-devel] Lock manager's hash calculations

>On the other hand, CS is going down, so lock manager performance may be > not a critical part anymore? It will take groups like mine a while before they embrace the new SMP functionality of v3 -- there is application/deployment testing to be performed... So, CS will be around for a

Re: [Firebird-devel] Transaction id size in Firebird 3

> Is there an easy trick to get Firebird to produce a 33 bit or longer > transaction > id without having to commit 32^2 + 1 transactions so I can check if my > implementation will work with FB 3.0.1? Hack the header of an existing database file with a Hex editor? Sean

Re: [Firebird-devel] Compiler for official Firebird 4 release on Windows

> However, I seriously question the need to support Windows XP and > Windows Server 2003 for Firebird 4. I completely agree! There comes a time when some OSs/installs need to be recognized as *legacy*. Systems based on those platforms need to recognize that they can't be running the

Re: [Firebird-devel] [Firebird-checkins] SF.net SVN: firebird:[62991] firebird/trunk

>Adapting changes to exotic builds are up to their maintainers. >Isn't all this too obvious?.. This primary issue, Dimitry, is that you are making changes without any consultation, assuming that your vision of a problem/solution is the right one for everyone else. You need to post

Re: [Firebird-devel] ODP: Re: fb3 connections limit

> Microsoft is now supporting the Linux poll() as WSAPoll(). Much more > intelligent data structures and is smart enough to wake up when the remote > end of a socket is closed. I don't know what platforms do or don't support > poll() Client OS == Windows Vista+ Server OS == Windows 2008+

Re: [Firebird-devel] ODP: Re: fb3 connections limit

> i read this but i still do not know the reason. Is this declared by Firebird > in code. > Because i read in this article that there is no limit in Winsock at all. > Only constant FD_SETSIZE at compilation time which can by changed in code. > But maybe i can understand this incorrectly

Re: [Firebird-devel] EXECUTE STATEMENT ON EXTERNAL DATA and Crypted Databases

All, > 25.01.2016 16:27, Adriano dos Santos Fernandes wrote: > > So, "if you 'use this thing', your database cannot be used with > > EXECUTE STATEMENT in others databases"? > >Why? It can. > > >> >As usual, it must call IProvider->SetDbCryptCallback() passing > >> >current connection's

Re: [Firebird-devel] nbackup -F without nbackup binary

> The main reason it was not done are usage patterns. -F switch is needed in 2 > cases: > - After restoring backup of database using non-nbackup tools (i.e. > someone does: alter database begin backup; copies db-file using some non- > firebird tools; alter database end backup) and after is wants

[Firebird-devel] Limit on Old and New context variables in triggers ?

All, We are running into an interesting problem while trying to implement some triggers. We are getting the following message: Cannot commit transaction: Undefined name. Too many Contexts of Relation/Procedure/Views. Maximum allowed is 255. We have tried to break up the trigger into multiple

Re: [Firebird-devel] Limit on Old and New context variables in triggers ?

> BLR uses a byte for context variables.  It's my fault.  Ann will explain that > I am > a victim of the 16 bit depression. More like *8* bit depression, since the limit is 255 variables. Sean -- Site24x7 APM

Re: [Firebird-devel] Limit on Old and New context variables in triggers ?

> > I always thought that this error was about table/view references, not > > about old/new context variables. > > What is the source of the error? > > OLD/NEW occupy two contexts, the rest is from somewhere else. Do you > have computed fields with embedded selects that are being accessed via

Re: [Firebird-devel] Limit on Old and New context variables in triggers ?

Dmitry, > > > I always thought that this error was about table/view references, > > > not about old/new context variables. > > > What is the source of the error? > > > > OLD/NEW occupy two contexts, the rest is from somewhere else. Do you > > have computed fields with embedded selects that are

Re: [Firebird-devel] Limit on Old and New context variables in triggers ?

> > What if one were to replace some contexts with calls to SPs that > > executed those actions? Would the context counts from the SPs be > > added to those of the trigger? > > Nope. The context limit is bound to a request. Every procedure/trigger has its > own request, thus a separate context

Re: [Firebird-devel] Limit on Old and New context variables in triggers ?

> Em 16/02/2016 19:55, Leyne, Sean escreveu: > > > > > >>> What if one were to replace some contexts with calls to SPs that > >>> executed those actions? Would the context counts from the SPs be > >>> added to those of the trigger? > >&g

Re: [Firebird-devel] RFC: File names with non-ASCII non-ANSI letters

Alex, > The main problem with use of any kind of file ID is when create database is > performed - file may not exist. What kind of "use" of the file ID are you referring to? AFAIU, the file ID would only be used to identify if a db filename matches an existing/already opened db file (the file

Re: [Firebird-devel] RFC: File names with non-ASCII non-ANSI letters

> >> Why it is better than BY_HANDLE_FILE_INFORMATION used currently ? > > > > FILE_OBJECTID_BUFFER has a unique File/Object ID, > BY_HANDLE_FILE_INFORMATION doesn't provide such a value. > > {dwVolumeSerialNumber, nFileIndexHigh, nFileIndexLow} is a unique > combination. I stand corrected, I

Re: [Firebird-devel] RFC: File names with non-ASCII non-ANSI letters

> > It seems that no one has looked at the File Management Structures of > > the Windows API for quite some time, it seems that ObjectId of the > > FILE_OBJECTID_BUFFER structure (which is supported as of WinXP) would > also seem to fit the bill! > >Why it is better than

Re: [Firebird-devel] RFC: File names with non-ASCII non-ANSI letters

Alex, > Sean, if we limit ourself to only already opened files - we have no problems. > But there are places (like per-database config) where we are not sure does > file exist and if yes is it opened or not. For posix (where file ID exists no > matter is file opened or not) I'm currently using

Re: [Firebird-devel] File lookup (was: RFC: File names with non-ASCII non-ANSI letters)

>I.e. sequence like this: > > 1) create dbb with flag "creating" > 2) get list mutex > 3) create the file and get its id 1- This would destroy any existing file, no? 2- why "get list mutex" before the create file and/or get fileID? Wouldn't the better "creating" order be: - try to

Re: [Firebird-devel] RFC: File names with non-ASCII non-ANSI letters

> Sean, I see no problems with changing way of files comparison for windows if > needed. I just disagree with case-insensitive comparison on posix where FS is > case-sensitive. > And it applies to all places where file names are used, including config > files. Then maybe we need to rethink how

Re: [Firebird-devel] File lookup

> 14.03.2016 20:25, Leyne, Sean wrote: > > - try to open/create file with non-shared access attribute, if success then > get fileID else fail/ throw "file already exists" > >In superserver at this point other thread can attach to this file and get > br

Re: [Firebird-devel] RFC: Tablespaces

Dmitry, > When we speak about tablespaces, it usually means that the database > consists of multiple files and different database object are stored in > different > files. Each such file is named within a database and called a tablespace. And > each tablespace has its own page set and page

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

> I don't know what gai.conf is (it's not in my Firebird folder). It should be > as > easy as possible and as less configuration as possible when we install the > software on the servers of our customers. > > As we still mainly live in an IPv4 world (especially in LANs) - would it be > possible

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

Michael, > For Windows, the policy table seems to be managed with netsh command: > > https://technet.microsoft.com/en- > us/library/cc740203(v=ws.10).aspx#BKMK_5 > > http://www.colorconsole.de/cmd/en/Windows_Vista/netsh/interface/ipv6/ > add/prefixpolicy.htm Thanks for the pointers. But

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

Stefan, > The problem is when I use the Fb3 client to connect to a Fb2.5 database. > Then there is this one second delay. > > To sum things up: > > Connection time using the new Fb3 fbclient.dll: > - 3.0 database using "localhost" - quick > - 3.0 database using "127.0.0.1" - quick > - 2.5

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

>To let rumors that Firebird is unbearable slow to spread is a bad thing > too. 1- 1 sec is not "unbearable"! 2- Slowness only occurs when using "localhost" with v3 client *and* v2.5 server -- a very unusual situation (why would you have new client installed on same host as old

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

>"Solutions" that only shift the problem into less visited area or drop the > problem to users is not a way to go. > >Quoting RFC 6724: > > >Well-behaved applications SHOULD NOT simply use the first address > >returned from an API such as getaddrinfo() and then give up if it >

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

> Sean, can you confirm that there is no delay when using 3.0 fbclient with > remote 2.5 server? I don't have that config available, perhaps Stefan can try and report back. Sean -- Find and fix application

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

> > Unfortunately, this function available in server OS starting with > > Win2003 but is only available on client OS as of Win8.1 (the page > > awkwardly refers to Vista support -- which would imply Win7+) > > Vista and up are supported(maybe some XP versions, but I think Microsoft > removed

[Firebird-devel] FYI: tracker.firebirdsql.org and web.firebirdsql.org are offline for infrastructure maintenance

All, The systems should be offline for 3-4 more hours. Sean -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of

Re: [Firebird-devel] FYI: tracker.firebirdsql.org and web.firebirdsql.org are offline for infrastructure maintenance

> The systems should be offline for 3-4 more hours. The maintenance was completed earlier than excepted, the systems are now online. Sean -- Find and fix application performance issues faster with Applications

Re: [Firebird-devel] FB/Java embedded connections

> I think Adriano is taking about the fact that someone from Java code running > inside Firebird would be able to make an embedded connection to any > database running on the same server. That is a totally different security > threat than the capability that a normal Java program with Jaybird has

Re: [Firebird-devel] FB/Java embedded connections

> 19.05.2016 19:32, Mark Rotteveel wrote: > > I think Adriano is taking about the fact that someone from Java code > > running inside Firebird would be able to make an embedded connection > > to any database running on the same server. That is a totally > > different security threat than the

Re: [Firebird-devel] Trace files and lock directory

What about the .conf and log files? Sean From: Dmitry Yemanov <firebi...@yandex.ru> Sent: Thursday, April 14, 2016 11:32 AM To: For discussion among Firebird Developers Subject: Re: [Firebird-devel] Trace files and lock directory 14.04.2016 18:27,

Re: [Firebird-devel] RFC: Timeouts

> > 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 engine ? Yes, the engine would be **waiting** for the

Re: [Firebird-devel] RFC: Timeouts

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 engine ? > > > > Yes, the engine would

Re: [Firebird-devel] RFC: Timeouts

> >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.state > > ment_timeouts > > > > > >

Re: [Firebird-devel] RFC: Timeouts

> > 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 engine of > waiting. > > > > Am I correct?

Re: [Firebird-devel] Virtual metadata

Roman, > May I ask an example? > > Will it work? > > start transaction; > > alter table T add column N INTEGER; > > insert into T (..., N) values (..., 10); > > commit; IMO, it should. But, the interesting question would be: What would be the state if instead of "commit", you executed

Re: [Firebird-devel] Virtual metadata

> > Roman, > > > >> May I ask an example? > >> > >> Will it work? > >> > >> start transaction; > >> > >> alter table T add column N INTEGER; > >> > >> insert into T (..., N) values (..., 10); > >> > >> commit; > > IMO, it should. > > > > But, the interesting question would be: > > > > What would

Re: [Firebird-devel] RFC: Timeouts

>Other mainstream DBMS already have support for active statement and > idle session timeouts. I know no example of transaction timeout, though. I > think, transactions timeouts could bring more troubles than goods and in > many cases could be replaced by idle session timeouts. Therefore i

Re: [Firebird-devel] RFC: Timeouts

>Sure. And it is stated in docs at first place: > > --- >The feature could be useful for: > - database administrators get instrument to limit heavy queries from >consuming too much resources The problem is that long running transactions does not always equate to "heavy

Re: [Firebird-devel] RFC: Timeouts

> > --- > >The feature could be useful for: > > - database administrators get instrument to limit heavy queries from > >consuming too much resources > > The problem is that long running transactions does not always equate to > "heavy queries". > > (1) A NATURAL SELECT which

Re: [Firebird-devel] RFC: Timeouts

Dmitry, > That said, I'd vote against reworking the current design. Perhaps, we could > additionally implement what Sean suggests, but *only* at the server side. I expected that the "ExecutionQuota" would be something only executed at the server side, since that is the only place where the

Re: [Firebird-devel] RFC: Timeouts

> > it is the value that represent a direct CPU cost of a SQL statement. > > You actually seem wanting CPU quotas. But they're not timeouts. A long- > running statement may produce almost zero CPU load. I have no problem with "ExecutionQuota" describing the functionality that I am referring

Re: [Firebird-devel] C++11 features

>As I was said, it would drop out some platforms such as HPUX and Solaris > where compilers don't support C++11 standard. Are these platforms that significant anymore for Firebird? Are there more than 1000 Firebird deployments on them? Since we are talking about changes which apply to

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

> 11.11.2016 10:06, Karsten Strobel wrote: > > Compared to MS SQL, Firdbird's localhost TCP roundtrips from Client to > > Server for doing things like single-row inserts or updates take > > significantly longer. There may be a several reasons for this. > >The most viable one that MS SQL

[Firebird-devel] tracker.firebirdsql.org and web.firebirdsql.org will be offline Tuesday November 22 from 20:00 to 24:00 EST

Sean -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] arithmetic exception, numeric overflow, or string truncation after change column datatype and select from older format view

> SQL> > SQL> select * from v; > > A > == > Statement failed, SQLSTATE = 22001 > arithmetic exception, numeric overflow, or string truncation -string right > truncation > SQL> > > > As you can see.. there is no error until the records are inserted or updated > with a value that the length

Re: [Firebird-devel] This can be closed CORE-5120

Done From: marius adrian popa [mailto:map...@gmail.com] Sent: Friday, November 4, 2016 5:38 AM To: For discussion among Firebird Developers Subject: [Firebird-devel] This can be closed CORE-5120 http://tracker.firebirdsql.org/browse/CORE-5120

Re: [Firebird-devel] Firebird 4 identifier limits

> As far as I understand it is specifically for backwards compatibility (eg > tools > that expect/depend on the max 31 characters **and** max 31 > bytes) limit OK, that's a reasonable answer. But does that mean that it needs to be configurable? It would seem that the better answer would be

Re: [Firebird-devel] Firebird 4 identifier limits

> > Is there a maximum length, or can I theoretically use a length of say > > 8191 characters for an identifier? > > Maximum is 63 characters. IIRC, configuration allows to lower this limit. Why is a configuration setting for this required? This seems like a fix/complication for a problem that

[Firebird-devel] MON$Attachment fields vs. RDB$Get_Context("SYSTEM", ....)

One of my developers was looking for a simple way to determine what Process was the current DB operation related to. I knew that MON$Attachments has a MON$Remote_Process value, so I expected the same details would be available thru RDB$Get_Context("SYSTEM",) call. But I was wrong. There

Re: [Firebird-devel] MON$Attachment fields vs. RDB$Get_Context("SYSTEM", ....)

> 04.04.2017 16:30, Leyne, Sean wrote: > > > > BTW, why would they have names which are different from the names > already established in the MON$ table? > > > >>> - MON$REMOTE_PID > >>> - MON$REMOTE_PROCESS > > Becau

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

> 19.04.2017 14:07, Adriano dos Santos Fernandes wrote: > > Transaction consistency and multiple connections are a sufficient and > > easier to use feature. > >CORE-5483 is also sufficient and easy to use, but still you called it "a > hack" > with rage. Because it is a "hack". You

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

>It can. Nothing prevent you from starting several read-only snapshot > transactions at once. If they all are started without any commit between > them (which can be ensured by a number of different ways) Really, how? I have client with over 500 connection to a database, I am pretty sure

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

> 2- that the cost of any approach to ensure such "alignment" will not be so > significant that it compromises system performance. Ooppps! That should have read: 2- that the cost of any approach to ensure such "alignment" *will be* so significant that it compromises system performance.

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

> > 2- that the cost of any approach to ensure such "alignment" will not be so > significant that it compromises system performance. > >The simplest method: ON COMMIT trigger waiting for some flag to be > unset. You set flag, start your transactions and then reset the flag. > Performance

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

> Being able to start next transaction, > basically, from the point where the previous left would be so convenient and > remove a lot of hacks we have in place right now. To be clear, in my example/use case the "master transaction" would still be active and the related connection would be

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

Adriano, > 1) A server (not database server) receives a request and dispatch it to others > servers for extra processing and more than one server need to access the > same database in a consistent way. > > 2) A multi-threaded program (may be a future version of gbak) wants to > dispatch

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

> If you need simultaneous queries - make them possible, > what the point of transaction hacking? You want a single "view" of the database from multiple _connections_. There is nothing that provides this, today -- There is no way to ensure that all connections have that same view. Sean

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

> > Really, how do you propose to coordinate the transactions account the > separate processes (potentially different hosts)? > >What? So far you talked about transactions from one multi-threaded > application. Where "different hosts" came from all of sudden? I never said anything about a

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

> > You want a single "view" of the database from multiple _connections_. > >I still see no point for _multiple_ connections. Isn't one enough? No -- with a single connection only 1 SQL can be executed at a time -- regardless of the number of threads to your process. Scenario: I want to

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

>    With current Firebird architecture you won't get better performance from 5 > connections. > Dmitry Kouzmenko some time ago made a video that busted this myth. > > Nope, video was about inserts in multiple connections into one table. This is > - > yes, useless. 1 connection inserts all this

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

> On 18/04/2017 16:41, Dimitry Sibiryakov wrote: > > 18.04.2017 21:30, Leyne, Sean wrote: > >>>With current Firebird architecture - yes. It can be changed. > >> Really, then why have we been living with that @#$@#$@# limitation for > more than 10 years!

Re: [Firebird-devel] Optimisation of where afield = coalesce(value1, value2 )

> To evaluate COALESCE, e.emp_no must be known. Why? Is it not really the case that for all practical purposes the COALESCE will always return a value How else could COALESCE(?, NULL ) [Example #3] use an index? {Nothing says that the input parameter won't be NULL} Sean

Re: [Firebird-devel] HASH function (CORE-4436)

> We have HASH function that returns a 64 bit integer. The algorithm is bad and > the result too small for a hash. > > I propose to extend the same function with a second parameter with the > algorithm name. > > When only one parameter is passed, things works as now. > > When two parameters

Re: [Firebird-devel] HASH function (CORE-4436)

> > I think the point is, if a cracker has a security database, it can run > > billions of SHA1 hashes per second using the same salt in a brute > > force attack, because SHA1 is a fast (suitable to hash large files) > > algorithm. > > > > With bcrypt, with is purposely slow, the cracker can't

Re: [Firebird-devel] HASH function (CORE-4436)

> > We need to decide whether the algorithm name can be passed dynamically > > (and thus be presented as "value" in the grammar) or must be > > predefined (via a string literal or maybe token). The latter gives us > > more flexibility regarding the result type. > > This is an interesting idea.

Re: [Firebird-devel] hello world example of gpre requested

> With Cobol things are worse. I do not know any sample, what is worse - > noone of FB developers ever used to write a single line using that language. > And if I'm not mistaken gpre distributed in binaries does not support cobol. Actually, Steve Boyd provided patches for Cobol support some

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

> The trick words is how to shortly tell this "the snapshot used to start > transaction ". > > And it's even more trick when we think about commit retaining. > > My understand is that if transaction had a commit retaining, subsequent > new derived transactions will use the snapshot after the

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

> >>> + | SNAPSHOT SHARING FROM > >> SNAPSHOT BASED ON > >> ? > >> > > Do you think with this words it's clear that the new transaction uses > > the same snapshot used in , instead of incorrectly saying that it > > will use as the snapshot for the new transaction? > > > > Thinking in these

Re: [Firebird-devel] [FB-Tracker] Created: (CORE-5538) Add ability to backup/restore only those (several) tables which are enumerated as command line argument (pattern)

> This is far from a simple request and would require fundamental changes to > gbak. FYI, v2.5 already has the basic feature. Pavel's request is to make it easier to define the scope/criteria of the tables to be excluded. Gbak is a logical dump of database contents that when restored >

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

> "Starting from"? That would be misleading, the connection would not be able to see commits from later transactions, which is certainly not the case. Sean -- Check out the vibrant tech community on one of the

Re: [Firebird-devel] SUPERSERVER_V2

> > - Asynchronous File I/O > >It is not really asynchronous as it waits for the completion of every > single IO > request. True, but it allows the storage controller to decide the best order in which to perform the operations... > Also, note, it completely disables file system

Re: [Firebird-devel] Under what condition can RDB$RELATION_TYPE be NULL?

> shouldn't the restore fix this up and make NULL explicit 0? gbak is not a special process, it is restricted the same as user connections, so with v3+ it would not be able to execute any DML operations on system tables. Sean

Re: [Firebird-devel] SUPERSERVER_V2

Vlad, > >>> - Asynchronous File I/O > >> > >> It is not really asynchronous as it waits for the completion of > >> every single IO request. > > > > True, but it allows the storage controller to decide the best order in which > to perform the operations... > > >Order of what ? IO

Re: [Firebird-devel] SUPERSERVER_V2

> > Async/Overlapped IO allows for IO on any number of file blocks (aka pages) > without limit to their locations, consecutive or not. > >You words "single operation for any storage device" make me think that > you are referring to a single OS call. There is no such API in "only platform >

[Firebird-devel] Effect of DST on current_timestamp values

A post to the Firebird support list pointed out that current_timestamp values do not correctly reflect the effect of DST time changes while the server is running. In order for current_timestamp to reflect the correct local time values, the server needs to be restarted. Though it never

Re: [Firebird-devel] SUPERSERVER_V2

> What's SUPERSERVER_V2 in the code? My review of the code (back in 2003, see attached) found the following: - Asynchronous File I/O - PreFetch Data Pages (i.e. statement is a natural scan so read-ahead in the file...) - Defer Header Page Write (i.e. reduce the number of times that the header

Re: [Firebird-devel] SUPERSERVER_V2

Forgot to attachment... > -Original Message- > From: Leyne, Sean [mailto:s...@broadviewsoftware.com] > Sent: Thursday, May 25, 2017 3:19 PM > To: For discussion among Firebird Developers de...@lists.sourceforge.net> > Subject: Re: [Firebird-devel] SUPERSERVER_V2 &

Re: [Firebird-devel] [FB-Tracker] Commented: (CORE-5631) Allow isc_info_svc_to_eof be used for sending binary stream to service

> > It's clear that choice to use isc_info_svc_line to mark chunk of stdin sent > > to > service via SPB was not wise choice (to say it mildly). Both > isc_info_svc_to_eof and isc_info_svc_line are normally used for service > output (query items) and they were created just for that purpose. > >

Re: [Firebird-devel] [FB-Tracker] Commented: (CORE-5631) Allow isc_info_svc_to_eof be used for sending binary stream to service

> > A general question about the idea of "streaming" fbk file to a remote > server for restore. > > > > There would need to be a proper protocol to handle the stream, no? > > > > It would be impossible to send the fbk in a single operation, so sending the > fbk in blocks would be required. > >

Re: [Firebird-devel] Lateral derived tables (was: Plans to support cross and outer apply)

Dmitry, > Opinions, please. > > My personal votes: 1d, 2c, 3a, 4b For myself: 1d, 2c, 3a or 3b, 4b -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org!

Re: [Firebird-devel] block size exceeds implementation restriction at JStatement::openCursor

>> Here's the plan: >> PLAN HASH (EMTD NATURAL, JOIN (SORT (DR DR NATURAL), EWR INDEX >> (IDX_EWR_SENT_A_TEMP))) > Post a tracker entry to have it fixed. Or create an index for joining. This suggests that the issue is JOINing based on a NATURAL scan of the related table. Correct? {Trying to

Re: [Firebird-devel] Support for timed-zones datatypes

> On 13/12/2017 15:20, Leyne, Sean wrote: > >> I must agree with Lester. Initially I want to only implement offsets, > >> but testing Oracle, PostgreSQL and reading the standard, I think > >> offsets are useless for almost everything. > > I don't agree,

Re: [Firebird-devel] Support for timed-zones datatypes

Lester > The problem I had in the past was with meetings being moved over a DST > boundary. And this was in a SINGLE timezone. The software was normalizing > everything to UTC time, so that it could be displayed in local time of the > client, but what was forgotten in the software was which

Re: [Firebird-devel] Support for timed-zones datatypes

> > Separately, consider that calendar applications exchange times using UTC > offset contexts not time zone/region names. Why? Local Timezone UTC > offsets and DST rules are *variable*, UTC offsets are not. > > It's stored normalized to UTC, but the point in also store the region or >

Re: [Firebird-devel] Support for timed-zones datatypes

> I must agree with Lester. Initially I want to only implement offsets, but > testing Oracle, PostgreSQL and reading the standard, I think offsets are > useless for almost everything. I don't agree, offsets are the appropriate for all but boundary cases that can be handled by appropriate

[Firebird-devel] Firebird v3.0.x support for External Functions plug-in

The Firebird v3.0.x release notes outlines that plug-ins support has been added, and mentions that it will be extended to supporting SP, Functions and Triggers. Was this ever implemented/completed? {The Prague 2014 Firebird Conference had a "What's new in Firebird 3" presentation that listed

Re: [Firebird-devel] Virtual table for time zones

Adriano, > I want to create a virtual table that lists available time zones. > > For now there is RDB$ (non-virtual), MON$ (virtual, but all about monitoring), > SEC$ (security plugin). > > What prefix should TIME_ZONES have? My feeling is to use the RDB$ prefix. Q's: How will the data be

<    1   2   3   4   >