Обсуждение: logtrigger issue in PostgreSQL HEAD

Поиск
Список
Период
Сортировка

logtrigger issue in PostgreSQL HEAD

От
Christopher Browne
Дата:
Something has evidently changed of late (not quite sure when) which
causes the Slony-I log triggers to break when working against PostreSQL
HEAD.

A more-or-less simplest case is demonstrated thus:

chris@dba2:/mnt/PostgreSQL/dbs> psql slonyregress1
Line style is ascii.
psql (8.5devel)
Type "help" for help.

slonyregress1=# \d table1                        Table "public.table1"Column |  Type   |                      Modifiers
                    
 
--------+---------+-----------------------------------------------------id     | integer | not null default
nextval('table1_id_seq'::regclass)data  | text    | 
 
Indexes:   "table1_pkey" PRIMARY KEY, btree (id)
Referenced by:   TABLE "table2" CONSTRAINT "table2_table1_id_fkey" FOREIGN KEY (table1_id) REFERENCES table1(id) ON
UPDATECASCADE ON DELETE CASCADE
 
Triggers:   _slony_regress1_logtrigger_1 AFTER INSERT OR DELETE OR UPDATE ON table1 FOR EACH ROW EXECUTE PROCEDURE
_slony_regress1.logtrigger('_slony_regress1','1', 'kv')
 

slonyregress1=# delete from table1 where id = 1;
server closed the connection unexpectedlyThis probably means the server terminated abnormallybefore or while processing
therequest.
 
The connection to the server was lost. Attempting reset: Failed.
!> \q

There are no notable compiler complaints about
src/backend/slony_funcs.c, so the mismatch must be at a subtler level
than that of an up-front API change for something.

I suppose a next step might be to kick off gdb against the backend when
processing this.
-- 
output = ("cbbrowne" "@" "ca.afilias.info")
Christopher Browne
"Bother,"  said Pooh,  "Eeyore, ready  two photon  torpedoes  and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"


Re: logtrigger issue in PostgreSQL HEAD

От
Alvaro Herrera
Дата:
Christopher Browne wrote:

> There are no notable compiler complaints about
> src/backend/slony_funcs.c, so the mismatch must be at a subtler level
> than that of an up-front API change for something.
> 
> I suppose a next step might be to kick off gdb against the backend when
> processing this.

Yeah, let's see a backtrace.  Maybe we need to break an API somewhere so
that this becomes more obvious at compile time.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support