postgres database lock cancelling on closing gnucash

[John Ralls]

On Nov 26, 2010, at 6:23 AM, Johann Wöckinger wrote:

> Hi,
> 
> here are the answers:
> 
> I connect to a local postgres-database and I use linux (debian squeeze). I use the hostname in the connectstring (not "localhost").
> Here are the process id observations:
> 
> after start of gnucash until pop-up with lock-message appears:
> 30525 ?        SLl    0:04 gnucash
> 30540 ?        Ss     0:00 postgres: hans gnucash 192.168.129.8(36175) idle
> 
> after selecting open though and gnucash up and running with active database connection:
> 30525 ?        SLl    0:06 gnucash
> 30540 ?        Ss     0:00 postgres: hans gnucash 192.168.129.8(36175) idle
> 31429 ?        Ss     0:00 postgres: hans gnucash 192.168.129.8(47428) idle
> 
> in gnclock, the pid-entry is pid 30525
> entry in gnclock not deleted on closing gnucash (checked by inspecting the database-entry)
> 
> So, gnucash makes two connections, and the lock-message is generated on trying to make the 2nd one.
> 
> regards,
> J. Woeckinger
> 
> 
> 
> Am 2010-11-26 02:31, schrieb John Ralls:
>> On Nov 25, 2010, at 1:44 PM, Johann Wöckinger wrote:
>> 
>>   
>>> Yes, it's also in 2.3.17.
>>> 
>>> Am 2010-11-25 21:28, schrieb John Ralls:
>>>     
>>>> On Nov 24, 2010, at 11:21 AM, Johann Wöckinger wrote:
>>>> 
>>>> 
>>>>       
>>>>> Hello,
>>>>> 
>>>>> since Version 2.3.16RC1, I notice the following message popup on starting gnucash:
>>>>> 
>>>>> GnuCash could not get exclusive write permission to postgres://.........
>>>>> 
>>>>> with some explaination for reasons for that.
>>>>> 
>>>>> It seems, that gnucash does not delete the lock entry in the database (table: gnclock) when closing the application (I found the lock entry still in the database table after closing gnucash), so it comes up with this warning on startup, which can be overridden on selecting "open" - but its somewhat annoying.
>>>>> 
>>>>> This behaviour was not observed in former releases of the 2.3.x series.
>>>>> 
>>>>> Would be nice to have the former behavior.
>>>>> 
>>>>>         
>>>> Have you seen this with 2.3.17? It sounds like a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=634392, which was fixed for 2.3.17.
>>>>       
>> Well, that's annoying, because I don't see the problem on my development system.
>> 
>> Are you connecting to a local (on the same machine) or network psql server?
>> On what OS are you running Gnucash? If you're connecting to psql on a different machine, what OS is it running? What version of psql?
>> 
>> Please start gnucash and find its PID and the hostname of the machine running Gnucash. Then quit Gnucash and, from psql, do "select * from gnclock". Are the hostnames and PIDs the same?
>> 
>> At the end of gnucash.trace is there a warning about not finding the lock?
>> 

Well, that's a use-case I hadn't considered. Why do you open the database again after Gnucash has already opened it for you?  

To change the behavior, Gnucash would have to close and unlock the old connection before opening the new one. If the open failed, it would have nothing open and would present a blank window, where now if the open fails it keeps the old connection (which for most users will be a different database).

Please, let's keep this on the list. Use "reply all" (or "reply list" if your mail client can do that).

Regards,
John Ralls