Re: [pgadmin-hackers] autocommit feature in pgadmin
Hi,
I have made all the changes mentioned in below mail.
Along with that I have changed the code to read autoRollBack value in
pgadmin/frm/frmQuery.cpp file.
previously it was used "settings->Read(wxT("frmQuery/AutoRollBack"),
&bVal, true)" directly.
Now I have changed it to settings->GetAutoRollBack() which is defined in
sysSettings class.
I have attached the new patch with this mail.
Please review it and do the needful.
Regards,
Sanket Mehta
Sr Software engineer
Enterprisedb
On Tue, Mar 31, 2015 at 9:43 PM, Ashesh Vashi wrote:
> Hi Sanket,
>
> In your patch, I see couple of issues with your patch:
> 1. In pgadmin/frm/frmQuery.cpp:
> You've used "settings->Read(wxT("frmQuery/AutoCommit"), &bVal, true)"
> directly.
> You should be using the function, you've defined in sysSettings.
> i.e.
> sysSettings::GetAutoCommit()
> and, sysSettings::SetAutoCommit()
>
> Please follow the correct naming convention for the
> frmQuery::CommandNoBegin(...) function.
> Function must not start with a capital letter for a regular function (we
> do declare/define only the event functions with capital letters).
>
> 2. In pgadmin/ui/frmOptions.xrc:
> A lot of changes are in this patch, which not required for this feature.
>
> --
>
> Thanks & Regards,
>
> Ashesh Vashi
> EnterpriseDB INDIA: Enterprise PostgreSQL Company
>
>
>
> *http://www.linkedin.com/in/asheshvashi*
>
>
> On Tue, Mar 24, 2015 at 6:01 PM, Sanket Mehta <
> sanket.me...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> Below is the description of the autocommit feature implementation in
>> pgadmin:
>>
>> This feature is only applicable in query editor.
>>
>> Autocommit can be set on/off from 2 places.
>>
>> 1. pgadmin main browser -> File menu -> Options -> Query tool -> Query
>> editor -> Enable Auto commit
>> 2. In Query editor -> Query menu -> Auto-commmit
>>
>> By default auto commit will be enabled in pgadmin.
>>
>>
>> In any query editor session, once user uncheck this autocommit checkbox,
>> depending upon postgreSQL standard for executing the query it will execute
>> "BEGIN;" statement before executing the actual query and thus setting the
>> autocommit off for that session.
>>
>> User can set the autocommit on at any time by selecting the checkbox from
>> above mentioned places.
>> But it will be active only after user has completed the transaction
>> block(started by BEGIN as mentioned above) by END or ROLLBACK or COMMIT;
>>
>> Let me know in case of any queries.
>>
>> Regards,
>> Sanket Mehta
>> Sr Software engineer
>> Enterprisedb
>>
>
>
autocommit.patch
Description: Binary data
--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] pgAgent commit: Fixed a bug in DBconn::GetLastError() function.
Fixed a bug in DBconn::GetLastError() function. pgAgent was crashing, while removing the trailing new-lines from the empty error message string (Reported by: Thomas Krennwallner) Branch -- master Details --- http://git.postgresql.org/gitweb?p=pgagent.git;a=commitdiff;h=f9bf1ccb27ebcfce00e7a6d467bc0e1b5ee9555e Modified Files -- connection.cpp | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] PATCH: pgagent fix for 'Caught unhandled unknown exception; terminating' bug in SQL steps
On Tue, Mar 31, 2015 at 6:26 PM, Ashesh Vashi wrote:
> On Tue, Mar 31, 2015 at 6:20 PM, Dave Page wrote:
>
>>
>>
>> On Tue, Mar 31, 2015 at 8:45 AM, Ashesh Vashi <
>> ashesh.va...@enterprisedb.com> wrote:
>>
>>> On Thu, Mar 26, 2015 at 6:19 PM, Thomas Krennwallner <
>>> tk+pg...@postsubmeta.net> wrote:
>>>
Hi!
Running pgagent 3.4.0 on Debian jessie with an SQL jobstep crashes the
worker thread with the error message
Caught unhandled unknown exception; terminating
Both job and jobstep status then remain as 'r' (running) until the
pgagent process quits. After restarting pgagent, which cleans up the
job status and sets it to 'd' (aborted), the job containing the SQL
jobstep is free to run again, but the next run will end up in the same
deadlock situation.
I have tracked down the problem to DBconn::GetLastError(), which gets
called after each SQL jobstep execution in Job::Execute(): there,
DBconn::GetLastError() throws an exception whenever the last error
message is empty.
The attached patch fixes this problem by adding missing bounds checks
to DBconn::GetLastError().
>>> Thanks for the patch.
>>> But - I was thinking about another fix for the same.
>>> I used the wxString::Trim(trimRight=true) function in order to remove
>>> the white-spaces from the right side.
>>>
>>>
>>> Dave,
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *diff --git a/connection.cpp b/connection.cppindex 6103c00..ccbb5c7
>>> 100644--- a/connection.cpp+++ b/connection.cpp@@ -314,14 +314,7 @@ int
>>> DBconn::ExecuteVoid(const wxString &query) wxString
>>> DBconn::GetLastError() {// Return the last error message, minus any
>>> trailing line ends- if (lastError.substr(lastError.length() - 2, 2)
>>> == wxT("\r\n")) // DOS- return lastError.substr(0,
>>> lastError.length() - 2);- else if
>>> (lastError.substr(lastError.length() - 1, 1) == wxT("\n")) //
>>> Unix- return lastError.substr(0, lastError.length() -
>>> 1);- else if (lastError.substr(lastError.length() - 1, 1) ==
>>> wxT("\r")) // Mac- return lastError.substr(0,
>>> lastError.length() - 1);- else- return
>>> lastError;+ return lastError.Trim(true); }*
>>>
>>> Do you think - above diff make sense?
>>> If yes - I will commit the code.
>>>
>>
>>
>> That does seem like it would do it.
>>
> Thanks.
> I will commit the changes.
>
I have committed the changes.
Thanks Thomas Krennwallner for the report and for the patch too.
--
Thanks & Regards,
Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company
*http://www.linkedin.com/in/asheshvashi*
>
> --
>
> Thanks & Regards,
>
> Ashesh Vashi
> EnterpriseDB INDIA: Enterprise PostgreSQL Company
>
>
>
> *http://www.linkedin.com/in/asheshvashi*
>
>
>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>
