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

[Adriano dos Santos Fernandes]

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 in VS 2017 and 2019?
>
>It highly depends on what is "usable". I don't know about "better" way
> as current
> one satisfy my needs as active developer and I don't look for something
> else.
>
>
It's a PITA to add .cpp/.h files to one set of projects, and much more to
two sets.

And in the past, we always had versions with lagging changes.



> > For my builds in VS 2019, I set WindowsTargetPlatformVersion just
> to "10.0" instead of a specific point release. Maybe this also
> > works for VS 2017.
>
>There is no such setting in VS 2017. There is "TargetPlatform"
> (read-only) and
> "Windows SDK Version". The values of the latter one depends on "Platform
> Toolset".
>
>
I'm talking about the settings in the .vcxproj files.



> > For PlatformToolset, is there a way to set it to some value that gets
> the "default" (v141 for VS 2017, v142 for VS 2019)?
>
>There is a problem with "Windows SDK Version" value in VS 2017, as
> different
> developers could have installed different versions of SDK and VS 2017
> can't just
> use most\any "suitable". It was promised to be fixed in VS 2019. I didn't
> check it
> by myself.
>
>As for "PlatformToolset" - i don't know, but not see it as a problem if
> we support
> two set of project files.
>
>
I'm testing a solution and it seems possible to have both VS 2017 and 2019
working with the same set of files without one interfering with the other.
I will tell more about it after more tests.



> > I'm testing the creation of a docker image for Firebird build, and it
> seems impossible to create a scripted install using a specific
> > version of VS 2017. It always installs the latest version.
>
>Why it is a problem for us ?
>
>
As for me it's ok. But not everyone agrees and chooses and fixes a version
for releases. It's as the project always worked.



> > For VS 2019 it's possible to install any version downloading a specific
> vs_buildtools installer.
> >
> >
> > Adriano
> >
> > PS: Soon there will also be VS 2022...
>
>I hope we will release FB5 before VS 2022 became stable.
>
> It depends on what you define as stable. It's supposed to be GA in
November.


Adriano
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

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

[Vlad Khorsun]

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 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 in VS 2017 and 2019?


  It highly depends on what is "usable". I don't know about "better" way as 
current
one satisfy my needs as active developer and I don't look for something else.

For my builds in VS 2019, I set WindowsTargetPlatformVersion just to "10.0" instead of a specific point release. Maybe this also 
works for VS 2017.


  There is no such setting in VS 2017. There is "TargetPlatform" (read-only) and
"Windows SDK Version". The values of the latter one depends on "Platform 
Toolset".


For PlatformToolset, is there a way to set it to some value that gets the 
"default" (v141 for VS 2017, v142 for VS 2019)?


  There is a problem with "Windows SDK Version" value in VS 2017, as different
developers could have installed different versions of SDK and VS 2017 can't just
use most\any "suitable". It was promised to be fixed in VS 2019. I didn't check 
it
by myself.

  As for "PlatformToolset" - i don't know, but not see it as a problem if we 
support
two set of project files.

I'm testing the creation of a docker image for Firebird build, and it seems impossible to create a scripted install using a specific 
version of VS 2017. It always installs the latest version.


  Why it is a problem for us ?


For VS 2019 it's possible to install any version downloading a specific 
vs_buildtools installer.


Adriano

PS: Soon there will also be VS 2022...


  I hope we will release FB5 before VS 2022 became stable.

Regards,
Vlad


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Firebird-devel] Visual Studio version for v5

[Adriano dos Santos Fernandes]

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 2019, I set WindowsTargetPlatformVersion just to "10.0"
instead of a specific point release. Maybe this also works for VS 2017.

For PlatformToolset, is there a way to set it to some value that gets the
"default" (v141 for VS 2017, v142 for VS 2019)?

I'm testing the creation of a docker image for Firebird build, and it seems
impossible to create a scripted install using a specific version of VS
2017. It always installs the latest version.

For VS 2019 it's possible to install any version downloading a specific
vs_buildtools installer.


Adriano

PS: Soon there will also be VS 2022...
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

[Dimitry Sibiryakov]

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

[Pro Turm]

>
> > 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 simultaneously be
restored, i.e. is there any performance or other issues compared to the
case A->(B)->C ?


Am Mi., 27. Okt. 2021 um 14:39 Uhr schrieb Pro Turm :

