View Issue Details

IDProjectCategoryView StatusLast Update
0033737FPCDatabasepublic2019-09-08 12:15
ReporterLuca Olivetti Assigned ToMichael Van Canneyt  
Status resolvedResolutionfixed 
Product Version3.0.4 
Fixed 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

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:
TagsNo tags attached.
Fixed in Revision
Attached Files


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


Luca Olivetti

2018-05-15 21:44

reporter (2,682 bytes)


2018-05-16 07:35

developer   ~0108328

Probably in TDatabase.CloseDataSets change:

    For I:=FDatasets.Count-1 downto 0 do


    For I:=FDatasets.Count-1 downto 0 do
        if not ForcedClose then

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


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