Re: [Firebird-devel] RFC: Timeouts

Hi, that's very neat idea. +1 best regards Pavel Cisar IBPhoenix Dne 18.8.2016 v 12:04 liviuslivius napsal(a): > 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? >

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 timeout set by DBA usually measured in

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

.@Dmitry. look at this like extension to feature. DBA set some timeout settings but developer can write those kind of trigger and take decision kill or cancell kill. @Vlad maybe inside trigger you can run command like:CANCEL_KILLREPEAT_AFTER time this is only proposition implementation

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 18:59, Dmitry Yemanov wrote: > Prevent production server from being unexpectedly overloaded *before* > DBA can analyse such cases and take actions to avoid them. Typical cases: > > - possibly heavy ad-hoc queries parallel to fast well-tuned ones > - unlucky database/application upgrade

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 20:12, Dimitry Sibiryakov wrote: > > May be there are simpler and safer solutions for these problems? I doubt that. > How about How about an optimizer mistake (yes, this is possible even in MSSQL and Oracle) that causes a bad access path being chosen? Don't substitute one issue

[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. Smart DBA should set

Re: [Firebird-devel] RFC: Timeouts

W dniu 2016-08-18 10:01:17 użytkownik Molnár Attila napisał: > Hi! > > I think timeout should depend on these independent factors : > - transaction parameters : RORC = false else true why do you need to take different action for readonly transaction? If statement consume to

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

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 different state that can be distinguished from

Re: [Firebird-devel] RFC: Timeouts

W dniu 2016-08-18 09:26:22 użytkownik Vlad Khorsun napisał: > 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

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 10:37, liviuslivius wrote: > > > W dniu 2016-08-18 09:26:22 użytkownik Vlad Khorsun > napisał: >> 18.08.2016 10:08, liviuslivius пишет: >>> Hi Vlad, >>> > I.e interactive Delphi application that fetch only really shown records > will get error > when

Re: [Firebird-devel] RFC: Timeouts

> > Query timeout is good for queries that consume CPU resources and not > > finished in limited time. > >CPU is important but not the only resource. Yes, i know - time cost to take action as a whole like cpu + I/O + sync should cause timeout - statement as a whole > > > But queries that

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 8:47, Vlad Khorsun wrote: >What about 2500 ms ? :) > If user fetch one record per hour - yes, 2500 ms is much less that an hour, you know... > such application should be better rewritten It will require to implement background fetch. Much out of skills for most Delphi

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

[Firebird-devel] [FB-Tracker] Created: (CORE-5332) libfbclient.so ANDROID ARM64

libfbclient.so ANDROID ARM64 Key: CORE-5332 URL: http://tracker.firebirdsql.org/browse/CORE-5332 Project: Firebird Core Issue Type: New Feature Components: API / Client Library Reporter:

Re: [Firebird-devel] RFC: Timeouts

Hi! I think timeout should depend on these independent factors : - transaction parameters : RORC = false else true - first fetch : not possible at the timeout moment = true else false - average fetch time (start to measure after the first fetch) : very high (config) = true else fales and

Re: [Firebird-devel] RFC: Timeouts

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... Kiling statement or transaction is not good as a general solution It must be customized for

[Firebird-devel] [FB-Tracker] Created: (CORE-5333) Mismatch in null flag

Mismatch in null flag - Key: CORE-5333 URL: http://tracker.firebirdsql.org/browse/CORE-5333 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0.0 Environment: windows

Re: [Firebird-devel] RFC: Timeouts

This is a GREAT idea! +1 And you might define the timeout in the CREATE/ALTER command (no need for config). On 2016.08.18. 12:04, liviuslivius wrote: > Kiling statement or transaction is not good as a general solution > It must be customized for situations. > > I suppose better feature will be

Re: [Firebird-devel] RFC: Timeouts

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 timeout set by DBA usually measured in tens of minutes or in hours. Could you provide an

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 queries >> got crazy) and so on. It

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 13:04, liviuslivius wrote: > > I suppose better feature will be "timeout messaging" - something like > TRIGGER ON STATEMENT_TIMEOUT > TRIGGER ON TRANSACTION_TIMEOUT Triggers are for developers. Asking DBAs to create special triggers is a bad idea. Dmitry

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 18:51, Dimitry Sibiryakov wrote: > >On the other hand it provides DBA a choice, not kill the query > unconditionally. >You are not going to make an option "log, but do not kill", are you?.. Logging slow queries is a completely different topic and it's already covered by

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 17:54, Dmitry Yemanov wrote: > Logging slow queries is a completely different topic and it's already > covered by trace/audit. Ok but then what is a _real_ problem that subj is supposed to _solve_? PS: Was query cancellation stress-tested enough to be considered safe and robust?

Re: [Firebird-devel] RFC: Timeouts

Dimitry Sibiryakov wrote Thu, 18 Aug 2016 16:41:23 +0300: > 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

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 > queries > got crazy) and so on. It is *last* line, therefore it should be used with >

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 17:26, Vlad Khorsun wrote: >>What can be an advantage of this feature over cron-ed script chat check >> monitoring >> > tables and send DBA mail with list of bad queries? > - no need to create such script > - no need to create such script for every database > - no need to check

Re: [Firebird-devel] RFC: Timeouts

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 some > queries > got crazy) and so on. It is *last* line, therefore it should be used with

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

On 08/18/2016 06:26 PM, Vlad Khorsun wrote: > 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

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 >> some queries >> got crazy)

Re: [Firebird-devel] RFC: Timeouts

18.08.2016 19:01, Dimitry Sibiryakov wrote: > > Ok but then what is a _real_ problem that subj is supposed to _solve_? Prevent production server from being unexpectedly overloaded *before* DBA can analyse such cases and take actions to avoid them. Typical cases: - possibly heavy ad-hoc queries