View Issue Details

IDProjectCategoryView StatusLast Update
0033737FPCDatabasepublic2019-09-08 12:15
ReporterLuca OlivettiAssigned ToMichael Van Canneyt 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.0.4Product Build 
Target VersionFixed in Version3.3.1 
Summary0033737: TPQConnection.Close(true) doesn't work if connection to server is severed
DescriptionWith the parameter ForceClose:=true Close should ignore errors while closing the connection, but in case of a TPQConnection (postgresql server) it raises an exception so it's impossible to reopen the connection.
Steps To Reproduce1) Create a table test in a postgresql database
create table test(c1 integer, c2 integer);
insert into test values (1,2);
insert into test values (3,4);

2) In the attached lazarus project adjust the parameters of the PQConnection1 component in order to connect to the postgresql server

3) Press the BtRefresh button to refresh the table

4) stop and restart the postgresql server

5) Now pressing the BtRefresh fails (as expected)

6) The BtReconnect button should close and reopen the connection but it raises an exception instead.

Project project1 raised exception class 'EPQDatabaseError' with message:
PQConnection1: connection pointer is NULL
(PostgreSQL:)

In file 'fcl-db/src/sqldb/postgres/pqconnection.pp' ad line 725:
raise E;
Additional InformationI tested both under win32 and linux64/qt (I don't think it's relevant).

See the mailing list thread starting here:
http://lists.lazarus-ide.org/pipermail/lazarus/2018-May/234734.html
TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget3.2.0
Attached Files

Relationships

related to 0035246 resolvedMichael Van Canneyt error on destroy transaction and connection 

Activities

Luca Olivetti

2018-05-15 21:44

reporter  

testsqldb.zip (2,682 bytes)

LacaK

2018-05-16 07:35

developer   ~0108328

Probably in TDatabase.CloseDataSets change:

    For I:=FDatasets.Count-1 downto 0 do
      TDataset(FDatasets[i]).Close;

to:

    For I:=FDatasets.Count-1 downto 0 do
      try
        TDataset(FDatasets[i]).Close;
      except
        if not ForcedClose then
          Raise;
      end;

like it is handled in TDatabase.CloseTransactions;

Luca Olivetti

2018-05-16 09:10

reporter   ~0108333

The same must be done in sqldb.pas, TSQLConnection.DoInternalDisconnect but it's still not enough: for some reason that I didn't trace yet, the query keeps the statement(s) as prepared, so in the line SQLQuery1.open it still fails because it is trying to execute a prepared query that doesn't exist in the new connection.

Luca Olivetti

2018-05-16 09:25

reporter   ~0108334

None of the above modification is necessary, it's enough to not raise an exception in TPQConnection.CheckResultError if ForcedClose is true, e.g. instead of

raise E;

do

if not ForcedClose then
  raise E;


but it seems it's causing some memory leak (I'm checking it now)

Luca Olivetti

2018-05-16 09:37

reporter   ~0108335

OK, the leak is because the exception isn't freed. It could either be freed in the else or a "if ForcedClose then exit" could be put right at the beginning of the procedure.

Luca Olivetti

2018-05-18 15:58

reporter   ~0108412

I give up, I cannot find a way of properly close the connection: the first error in CheckResultError will call ReleaseConnection, but that same PGConn will be used later in, at least, TPQConnection.Rollback and UnPrepareStatement, causing a SIGSEV.
If I protect those two methods with "if ForcedClose then exit", the SIGSEV appears later when reopening the connection (again, because it's using the same PGConn that was released previously).
The above happens if I restart the server between a call to Post/Applyupdates and a call to CommitRetaining (and do a Close(true) as a reaction to the generated exception in CommitRetaining). It doesn't happen if the exception happens in Post.
I think I'll simply halt the main program in case of a failure and have an auxiliary program restart it.

Michael Van Canneyt

2019-09-08 12:15

administrator   ~0117987

Fixed, please test and close if OK

Issue History

Date Modified Username Field Change
2018-05-15 21:44 Luca Olivetti New Issue
2018-05-15 21:44 Luca Olivetti File Added: testsqldb.zip
2018-05-16 07:35 LacaK Note Added: 0108328
2018-05-16 09:10 Luca Olivetti Note Added: 0108333
2018-05-16 09:25 Luca Olivetti Note Added: 0108334
2018-05-16 09:37 Luca Olivetti Note Added: 0108335
2018-05-16 23:39 Michael Van Canneyt Assigned To => Michael Van Canneyt
2018-05-16 23:39 Michael Van Canneyt Status new => assigned
2018-05-18 15:58 Luca Olivetti Note Added: 0108412
2019-09-08 12:14 Michael Van Canneyt Relationship added related to 0035246
2019-09-08 12:15 Michael Van Canneyt Status assigned => resolved
2019-09-08 12:15 Michael Van Canneyt Resolution open => fixed
2019-09-08 12:15 Michael Van Canneyt Fixed in Version => 3.3.1
2019-09-08 12:15 Michael Van Canneyt FPCTarget => 3.2.0
2019-09-08 12:15 Michael Van Canneyt Note Added: 0117987