Re: [HACKERS] Small patches in copy.c and trigger.c

From: jwieck(at)debis(dot)com (Jan Wieck)
To: maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian)
Cc: jwieck(at)debis(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgreSQL(dot)org, mha(at)sollentuna(dot)net
Subject: Re: [HACKERS] Small patches in copy.c and trigger.c
Date: 1999-02-02 16:49:53
Message-ID: m107j1P-000EBPC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> > > > I thought Magnus' changes were only in the current CVS branch, not
> > > > in REL6_4 ?
> > >
> > > You are absolutely right. Sorry Magnus. The COPY complaint I heard
> > > obviously was not from this.
> > >
> >
> > If we don't discover any errors on COPY FROM after some days,
> > I think I should fix it in REL6_4 too.
> >
> > Do we plan to release v6.4.3 sometimes? If so, are there any
> > neat things I could add to the v6.4.3 feature patch?
>
> You mean your fixes, right. Magnus's stuff was only in current, and is
> fixed now.

That one in COPY.

But the other one in ExecBRDeleteTriggers() is still in
place. If a trigger returns something it created with
SPI_copytuple() (what's done for PL/pgSQL triggers allways if
returning NEW or OLD), that heap_tuple isn't pfree()'d until
transaction end.

Since it's safe to throw it away I'll go ahead and put that
into REL6_4.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1999-02-02 16:55:47 Re: [HACKERS] Postgres Speed or lack thereof
Previous Message Bruce Momjian 1999-02-02 16:39:18 Re: [HACKERS] Postgres Speed or lack thereof