On Thu, 27 Sep 2007, Jeff Frost wrote:

>> ALTER TABLE billing_discount ADD column "use_term" character(1);]
>> 2007-09-27 20:21:16 UTC CONFIG DDL success - PGRES_COMMAND_OK
>> 2007-09-27 20:21:16 UTC CONFIG remoteWorkerThread_1: DDL Statement 6: [
>> ALTER TABLE billing_discount ALTER column use_term set default 'n';]
>> 2007-09-27 20:21:16 UTC CONFIG DDL success - PGRES_COMMAND_OK
>> 2007-09-27 20:21:16 UTC CONFIG remoteWorkerThread_1: DDL Statement 7: [
>> ALTER TABLE billing_discount add constraint use_term_cons check (use_term 
>> in ('y','n'));]
>> 2007-09-27 20:21:16 UTC CONFIG DDL success - PGRES_COMMAND_OK
>> 2007-09-27 20:21:16 UTC CONFIG remoteWorkerThread_1: DDL Statement 8: [
>> 
>> alter table table1 rename column id to col1;]
>> 2007-09-27 20:21:16 UTC CONFIG DDL success - PGRES_COMMAND_OK
>> 2007-09-27 20:21:16 UTC CONFIG remoteWorkerThread_1: DDL Statement 9: []
>> 2007-09-27 20:21:16 UTC CONFIG DDL success - PGRES_EMPTY_QUERY
>> 2007-09-27 20:21:16 UTC DEBUG2 slon: child terminated status: 65280; pid: 
>> 24126, current worker pid: 24126
>> 2007-09-27 20:21:16 UTC DEBUG1 slon: restart of worker in 10 seconds
>> 2007-09-27 20:21:20 UTC DEBUG1 slon: shutdown requested
>> 2007-09-27 20:21:20 UTC DEBUG2 slon: notify worker process to shutdown
>> 2007-09-27 20:21:20 UTC DEBUG1 slon: done
>> 2007-09-27 20:21:20 UTC DEBUG2 slon: exit(0)
>> 
>> So, for instance, statement #6 was going to alter table billing_discount to 
>> add a CHECK constraint:
>> 
>> As we can see, that constraint isn't there.
>> 
>> slonyregress2@[local]:5834=# \d billing_discount
>>                                          Table "public.billing_discount"
>>      Column        |           Type           | Modifiers 
>> ---------------------+--------------------------+--------------------------------------------------------------------
>> discount_code       | character(2)             | not null
>> billing_object_type | character varying(10)    | not null
>> billing_action_type | character varying(10)    | not null
>> discount_amount     | numeric(7,2)             | not null
>> start_date          | timestamp with time zone | not null
>> end_date            | timestamp with time zone | not null
>> billing_discount_id | integer                  | not null default 
>> nextval(('billing_discount_seq'::text)::regclass)
>> registrar_id        | integer                  |
>> tld_id              | integer                  |
>> zone_id             | integer                  |
>> Indexes:
>>   "billing_discount_pkey" PRIMARY KEY, btree (billing_discount_id)
>> Triggers:
>>   _slony_regress1_denyaccess_5 BEFORE INSERT OR DELETE OR UPDATE ON 
>> billing_discount FOR EACH ROW EXECUTE PROCEDURE 
>> _slony_regress1.denyaccess('_slony_regress1')
>> 
>> slonyregress2@[local]:5834=#
>> 
>> This heads me back to the "wait, that's impossible!" expectation that I 
>> started with.
>> 
>> When the ERROR message was submitted to the slon log, that means that the 
>> transaction rolls back, and everything recovers to where it was.
>> 
>> That's what I see happen here; I can't quite fathom why that's not 
>> happening there.
>
> I guess it's fun to be unique. :-)
>
> And your introduction of the failure modes was on the slave and not the 
> master, correct?  Were you testing with 1.2.11 and not 1.2.10?  Could I 
> possibly be misinterpreting the log messages?
>
> BTW, thanks for looking into this.

And more importantly, how can I get you more useful data points?

-- 
Jeff Frost, Owner 	<jeff at frostconsultingllc.com>
Frost Consulting, LLC 	http://www.frostconsultingllc.com/
Phone: 650-780-7908	FAX: 650-649-1954