Re: [Firebird-devel] Visual Studio version for v5

On Wed, Oct 27, 2021 at 5:01 PM Vlad Khorsun wrote: > > If yes for above question, would we create duplicate files as before? > >I see no problem with it. Especially if we'll support just two VS > versions. > > > Or is there a better way to make the same set of files easily > > usable both

Re: [Firebird-devel] Visual Studio version for v5

27.10.2021 21:48, Adriano dos Santos Fernandes wrote: Hi! Do we plan to update Visual Studio to 2019 for v5? I have no such a plan but see nothing wrong with it. If yes, will the VS 2017 build be still maintained? I suppose - yes. If yes for above question, would we create duplicate

[Firebird-devel] Visual Studio version for v5

Hi! Do we plan to update Visual Studio to 2019 for v5? If yes, will the VS 2017 build be still maintained? If yes for above question, would we create duplicate files as before? Or is there a better way to make the same set of files easily usable both in VS 2017 and 2019? For my builds in VS

Re: [Firebird-devel] Cascade replication

Pro Turm wrote 27.10.2021 14:46: And how about the following constellation: The same. You still create a single failure point at B. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

> > > How about the case A->B->C, and B fails? Will A be replicating directly > to C ? And how about the following constellation: A->B->C ...|->D ...|->F i.e. B was originally replicating to C, D, F simultaneously, before it failed. How could the replication from A to C, D, F

Re: [Firebird-devel] Cascade replication

Pro Turm wrote 27.10.2021 14:39: Which means cascading could be quite vulnerable. What is then the quickest possible way to connect A to C in the above case? Drop database C, recreate replica from scratch. > Restarting the servers: are there some performance issues expected due to

Re: [Firebird-devel] Cascade replication

> > > How about the case A->B->C, and B fails? Will A be replicating directly > to C ? > >No. > Which means cascading could be quite vulnerable. What is then the quickest possible way to connect A to C in the above case? > Restarting the servers: are there some performance issues expected

Re: [Firebird-devel] Cascade replication

Pro Turm wrote 27.10.2021 14:26: How about the case A->B->C, and B fails?  Will A be replicating directly to C ? No.  What does a switch from primary <-> replica mean? Only changing the configuration files? No, it is invoking "gfix" command with appropriate switches as described in

Re: [Firebird-devel] Cascade replication

> > > e.g. in A->B->C, when A fails to become B->C ? > >It is already B->C, there is nothing to do. How about the case A->B->C, and B fails? Will A be replicating directly to C ? > Further, is it possible and how that from A->B->C the following happens > A<-B->C ? > > Switch A from primary

Re: [Firebird-devel] Cascade replication

27.10.2021 14:52, Pro Turm wrote: Is it possible and how does a replica become primary at some point? It never does it by itself. Firebird provides replication, but high-availability cluster (which you're talking about) is way more than just replication. Custom automatization is required.

Re: [Firebird-devel] Cascade replication

Pro Turm wrote 27.10.2021 13:52: Is it possible and how does a replica become primary at some point? As usual, changing of the replica mode of the database (if necessary at all). Read readme.replication.txt in doc folder. e.g. in A->B->C, when A fails to become B->C ? It is already

Re: [Firebird-devel] Cascade replication

Is it possible and how does a replica become primary at some point? e.g. in A->B->C, when A fails to become B->C ? Further, is it possible and how that from A->B->C the following happens A<-B->C ? Am Mi., 27. Okt. 2021 um 11:31 Uhr schrieb Dimitry Sibiryakov < s...@ibphoenix.com>: > Dmitry

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

On 2021-10-27 09:55, Dmitry Yemanov wrote: 23.10.2021 17:13, Mark Rotteveel wrote: If record buffering is hard, it could have been done **without** it. Then it would have been the choice of the user whether it is worth the performance implications or not. So you consider acceptable that

Re: [Firebird-devel] Cascade replication

Dmitry Yemanov wrote 27.10.2021 9:18: Nope, it's configured on the replica side and allows the received changes to be propagated further (if replica is also configured as a primary, i.e. A->B->C). ...and must be disabled for replication A->B->A i.e. bidirectional to prevent infinite data

Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors

23.10.2021 17:13, Mark Rotteveel wrote: If record buffering is hard, it could have been done **without** it. Then it would have been the choice of the user whether it is worth the performance implications or not. So you consider acceptable that forward-only usage of scrollable cursors is

[Firebird-devel] ODP: Cascade replication

Now it have more sense, thx regards, Karol Bieniaszewski Od: Dmitry Yemanov Wysłano: środa, 27 października 2021 09:18 Do: For discussion among Firebird Developers Temat: Re: [Firebird-devel] Cascade replication 27.10.2021 09:06, Karol Bieniaszewski wrote: > > Can you point me > >

Re: [Firebird-devel] Cascade replication

27.10.2021 09:06, Karol Bieniaszewski wrote: Can you point me https://github.com/FirebirdSQL/firebird/commit/e6a33454e871b9f9a368ccf281081e867c2b18cf what is enabled here and on which side? If i

[Firebird-devel] Cascade replication

Hi Can you point me https://github.com/FirebirdSQL/firebird/commit/e6a33454e871b9f9a368ccf281081e867c2b18cf what is enabled here and on which side? If i understand correctly it is configured on primary database side not on replica? If yes, why it is needed? Why not „simple” configure another