<p class="MsoNormal">Context:</p><p class="MsoNormal"><br></p>

<p class="MsoNormal">Occasionally, we use SLONIK EXECUTE SCRIPT to create a
table, and then add it to replication by putting the new table in a temporary
set and merging it into our main set. The tables we create reference one of our
highest-activity tables, locations_miles_log, which regularly receives hundreds
of updates every few seconds.</p>

<p class="MsoNormal">We run Slony 2.0.7 and Postgresql 8.4.9 on a single-master,
single-slave cluster, connected by a fast WAN, with both slons running on the
same server as the slave.</p>

<p class="MsoNormal"><br></p><p class="MsoNormal">Problem: </p><p class="MsoNormal"><br></p>

<p class="MsoNormal">Recently, we created a table via SLONIK EXECUTE SCRIPT, with
the following structure (as reported by the slonik_execute_script altperl
script):</p>

<p class="MsoNormal">    DDL script consisting of 1 SQL statements</p>

<p class="MsoNormal">    DDL Statement 0: (0,508) [CREATE TABLE
display_field_data_23656(</p>

<p class="MsoNormal">                  miles_log_id integer NOT NULL,</p>

<p class="MsoNormal">                  locations_miles_log_id integer NOT NULL</p>

<p class="MsoNormal">     </p>

<p class="MsoNormal">                 ,CONSTRAINT display_field_data_23656_pkey PRIMARY KEY
(locations_miles_log_id)</p>

<p class="MsoNormal">                 ,CONSTRAINT display_field_data_23656_fk FOREIGN KEY
(locations_miles_log_id)</p>

<p class="MsoNormal">                      REFERENCES
locations_miles_log</p>

<p class="MsoNormal">                      (locations_miles_log_id) MATCH SIMPLE ON UPDATE</p>

<p class="MsoNormal">                       NO
ACTION ON DELETE CASCADE</p>

<p class="MsoNormal">                )]</p>

<p class="MsoNormal">Shortly (30m) after running that through Slonik, our
application crashed due to unreleased locks on tables. We checked, and the
CREATE TABLE statement generated by Slonik was still in progress, presumably
waiting. We had not yet added the created tables to replication; all we had
done was run slonik_execute_script. It is possible that this is coincidental,
and a problem with our application’s structure. However, that seems remote,
considering the thousands of similar such changes we have made in the past, before we used Slony. Do you have
any ideas why this might have occurred, or of why passing table creation
statements through SLONIK EXECUTE SCRIPT might cause locking issues?</p>