On 12/23/2011 10:00 AM, Zac Bentley wrote:
>
>      DDL Statement 0: (0,508) [CREATE TABLE display_field_data_23656(
>
>                    miles_log_id integer NOT NULL,
>
>                    locations_miles_log_id integer NOT NULL
>
>                   ,CONSTRAINT display_field_data_23656_pkey PRIMARY KEY
> (locations_miles_log_id)
>
>                   ,CONSTRAINT display_field_data_23656_fk FOREIGN KEY
> (locations_miles_log_id)
>
>                        REFERENCES locations_miles_log
>
>                        (locations_miles_log_id) MATCH SIMPLE ON UPDATE
>
>                         NO ACTION ON DELETE CASCADE
>
>                  )]

This CREATE TABLE statement will require an AccessExclusiveLock on the 
locations_miles_log table, no matter if it is executed through psql.

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

Unless the application is accessing any slony internal tables, there 
should not be any such locking issues. Is it possible that some other 
connection is/was "idle in transaction", holding a share lock on the table?

Since you are on 2.0.x, you can create the table directly through psql 
on all nodes, then add it to replication in the usual fashion. This will 
remove Slony as a possible cause of problems during the CREATE TABLE part.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin