https://en.wikipedia.org/wiki/Multiversion_concurrency_control#History
-Eredeti üzenet-
Feladó: Pól Ua L. via Firebird-devel
[mailto:firebird-devel@lists.sourceforge.net]
Küldve: 2022. május 26., csütörtök 9:11
Címzett: For discussion among Firebird Developers
Másolatot kap: Pól Ua L.
"Tablespaces has meaning for large databases only that don't fit into single
storage (terrabytes)."
That is not true. It has meaning whatever the programmers meant to use it. It
might not be about read performance, but e.g. logical data serparation, backup
speedup, etc...
Also you should not ju
-Eredeti üzenet-
Feladó: Dimitry Sibiryakov [mailto:s...@ibphoenix.com]
Küldve: 2021. szeptember 1., szerda 11:27
Címzett: For discussion among Firebird Developers
Tárgy: Re: [Firebird-devel] Dialect 3 inconsistent round/trunc - configurable
calculation method needed
Molnár Attila wrote 01.09.2
eforge.net
Tárgy: Re: [Firebird-devel] Dialect 3 inconsistent round/trunc - configurable
calculation method needed
On 31-08-2021 16:19, Molnár Attila wrote:
> 127.13 / 3.4618 = 36,72366976717315
It isn't, taken literally in dialect 3, the result is 36,723669 ;).
> EXECUTE BLOCK
> R
orage)
- firebird.conf (don't prefer, this should be linked to the database
file)
- connection string (don't prefer, this should be linked to the
database file)
[cid:image002.png@01D79E83.EB3C4920]<http://www.libra.hu/>
CÉGÜNK A LIBRA CSOPORT TAGJA
Molnár Attila
fejleszt
In my point of view (not a native english speaker)
owner : ownership is a legal term basicly. It gives the owner rights over the
owned property.
master : master has actual power over the slave to command/control the slave.
-Eredeti üzenet-
Feladó: Dimitry Sibiryakov [mailto:s...@ibph
You can posrt the difference between new ICU versoins in firebirdsql.org to
help developers/users/admins to decide wheter an update nedded at all.
-Eredeti üzenet-
Feladó: Paul Reeves [mailto:pree...@mail.ibphoenix.com]
Küldve: 2020. április 29., szerda 13:38
Címzett: firebird-devel@list
Firebird UPDATE supports ORDER BY clause.
Feladó: marius adrian popa [mailto:map...@gmail.com]
Küldve: 2019. november 19., kedd 10:48
Címzett: For discussion among Firebird Developers
Tárgy: [Firebird-devel] interesting test fails with Firebird 3.0
https://twitter.com/FranckPachot/status/119641
BTW I also agree that this shoud throw FK voilation exception on detail insert.
-Eredeti üzenet-
Feladó: Carlos H. Cantu [mailto:lis...@warmboot.com.br]
Küldve: 2019. szeptember 6., péntek 14:13
Címzett: For discussion among Firebird Developers
Tárgy: Re: [Firebird-devel] Inserts and F
Why do you insert master and detail record in separate transaction?
If you do master and detail in separate transaction then tx2 should not be
started before tx1, tx2 start MUST wait for tx1 SUCCESSFUL commit, otherwise
your business logis FLAWED.
This scenario is looks like "Dirty read" :
http
This might be a GC/sweep issue
http://tracker.firebirdsql.org/browse/CORE-4751
http://tracker.firebirdsql.org/browse/CORE-4745
On 2017.12.07 16:35, Vlad Khorsun via Firebird-devel wrote:
07.12.2017 17:16, Jiří Činčura wrote:
Nope. Still happening. Even with `-i`.
Hmm... i was not attenti
Awesome! :)
On 2017.04.21. 1:30, Adriano dos Santos Fernandes wrote:
> Em 20/04/2017 17:53, Vlad Khorsun escreveu:
>> Also it is necessary
>> to teach engine to use that metadata (instead of current one) within
>> attachment
>> working "in the past".
>>
> I'm doing a prototype implementation of t
+1 for this feature. I would be very happy for this. Also it would be
awesmone if this consistent view were accessible later in time (this
woudl mean garbage collection blocking).
On 2017.04.18. 20:56, Leyne, Sean wrote:
>
>> If you need simultaneous queries - make them possible,
>> what the poi
Hi!
I expect form the FB engine to return the default value at INSERT/UPDATE
TIME, not the current default value. So default values should be kept in
the rdb$format table, because versioning is needed.
On 2017.03.24. 8:18, Dmitry Yemanov wrote:
> 24.03.2017 09:33, Vlad Khorsun wrote:
>>> Firebi
Don't forget about SAVEPOINT handling! It can make things very messy in
this case (BUT expected to work as part of the transaction logic from my
point of view).
Lock should be applied in case of altering, parallel altering should be
not allowed. (same as update a record, instant lock conflict er
Yes, this is correct. SQL specification defines this behaviour.
On 2016.12.07. 14:24, Slavomir Skopalik wrote:
> Hi,
>
> is it correct that empty string '' in comparison with one space string '
> ' is evaluated as true?
>
> SELECT * FROM rdb$database WHERE ''=' '
>
> FB 2.5.6, database dialect 1
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 "
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 optiona
On 2016.04.09. 20:25, Ann Harrison
wrote:
On Fri, Apr 8, 2016 at 5:54 AM,
Molnár Attila <amol...@mve.hu>
wrote:
Optimiz
Hi Dmitry!
Hope never dies. I prefer optimizations over the other new features. ;)
Thanks for the reply.
On 2016.04.08. 12:30, Dmitry Yemanov wrote:
> 08.04.2016 12:54, Molnár Attila wrote:
>> Here is my list.
> List of v4 features is already composed. We may add some more
> im
istinct values from table. (currently you
have to keep a separate table with this information because you
can't access to this information fast)
Thank You!
--
Molnár Attila
szoftverfejlesztő
Libra Szoftver Zrt.
1113 Budapest, Karolina út 65.
Tel.: +36 1 255 3939
The goal is to send notification from one connection to other
connection(s) without roundrip to client using current event
mechanism.
On 2015.02.26. 15:56, James Starkey
wrote:
Could you describe what you are actually trying to do
rather than how a p
It sounds very strange, but hoping so. And WOW!
Also hope IBX also unaffected then...
On 2015.01.15. 15:07, Paul Beach wrote:
> < old), or this will break the old API?>>
>
> The API is completely unaffected by the support for 64bit transaction ids.
>
> Regards
> Paul
>
> -
Hi!
Old 32bit Tx API will be unchanged (new 64bit Tx API existst beside the
old), or this will break the old API?
On 2015.01.15. 9:17, Dmitry Yemanov wrote:
> 12.01.2015 23:22, liviusliv...@poczta.onet.pl wrote:
>> is somewhere some list of changes in this or can someone say something
>> in thi
Hello all!
Have a look at ScaleMM.
It has great multithreaded performance, AND low fragmentation rate.
https://code.google.com/p/scalemm/
You should consider rewrite it to C++.
On 2014.09.20. 23:57, Jim Starkey wrote:
> Memory management is perhaps the single most performance part of a
> databa
So this Interface is not designed and made for clinet component
developers and communicatin with server but just for Firebird engine
inside use?
In that case just do what you want. ;)
On 2014.08.11. 11:05, Dimitry Sibiryakov wrote:
> Remember, that new API wasn't designed as a public API. It w
1. 10:49, Molnár Attila
wrote:
Lets see the next scenatios
#1 : API call creates object and returned to host
- in this case object has to be readonly (at least buffer like
fields)1
- host has to support reference coun
Lets see the next scenatios
#1 : API call creates object and returned to host
- in this case object has to be readonly (at least buffer like
fields)1
- host has to support reference counting2
#2 : API call parameterised by a host created object
- better multithread scalability
- make place for future FB developements
- make place for supporting missing SQL standard features
--
Molnár Attila
szoftverfejlesztő
Tel : 372-
E-mail: amol...@mve.hu
LIBRA Szoftver zrt.
1113 Bp. Karolina út 65.
Tel: 372-
Fax: 209-
E.g. our application still in dialect 1. It would be a huge job to
switch dialect 3.
On 2014.05.23. 8:41, Martijn Tonies (Upscene Productions) wrote:
- Any other suggestion?
>>> Drop dialect 1 support.
>>Allow dialect 1 to have access to BIGINT fields.
> I don't have to work for this to
conversations must be used heavly. With VARIANT the code
become cleaner and could avoid conversations.
new context variable access method in PSQL with variant support would be
great also
On 2014.05.10. 16:43, Adriano dos Santos Fernandes wrote:
> On 10-05-2014 04:03, Molnár Attila wr
Derived table usage for this problem is GREAT idea! Why the ... I didn't
tought that!
Thank you!
On 2014.05.10. 10:26, Dimitry Sibiryakov wrote:
> 10.05.2014 10:12, Molnár Attila wrote:
>> OK, this just means smaller treshold rate. But with this some case you
>> can gain HU
On 2014.05.10. 9:52, Dimitry Sibiryakov wrote:
> 10.05.2014 9:03, Molnár Attila wrote:
>> *VARIANT data type in PSQL*
>> - gain : a little memory and/or CPU overhead but much cleaner code.
>> Also
>> rdb$get/set_context value colud be variant.
> Welcom
n the order/group columns
then fetching on the temporal index. In this way much less writes
needed. This shold be applied after a treshold : common sense sais
after index size/row size rate is smaller than 0.5.
--
Molnár Attila
szoftverfejlesztő
Tel : 372-
E-mail: amol...@m
On 2014.05.05. 9:27, Dmitry Yemanov wrote:
> 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 he
Hello Dmitry!
On 2014.05.02. 8:34, Dmitry Yemanov wrote:
> 30.04.2014 13:50, Molnár Attila wrote:
>> *SIZE OF , SCALE OF > domain or variable name>*
>> - SIZE OF : returns max CHAR/VARCHAR length or NUMERIC precision,
>> SCALE OF : return scale of NUMERIC
>
Hello Sean!
On 2014.05.01. 21:24, Leyne, Sean wrote:
>> TRIGGER : NEW/OLD values accessible by column name, and column number
>> (PSQL)
>> - e.g.: NEW['id'], NEW[0]
>> - gain : code reduction, dynamic code (don't have to alter the trigger
>> ICO
>> the table structure altered)
> 1- What
wed, but execute block can't
replace the procedure in this case)
Thank You!
--
Molnár Attila
szoftverfejlesztő
Tel : 372-
E-mail: amol...@mve.hu
LIBRA Szoftver zrt.
1113 Bp. Karolina út 65.
Tel: 372-
Fax: 209-1477
Web: www.mve.hu
E-mail: i...@mve.hu
Olvasson üg
38 matches
Mail list logo