> > 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 due
>> to
>> > restarting (looising data, long-time unavailability etc.) ?
>>
>>It depends.
>>
> Could you please elaborate more on that ?
>
> Am Mi., 27. Okt. 2021 um 14:33 Uhr schrieb Dimitry Sibiryakov <
> s...@ibphoenix.com>:
>
>> 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
>> README.replication.txt.
>>
>> > Restarting the servers: are there some performance issues expected due
>> to
>> > restarting (looising data, long-time unavailability etc.) ?
>>
>>It depends.
>>
>> --
>>WBR, SD.
>>
>>
>> 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

Re: [Firebird-devel] Cascade replication

[Dimitry Sibiryakov]

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 
> restarting (looising data, long-time unavailability etc.) ?


    It depends.

Could you please elaborate more on that ?


  Performance issues, data losses and recovery time highly depends on the 
nature of the disaster that has made the recovery needed, replication settings 
and other factors.


--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

[Pro Turm]

>
> > 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 due to
> > restarting (looising data, long-time unavailability etc.) ?
>
>It depends.
>
Could you please elaborate more on that ?

Am Mi., 27. Okt. 2021 um 14:33 Uhr schrieb Dimitry Sibiryakov <
s...@ibphoenix.com>:

> 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
> README.replication.txt.
>
> > Restarting the servers: are there some performance issues expected due
> to
> > restarting (looising data, long-time unavailability etc.) ?
>
>It depends.
>
> --
>WBR, SD.
>
>
> 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

Re: [Firebird-devel] Cascade replication

[Dimitry Sibiryakov]

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 
README.replication.txt.


Restarting the servers: are there some performance issues expected due to 
restarting (looising data, long-time unavailability etc.) ?


  It depends.

--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

[Pro Turm]

>
> > 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 mode to replica, switch B from replica mode to
> master,
> make corresponding changes in the configuration files, restart servers.
>
 What does a switch from primary <-> replica mean? Only changing the
configuration files?
Restarting the servers: are there some performance issues expected due to
restarting (looising data, long-time unavailability etc.) ?

Am Mi., 27. Okt. 2021 um 14:14 Uhr schrieb Dimitry Sibiryakov <
s...@ibphoenix.com>:

> 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 B->C, there is nothing to do.
>
> > Further, is it possible and how that from A->B->C the following happens
> A<-B->C ?
>
>Switch A from primary mode to replica, switch B from replica mode to
> master,
> make corresponding changes in the configuration files, restart servers.
>
>The main problem is in database and application design that has to be
> made
> with replication in mind at the beginning.
>
> --
>WBR, SD.
>
>
> 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

Re: [Firebird-devel] Cascade replication

[Dmitry Yemanov]

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.



e.g. in A->B->C, when A fails to become B->C ?


In read-only replica, this is impossible, as all changes are produced by 
A and the whole chain stops working without A.
In read-write replica, the B->C part will continue working without A 
automagically. But you need somehow to reconnect everybody from A to B 
(and make sure A never reappears).


Further, is it possible and how that from A->B->C the following happens  
A<-B->C ?


Impossible without manual DBA actions.


Dmitry


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

[Dimitry Sibiryakov]

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 B->C, there is nothing to do.


Further, is it possible and how that from A->B->C the following happens  
A<-B->C ?


  Switch A from primary mode to replica, switch B from replica mode to master, 
make corresponding changes in the configuration files, restart servers.


  The main problem is in database and application design that has to be made 
with replication in mind at the beginning.


--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

[Pro Turm]

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 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 bouncing.
>
> --
>WBR, SD.
>
>
> 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

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

[Mark Rotteveel]

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 forward-only usage of scrollable
cursors is 10x slower than for regular cursors? Personally, I consider
it hard to explain.


Yes, I think that is perfectly acceptable for an initial version. 
Scrollable cursors are a bit of an oddity anyway, but having scrollable 
cursors in embedded access, but not in remote access is IMHO less 
acceptable than bad performance. As long as the performance behaviour is 
clearly documented, people can make the decision if the bad performance 
is worth the utility of scrollable cursors for themselves.


Mark


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

[Dimitry Sibiryakov]

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 bouncing.


--
  WBR, SD.


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

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

[Dmitry Yemanov]

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 10x slower than for regular cursors? Personally, I consider it hard 
to explain.



Dmitry


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Firebird-devel] ODP: Cascade replication

[Karol Bieniaszewski]

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
> 
> 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?

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).


Dmitry


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

Re: [Firebird-devel] Cascade replication

[Dmitry Yemanov]

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 understand correctly it is configured on primary database side not 
on replica?


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).



Dmitry


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Firebird-devel] Cascade replication

[Karol Bieniaszewski]

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 replication on 
replica side? And anothere on another replica side... It is more natural.
But maybe i am wrong here, please explain more this option.

regards,
Karol Bieniaszewski

Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel