[Firebird-devel] Coalesce of the damned
Hello, I'm toying since a week with a slight simplification of core-4959 in FB 2.5: isql -user sysdba -pass masterkey create database 'coalesce.fdb'; set list on; create view v3(f1, f2) as select coalesce(rdb$relation_id, 111), coalesce(null, rdb$relation_id) from rdb$database; select * from v3; /* F1 130 F2 130 /* create view v4(f1, f2) as select coalesce(rdb$relation_id, 111), coalesce(5, 5) from rdb$database; select * from v4; /* F1 130 F2 5 */ So far so good. Now: select v3.* from rdb$database left join v3 on 1=0; /* F1 111 ? F2 */ select v4.* from rdb$database left join v4 on 1=0; /* F1 111 ? F2 */ The only wrong case that can be detected is A left join B with coalesce(B.field, constant) when B doesn't have a matching record. It means for that rpb: record->rec_format == NULL && record->rec_fmt_bk != NULL The "problem" here is case nod_missing inside EVL_boolean because it clears the null indicator. When B.field is evaluated to null, nod_missing does request->req_flags &= ~req_null; and the rest is history. Because the second param of coalesce is a constant, the null flag remains inactive and we see 111 in the output instead of null. But it also can happens with expressions: create view v5(f1, f2) as select coalesce(null, current_time), coalesce(rdb$relation_id, current_time - current_time) from rdb$database; select * from v5; /* F1 04:01:38. F2 134. */ select v5.* from rdb$database left join v5 on 1=0; /* F1 F2 0. ? */ My wish for FB v4 is that we stop using nod_value_if for coalesce (and for the CASE statement) and instead we implement a new verb. Among other things, it will avoid reevaluating expressions and will give us more freedom to fix things. C. --- Claudio Valderrama C. Consultant, SW developer. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Bug in interface.cpp init method
On 10/25/2015 03:46 PM, Mark Rotteveel wrote:
> I am looking at the init method in interface.cpp, and I see this:
>
> if (port->port_protocol < PROTOCOL_VERSION12)
> {
> // This is FB < 2.5. Lets remove that not recognized DPB/SPB and
> convert the UTF8
> // strings to the OS codepage.
> intlParametersBlock.fromUtf8(dpb, isc_dpb_utf8_filename);
> ISC_unescape(file_name);
> ISC_utf8ToSystem(file_name);
> }
>
> As this method is called for both database attach/create and service
> attach, shouldn't the "isc_dpb_utf8_filename" from
> "intlParametersBlock.fromUtf8(dpb, isc_dpb_utf8_filename);" be an
> spb/dpb independent reference (eg using the ParameterSet)? Or better
> yet: shouldn't this be handled in the implementation of IntlParametersBlock?
>
> Mark
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3.0 B2 (and lastsnapshot)fbclient.dll(Win32) slow unload?
On 10/26/2015 10:08 PM, Claudio Valderrama C. wrote: >> -Original Message- >> From: Arno Brinkman [mailto:fbsupp...@abvisie.nl] >> Sent: Lunes, 26 de Octubre de 2015 5:37 >> >> Would you consider the unloading time acceptable? >> I think 500ms is quite a lot. > Well, if you think about many clients connecting and disconnecting, it > becomes a problem. > >> Didn't dive into into Firebird source, may be i should see if >> i can setup >> everything to build Firebird again, but time. :-( > I think all the sync'ing logic is a topic that Alex can answer. That were Vlad's changes :) Telling true I do not completely understand why we can not use default linger leaving all job, related with connection shutdown, to operating system. Network disconnect in linux really became eye-visible slower, this is specially well noticeable when comparing embedded and network connections - embedded is closed at once, tcp - with visible delay (I think yes, about 500ms). The only thing I hope on is that this delays will not summarize when multiple clients disconnect from server - suppose they should go in parallel in different working threads. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3.0 B2 (and lastsnapshot)fbclient.dll(Win32) slow unload?
On 10/27/2015 11:12 AM, Alex Peshkoff wrote: > On 10/26/2015 10:08 PM, Claudio Valderrama C. wrote: >>> -Original Message- >>> From: Arno Brinkman [mailto:fbsupp...@abvisie.nl] >>> Sent: Lunes, 26 de Octubre de 2015 5:37 >>> >>> Would you consider the unloading time acceptable? >>> I think 500ms is quite a lot. >> Well, if you think about many clients connecting and disconnecting, it >> becomes a problem. >> >>> Didn't dive into into Firebird source, may be i should see if >>> i can setup >>> everything to build Firebird again, but time. :-( >> I think all the sync'ing logic is a topic that Alex can answer. > That were Vlad's changes :) Reviewing once again new fresh build I see no more delays. Sorry. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Coalesce of the damned
On 27/10/2015 05:21, Claudio Valderrama C. wrote: > > My wish for FB v4 is that we stop using nod_value_if for coalesce (and for > the CASE statement) and instead we implement a new verb. Among other things, > it will avoid reevaluating expressions and will give us more freedom to fix > things. > > That's not the problem with CORE-4959. v3 does uses blr_coalesce ;) The problem is that we can't go to evaluate blr_coalesce for a "null stream". Currently that can be done with blr_derived-expr but it's very invasive in the optimization process. I've sent for Dmitry's analysis an idea to use a kind of "runtime only" blr_derived_expr. Adriano -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3.0 B2 (and lastsnapshot)fbclient.dll(Win32) slow unload?
Hi, I'll try again with the latest snapshot build Regards, Arno -Oorspronkelijk bericht- From: Alex Peshkoff Sent: Tuesday, October 27, 2015 10:17 AM To: firebird-devel@lists.sourceforge.net Subject: Re: [Firebird-devel] Firebird 3.0 B2 (and lastsnapshot)fbclient.dll(Win32) slow unload? On 10/27/2015 11:12 AM, Alex Peshkoff wrote: > On 10/26/2015 10:08 PM, Claudio Valderrama C. wrote: >>> -Original Message- >>> From: Arno Brinkman [mailto:fbsupp...@abvisie.nl] >>> Sent: Lunes, 26 de Octubre de 2015 5:37 >>> >>> Would you consider the unloading time acceptable? >>> I think 500ms is quite a lot. >> Well, if you think about many clients connecting and disconnecting, it >> becomes a problem. >> >>> Didn't dive into into Firebird source, may be i should see if >>> i can setup >>> everything to build Firebird again, but time. :-( >> I think all the sync'ing logic is a topic that Alex can answer. > That were Vlad's changes :) Reviewing once again new fresh build I see no more delays. Sorry. -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4980) Operator REVOKE can modify rights granted to system tables at DB creation time
Operator REVOKE can modify rights granted to system tables at DB creation time -- Key: CORE-4980 URL: http://tracker.firebirdsql.org/browse/CORE-4980 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0 RC 1 Reporter: Alexander Peshkov Some forms of SQL operator REVOKE can trash access rights to system tables. For example: REVOKE ALL ON ALL FROM REVOKE ALL ON ALL FROM PUBLIC REVOKE SELECT ON RDB$RELATIONS FROM PUBLIC As a result it's very easy to have a database from which none can read (for example) list of tables. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
