23.05.2018 15:59, Dimitry Sibiryakov wrote:
23.05.2018 14:40, Mark Rotteveel wrote:
I think it should unconditionally do a session reset on return to the pool if the protocol is v16 or higher (assuming v16 is the
Firebird 4 protocol version).
This is not truly unconditionally :)
But re
24.05.2018 0:39, Dimitry Sibiryakov wrote:
23.05.2018 21:18, Vlad Khorsun via Firebird-devel wrote:
At second, there is no way to upgrade server without breaking established
connection (obviously).
Nobody tell about it. And it change nothing.
Then could you, please, explain what
24.05.2018 11:35, Dimitry Sibiryakov wrote:
24.05.2018 1:08, Vlad Khorsun via Firebird-devel wrote:
24.05.2018 0:39, Dimitry Sibiryakov wrote:
What visible changes can happen after upgrade of server version?
We have local server v4 and remote server v3. v4 runs external statements
24.05.2018 12:06, Dimitry Sibiryakov wrote:
24.05.2018 10:50, Vlad Khorsun via Firebird-devel wrote:
From reading documentation I have a feeling that currently external connection is reused only within transaction. When local
transaction ends, connection is disconnected.
Yes, almost
24.05.2018 12:01, Mark Rotteveel wrote:
On 2018-05-24 01:08, Vlad Khorsun via Firebird-devel wrote:
24.05.2018 0:39, Dimitry Sibiryakov wrote:
So far we have following propositions:
1. Always reset external connection when it gets out of use. Close connection if
any kind of error happens
25.05.2018 16:40, Dimitry Sibiryakov пишет:
25.05.2018 15:28, Vlad Khorsun via Firebird-devel wrote:
We have local server v4 and remote server v3. v4 runs external statements
against v3
and remote sessions have some context that is re-used by remote statements
somehow.
Then remote server
25.05.2018 17:05, Dimitry Sibiryakov wrote:
25.05.2018 15:53, Vlad Khorsun via Firebird-devel wrote:
Remote statement could check some context variable and run this or that
branch
of code in dependence of variable value. Then it could assign another value to
this context variable. It all
25.05.2018 18:33, Dimitry Sibiryakov wrote:
25.05.2018 17:26, Vlad Khorsun via Firebird-devel wrote:
I.e. all works a bit slower than before v4.
I think that it can be a good motivation to upgrade remote server to v4.
Bad joke
All works much faster than before v4.
Do you have
23.05.2018 15:07, Adriano dos Santos Fernandes wrote:
On 23/05/2018 08:51, Vlad Khorsun via Firebird-devel wrote:
23.05.2018 13:40, Adriano dos Santos Fernandes wrote:
On 23/05/2018 06:48, Dimitry Sibiryakov wrote:
In this case I guess there must be two triggers: BEFORE RESET and
AFTER
All,
Some update on this topic
18.05.2018 19:44, Vlad Khorsun via Firebird-devel wrote:
All,
I going to merge into master implementation of pool of external connections.
The feature was initially developed more than a year ago, and works at
production
with good feedback
28.05.2018 15:57, Dimitry Sibiryakov wrote:
28.05.2018 14:13, Vlad Khorsun via Firebird-devel wrote:
- forcebly rollback active transactions and reset connection
same as if connection was broken
- raise error and don't reset connection.
Obviously, first case is not an option and we
28.05.2018 18:03, Dimitry Sibiryakov wrote:
28.05.2018 16:45, Vlad Khorsun via Firebird-devel wrote:
On one hand third option would be consistent with behavior of isc_detach_database() on client. On the other hand server cannot
handle such error and it will result in endless transaction with
29.05.2018 2:06, Adriano dos Santos Fernandes wrote:
On 28/05/2018 09:13, Vlad Khorsun via Firebird-devel wrote:
There is still no agreement. Current offers:
- single ON SESSION RESET trigger
- pair of new triggers: BEFORE SESSION RESET and AFTER SESSION RESET
- use existing ON CONNECT and
02.06.2018 18:07, Mark Rotteveel wrote:
I just saw the following commit:
https://github.com/FirebirdSQL/firebird/commit/bbf8348817c4592999fc137b18ba1be7326ad42d
This disallows execution of ALTER SESSION RESET if there are transactions
active. I think this is too restrictive.
Only from clie
02.06.2018 19:54, Mark Rotteveel wrote:
On 2-6-2018 17:56, Vlad Khorsun via Firebird-devel wrote:
02.06.2018 18:07, Mark Rotteveel wrote:
I just saw the following commit:
https://github.com/FirebirdSQL/firebird/commit/bbf8348817c4592999fc137b18ba1be7326ad42d
This disallows execution of ALTER
All,
I have a questions about error handling after TRANSACTION START trigger and
I want to clear my doubts or fix the bug (if confirmed).
From README.db_triggers.txt:
- TRANSACTION START
Triggers are fired in the newly user created transaction - uncaught
exceptions are returned to
08.06.2018 12:16, Dimitry Sibiryakov wrote:
08.06.2018 11:01, Vlad Khorsun via Firebird-devel wrote:
Another question is how to handle rollback error. I mean rollback that run
at catch block. I offer to ignore rollback error (maybe log it into
firebird.log,
if database is not bug-checked
Mark, all
I just committed changes as we discussed above. I.e. session reset now ignores
prepared transactions, rollback currently active user transaction and start new
one, issue warning if user transaction made changes in tables.
Here is how it looks now:
SQL> alter session reset;
State
All,
I going to merge into master implementation of pool of external connections.
The feature was initially developed more than a year ago, and works at
production
with good feedback.
Some bugs was fixed since then, so it should be stable enough and definitely
good for beta release of
20.10.2020 13:43, Dmitry Yemanov wrote:
20.10.2020 13:40, Roman Simakov wrote:
Because documentantion here
(https://firebirdsql.org/en/firebird-date-literals/) says they are valid
separators.
Keep in mind, that link is an excerpt from Helen Borrie's Firebird Book
from 2004 (Firebird 1.5 era)
19.10.2020 12:42, marius adrian popa wrote:
From pg release notes
https://www.postgresql.org/about/news/postgresql-13-released-2077/
https://www.postgresql.org/docs/13/btree-implementation.html#BTREE-DEDUPLICATION
ps: I don't know if Firebird can be optimized in a similar
AFAIU, PG tried to
101 - 121 of 121 matches
Mail list logo
