[Firebird-devel] [FB-Tracker] Created: (CORE-5006) optimizer suggestion

optimizer suggestion Key: CORE-5006 URL: http://tracker.firebirdsql.org/browse/CORE-5006 Project: Firebird Core Issue Type: Improvement Components: Engine Affects Versions: 2.5.2 Update 1

Re: [Firebird-devel] FB3 Run-time Statistics in gbak Verbose Output and also Release Notes

> 10.11.2015 15:19, liviuslivius wrote: >> and also on page 110: >> "See also: Tracker ticket CORE-4919" - this tracker ticket have not >> correlation with subject >> I suppose that different number should be? >> regards, Wednesday, November 11, 2015, 2:34:20 AM, Vlad wrote: >Looks like

[Firebird-devel] ODP: Re: FB3 Run-time Statistics in gbak Verbose Output and also Release Notes

hi, for every line date time will be different.and this is very usefull. e.g. you run backup or restore every day and at some day you see that restoring some table take too much time compared to previous days. You need to know exact time when this happened and then you can go into server

Re: [Firebird-devel] ODP: Re: FB3 Run-time Statistics in gbak Verbose Output and also Release Notes

10.11.2015 20:15, liviuslivius wrote: > > for every line date time will be different. Date part will be the same, that was the Vlad's point. Redirect output to gbak-DDMM.log and look inside the log for the timings. Dmitry

Re: [Firebird-devel] FB3 Run-time Statistics in gbak Verbose Output and also Release Notes

10.11.2015 19:15, liviuslivius wrote: > hi, > > for every line date time will be different. Time portion will be mo-or-less different, but not a date portion. > and this is very usefull. e.g. you run backup or restore every day and at > some day you see that restoring some table take too

[Firebird-devel] ODP: Re: ODP: Re: FB3 Run-time Statistics in gbak Verbose Output and also Release Notes

but if you append info to same log file then will be good to see also date part. and as option why not let user decide? I like this feature in Interbase then why not in Firebird? regards,Karol Bieniaszewski Oryginalna wiadomość Od: Dmitry Yemanov

Re: [Firebird-devel] Pull request fixed (explained plan xml format)

Hi, i know that team is now very busy - today released RC1.. but i have 3 questions 1. I fix some output indentation and i have removed Index name quotation and i put patch file on own server http://itstop.pl/SVNFB/FB3.patch but is this good code formating and conversion? (changes in

Re: [Firebird-devel] Security problem with encrypted databases

10.11.2015 10:13, Alex Peshkoff wrote: > Does anybody see problems with suggested approach? It cannot detect partially written or physically corrupted page. -- WBR, SD. -- Firebird-Devel mailing list, web

Re: [Firebird-devel] Security problem with encrypted databases

10.11.2015 10:28, Alex Peshkoff wrote: > Agree, but it's not-related to the wrong/correct crypt key IMHO, one solution solving several problems at once is better that separate solutions for every single problem. -- WBR, SD.

[Firebird-devel] [FB-Tracker] Created: (CORE-5003) Implement pre-ODS 12 provider

Implement pre-ODS 12 provider - Key: CORE-5003 URL: http://tracker.firebirdsql.org/browse/CORE-5003 Project: Firebird Core Issue Type: Improvement Components: Engine Affects Versions: 3.0 RC 1

Re: [Firebird-devel] Encrypt some more

On 11/09/2015 08:05 PM, Dimitry Sibiryakov wrote: > 09.11.2015 18:00, Jim Starkey wrote: >> It matters because if every page is encrypted with the same key and >> initial state, information can be learned by building a table of first >> blocks. If two pages have the same encryption, then an

Re: [Firebird-devel] Security problem with encrypted databases

On 11/10/2015 12:20 PM, Dimitry Sibiryakov wrote: > 10.11.2015 10:13, Alex Peshkoff wrote: >> Does anybody see problems with suggested approach? > It cannot detect partially written or physically corrupted page. > Agree, but it's not-related to the wrong/correct crypt key

Re: [Firebird-devel] Security problem with encrypted databases

10.11.2015 10:31, Vlad Khorsun wrote: > b) questionable itself Ask DK for corruption statistics. If a page is corrupted, server may crash trying to parse it. To prevent that you'll have to put a lot of checks on every parsing step. IMHO, it is simpler and faster to check integrity of

Re: [Firebird-devel] Security problem with encrypted databases

10.11.2015 11:39, Dimitry Sibiryakov wrote: > 10.11.2015 10:31, Vlad Khorsun wrote: >> b) questionable itself > > Ask DK for corruption statistics. Good argument ! Note, it's up to you to proof your point :) > If a page is corrupted, server may crash trying to parse it. To prevent >

Re: [Firebird-devel] Security problem with encrypted databases

