On 19/02/2019 13:56, Vlad Khorsun wrote:
>
> As i understand you - it doen't break anything. For me, it is safe to
> assign
> to the new snapshot (CONCURRENCY) transaction number of already existing
> and
> still alive snapshot. It is very important to ensure existence of that
> snapshot
> numb
isql query fails to return correct result
-
Key: CORE-6008
URL: http://tracker.firebirdsql.org/browse/CORE-6008
Project: Firebird Core
Issue Type: Bug
Environment: ISQL Version: LI-V2.5.7.2705
Hi,
Dne 21. 02. 19 v 11:15 Dimitry Sibiryakov napsal(a):
21.02.2019 10:46, Pavel Cisar wrote:
It's tempting, but I see potential for problems. If we would allow
multiple sets & filters at master node, there is no need to have them
at replica. And if replica would have different definitions tha
Ok, thank you
Regards,
Karol Bieniaszewski
Od: Dmitry Yemanov
Wysłano: czwartek, 21 lutego 2019 09:18
Do: For discussion among Firebird Developers
Temat: Re: [Firebird-devel] CORE-6005
21.02.2019 10:39, liviuslivius wrote:
>
> http://tracker.firebirdsql.org/browse/CORE-6005
> I do not talk about
Firebird does not build on Mac with fresh toolchain
---
Key: CORE-6007
URL: http://tracker.firebirdsql.org/browse/CORE-6007
Project: Firebird Core
Issue Type: Bug
Affects Versions: 4.0 Beta
21.02.2019 12:46, Pavel Cisar wrote:
And one partially related question from another angle: does it make
sense to implement also replica-side declarative filtering? I mean the
case where changes for all tables are journaled but for some reason
only some tables should be applied to replica - e
21.02.2019 10:46, Pavel Cisar wrote:
It's tempting, but I see potential for problems. If we would allow multiple sets & filters
at master node, there is no need to have them at replica. And if replica would have
different definitions than master, then it's not possible to replace master with rep
21.02.2019 9:14, Dmitry Yemanov wrote:
Second, IMHO declaring tables as "publishable" via CREATE|ALTER TABLE is too restrictive.
I'd rather manage the replication set using some global commands, be it ALTER DATABASE or
something different, allowing to include/exclude all tables at once, or comma
On 2/21/19 12:46 PM, Pavel Cisar wrote:
Second, IMHO declaring tables as "publishable" via CREATE|ALTER TABLE
is too restrictive. I'd rather manage the replication set using some
global commands, be it ALTER DATABASE or something different,
allowing to include/exclude all tables at once, or co
Hi,
Generally, I like the DDL approach more than using the configuration
file. Additional benefit to ones listed is possibility to create various
front-ends for replication configuration / integration of such
functionality into existing Firebird management tools.
Comments to specific questio
21.02.2019 10:39, liviuslivius wrote:
http://tracker.firebirdsql.org/browse/CORE-6005
I do not talk about problem itself but think about new feature.
Is this stable cursor a real cursor on which we can work and we can have
some system name for it?
No, it's just low-level visibility rules - wh
All,
In v4 Beta, replication is fully driven by the configuration file. In
particular, tables to be replicated are (optionally) defined using two
regexp-based options: include_filter and exclude_filter. This was the
easiest solution that doesn't require ODS changes and this matches the
trace/
12 matches
Mail list logo
