Fixed "Slony" related issues - Mailing list pgadmin-hackers

From Akshay Joshi
Subject Fixed "Slony" related issues
Date
Msg-id CANxoLDdjmm86f9+jKS+_YAdn+nNdSHM_zL2p5Y0WEWqddmdexQ@mail.gmail.com
Whole thread Raw
Responses Re: Fixed "Slony" related issues  (Dave Page <dpage@pgadmin.org>)
List pgadmin-hackers
Hi Dave 

While testing pgAdmin with "Slony" I have found couple of following issues
  1. Found crash (segmentation fault) when create a new schema using slony replication cluster. Crash is reproducible when user opens the "New Schema..." dialog and select an slony cluster from "Use Slony" combo box and click "OK".
  2. DDL Statements like ( "CREATE SCHEMA" , "ALTER TABLE" ..)  didn't work if user select an slony cluster from "Use Slony" combo box and click "OK".
I have analyze and fixed both the issues. Below is my analysis and solution

Analysis for 1: - We have used wxComboBox for "Use Slony" option in the dlgProperty dialog. To add an item into the combo box we have used "Append" method of wxControlWithItems (wxComboBox is derived from wxControlWithItems). 

According to the documentation of "wxControlWithItems" it is mention that in the same control all items must have client data of the same type (typed or untyped), if any. This type is determined by the first call to Append (the version with client data pointer) or SetClientData. Attached is the screenshot.

In pgAdmin we have appended the wxEmptyString without any client data first in the "Use Slony" combo box and then the slony cluster with client data. So when the first append call gets executed, type of the client data is determined as "Void *"  

Solution for 1:- There are two ways to solve this issue. 
  • Create a dummy object of client data(replClientData in our case) and passed it when we append the wxEmptyString".
  • Typecast the "replClientData" to (void *) while appending the slony cluster.
I have fixed it using the second option. 

Analysis for 2:- After fixing the above crash when we try to create the new schema or add any new column to the existing table it neither applied to the Master nor on Slave. As per the pgAdmin code if we select a slony cluster then following two statements runs:

SELECT _slonycluster.ddlscript_prepare(1, 0);
SELECT _slonycluster.ddlscript_complete(1, 'ALTER TABLE "Test" ADD COLUMN isSlony boolean; ', 0);

Where "p_only_on_node" parameter is set to 0. It is hard coded. Then I have googled and found some example where this parameter is set to -1. 

I have analyze the code of "Slony 2.1.3 (slonik.c file) " and found that it executes the following statement in sequence 
SELECT _slonycluster.ddlscript_prepare(1, -1);
ALTER TABLE "Test" ADD COLUMN isSlony boolean;
SELECT _slonycluster.ddlscript_complete(1, 'ALTER TABLE "Test" ADD COLUMN isSlony boolean; ', -1); 

Comparing it with pgAdmin code we execute only two statements(ddlscript_prepare and ddlscript_complete) which is being used for replication only, but there is no logic to execute the statement on Master itself. May be my understanding here is wrong, please correct me.       

 
Solution for 2:- To solve the above issue, First I have set the value of "p_only_on_node" to -1 instead of 0 and then added the SQL which is going to be executed on Master.

Attached is the patch file. Please review it and if it looks good to you then can you please commit it.

--
Akshay Joshi
Senior Software Engineer 
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
Phone: +91 20-3058-9522
Mobile: +91 976-788-8246
Attachment

pgadmin-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: Fixed one minor issue related to "Reassign objects to"
Next
From: Dave Page
Date:
Subject: Re: Fixed help information issue for "Server Instrumentation" guru hint