On 11/09/2015 11:08 PM, Roman Simakov wrote: > Key correctness can be checked by engine via crypto-plugin... Does anybody see problems with suggested approach? If not - I will add a ticket to the tracker for myself. --

Re: [Firebird-devel] Encrypt some more

10.11.2015 9:57, Alex Peshkoff wrote: > In that case encrypting something from page header seems to be bad idea. For encryption algorithms that are vulnerable to known-plaintext attack - yes. Fortunately, AES is not one of them. -- WBR, SD.

Re: [Firebird-devel] Security problem with encrypted databases

10.11.2015 11:20, Dimitry Sibiryakov wrote: > 10.11.2015 10:13, Alex Peshkoff wrote: >> Does anybody see problems with suggested approach? > > It cannot detect partially written or physically corrupted page. > This task a) have no relation with encryption b) questionable itself Regards,

Re: [Firebird-devel] Pull request fixed (explained plan xml format)

Hi, Just my 2 cents: I can see the benefit of an XML output, but then i would not use underscores inside the tags and params. Also i would prefer using the base operation as tag and not everything capsulated inside Something like: RDB$RELATIONS

Re: [Firebird-devel] Pull request fixed (explained plan xml format)

I've been trying not to get involved in this question, but it's not working. JSON and XML are both complex formats that require formal parsers. JSON can use a built-in parse, but that doesn't mean that a parser isn't required. And one may reasonable argue than XML is more regular than JSON

Re: [Firebird-devel] Pull request fixed (explained plan xml format)

About the code style... You surely should not reinvent another style. It's very easy to see that things like else if (...) Is never used this way in Firebird code. Also, nobody write this kind of things "detailed_format==2" without spaces. Just a observation of 2 seconds in your code. Not of

Re: [Firebird-devel] New API and multiple connections

On 11/10/2015 01:41 PM, Dimitry Sibiryakov wrote: > Hello, All. > > Which code for establishing two connections is right? > > This one: > > IProvider* disp = master->getDispatcher(); > IAttachment* att1 = disp->attachDatabase(status, "DB1", 0, NULL); > IAttachment* att2 =

[Firebird-devel] New API and multiple connections

Hello, All. Which code for establishing two connections is right? This one: IProvider* disp = master->getDispatcher(); IAttachment* att1 = disp->attachDatabase(status, "DB1", 0, NULL); IAttachment* att2 = disp->attachDatabase(status, "DB2", 0, NULL); Or this one: IProvider* disp1

[Firebird-devel] [FB-Tracker] Created: (CORE-5004) Method to demand use out-of-process stadalone server ( or oppositely, embedded engine) in DPB or connection string

Method to demand use out-of-process stadalone server ( or oppositely, embedded engine) in DPB or connection string -- Key: CORE-5004 URL:

[Firebird-devel] [FB-Tracker] Created: (CORE-5005) GSTAT reports wrong values for some index attributes after DML with long-key-indexed field fails with "Maximum index level reached"

GSTAT reports wrong values for some index attributes after DML with long-key-indexed field fails with "Maximum index level reached" --- Key: CORE-5005

Re: [Firebird-devel] Pull request fixed (explained plan xml format)

11.11.2015 04:40, Adriano dos Santos Fernandes wrote: > About the code style... > > You surely should not reinvent another style. It's very easy to see that > things like > > else > if (...) > > Is never used this way in Firebird code. > > Also, nobody write this kind of things

[Firebird-devel] FB3 Run-time Statistics in gbak Verbose Output and also Release Notes

Hi,   I have read topic "Run-time Statistics in gbak Verbose Output"   and i see that there is not possibility to output date-time like below? gbak: 2015-11-10 14:15:59.123     and also on page 110: "See also: Tracker ticket CORE-4919" - this tracker ticket have not correlation with

Re: [Firebird-devel] FB3 Run-time Statistics in gbak Verbose Output and also Release Notes

10.11.2015 15:19, liviuslivius wrote: > Hi, > I have read topic "Run-time Statistics in gbak Verbose Output" > and i see that there is not possibility to output date-time like below? > gbak: 2015-11-10 14:15:59.123 No. It have no sense (as for me) to include the same info (date) into

Re: [Firebird-devel] Pull request fixed (explained plan xml format)

Huh? What are you blithering about? Is this about my paragraphing styke 30 years ago? Get a life. On Tuesday, November 10, 2015, Adriano dos Santos Fernandes < adrian...@gmail.com> wrote: > About the code style... > > You surely should not reinvent another style. It's very easy to see that >

Re: [Firebird-devel] Pull request fixed (explained plan xml format)

> I've been trying not to get involved in this question, but it's not working. > Generating XML with printf's is not a really good idea. Build of tree of XML > objects and serialize the sucker. Hand counting angle brackets if for the > birds. I didn’t look at the patch yet (now i did and