Bug into RestoreProgressEventArgs class - PgSqlDump problems

Discussion of open issues, suggestions and bugs regarding ADO.NET provider for PostgreSQL
Post Reply
Feneck91
Posts: 49
Joined: Mon 12 Aug 2013 13:52

Bug into RestoreProgressEventArgs class - PgSqlDump problems

Post by Feneck91 » Thu 14 May 2020 09:56

Hello to everybody.

As I indicate into this post 2.5 years ago, there are some problems with RestoreProgressEventArgs when a database is restored.

I suggest changing Offset and Length properties of the RestoreProgressEventArgs class from Int32(int) to Int64 (long) : It has been done by your developers team.
Do you test it on big database restauration ? May be not.

Now, when restauring big database (21 Go of text dump for only a part of our database that I'll be need in the future) I have several problems :
  • The RestoreProgressEventArgs.Offset field grow up and when it become big, it goes back on small number, may be in internal code some interger (and not long) are used and there are overshoot.
  • When creating foreign keys on Table that contains millions of rows, I have this exception.
    Some sentences are in french : Image
Any ideas to make it work properly ? Or just it is impossible to restore database saved by the same tool?

Shalex
Site Admin
Posts: 9077
Joined: Thu 14 Aug 2008 12:44

Re: Bug into RestoreProgressEventArgs class - PgSqlDump problems

Post by Shalex » Wed 03 Jun 2020 16:52

Feneck91 wrote:
Thu 14 May 2020 09:56
The RestoreProgressEventArgs.Offset field grow up and when it become big, it goes back on small number, may be in internal code some interger (and not long) are used and there are overshoot.
If possible, please upload your test project with the dump for reproducing the problem to some file exchange server and send us download link.
Feneck91 wrote:
Thu 14 May 2020 09:56
When creating foreign keys on Table that contains millions of rows, I have this exception.
Try increasing the value of your Default Command Timeout connection string parameter. 0 indicates no limit.

There is a workaround for both issues: iterate through the collection PgSqlScript.Statements and execute statements one by one. A sample is available at https://www.devart.com/dotconnect/postg ... ments.html.

Feneck91
Posts: 49
Joined: Mon 12 Aug 2013 13:52

Re: Bug into RestoreProgressEventArgs class - PgSqlDump problems

Post by Feneck91 » Thu 04 Jun 2020 10:50

Hi Shalex,

I hope you are fine.

The database is very big and contains company secret's informations. I cannot give you the database.
Create one with lots of data with test project will take too much time to develop.

I think you should have big databases in your dev environment to test your drivers, isn't it?

I don't know how to help you more.
Any idea?

Stéphane.

Shalex
Site Admin
Posts: 9077
Joined: Thu 14 Aug 2008 12:44

Re: Bug into RestoreProgressEventArgs class - PgSqlDump problems

Post by Shalex » Fri 05 Jun 2020 21:18

Please iterate through the collection PgSqlScript.Statements and execute statements one by one: https://www.devart.com/dotconnect/postg ... ments.html.

We will try to reproduce the issue you have encountered and notify you about the result. There is no timeframe at the moment.

Feneck91
Posts: 49
Joined: Mon 12 Aug 2013 13:52

Re: Bug into RestoreProgressEventArgs class - PgSqlDump problems

Post by Feneck91 » Mon 17 Aug 2020 14:34

Any workaroud or fixes for these bugs ?

Thanks.

Feneck91
Posts: 49
Joined: Mon 12 Aug 2013 13:52

Re: Bug into RestoreProgressEventArgs class - PgSqlDump problems

Post by Feneck91 » Mon 14 Sep 2020 08:16

Up ! Please give a date to correct this problem ! Nobody use your database dump feature ?

Shalex
Site Admin
Posts: 9077
Joined: Thu 14 Aug 2008 12:44

Re: Bug into RestoreProgressEventArgs class - PgSqlDump problems

Post by Shalex » Thu 24 Sep 2020 15:36

The fix of the Int32(int) issue will not solve the "Server did not respond within the specified timeout interval." problem. The later one occurs when the server itself drops connection after some period of activity or when there are network problems.

PgSqlDump.Restore() doesn't include the failover logic because it has to work with the connection object that was provided to it only.

Why don't you want to iterate through the collection PgSqlScript.Statements and execute statements one by one? Refer to https://www.devart.com/dotconnect/postg ... ments.html. This approach allows you to implement your own failover mechanism. If pgStatement.Execute() fails within try...catch, you can reexecute the same statement with the new connection and move further.

Post Reply