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

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: jwieck(at)debis(dot)com
Cc: 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-01 23:23:59
Message-ID: 199902012324.SAA03146@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Hi,
>
> I've just committed two very simple patches to copy.c and
> trigger.c which caused backend to grow until transaction end.
>
> trigger.c didn't expected that trigger function could have
> returned another heap tuple that was built inside of trigger
> with SPI_copytuple().
>
> In copy.c I'n not absolutely sure why it was as it was. In
> CopyFrom() the array for the values was palloc()'d once
> before entering the copy loop, and then again at the top of
> the loop. But there was only one pfree() after loop exited.
>
> I've removed the palloc() inside the loop. Seems to work for
> the regression test. Telling here only for the case someone
> encounters problems on COPY FROM.

I have a morbid curiosity, so I decided to find out how this got into
the source. On November 1, 1998, Magus applied a patch:

Here is a first patch to cleanup the backend side of libpq. This patch
removes all external dependencies on the "Pfin" and "Pfout" that are
declared in pqcomm.h. These variables are also changed to "static" to
make sure. Almost all the change is in the handler of the "copy" command
- most other areas of the backend already used the correct functions.
This change will make the way for cleanup of the internal stuff there -
now that all the functions accessing the file descriptors are confined
to a single directory.

Several users have complained about 6.4.* COPY slowing down when loading
rows. This may be the cause. Good job finding it.

In fact, Magnus added two palloc's, when 'values' already had a
palloc(). Magnus, we all make goofy mistakes, so don't sweat it.
However, if you had some deeper reason for adding the palloc's, please
let us know. Jan, I will make sure there is only one palloc for 'values'
in CopyFrom().

I am about to commit TEMP tables anyway.

---------------------------------------------------------------------------

values = (Datum *) palloc(sizeof(Datum) * attr_count);
nulls = (char *) palloc(attr_count);
index_nulls = (char *) palloc(attr_count);
idatum = (Datum *) palloc(sizeof(Datum) * attr_count);
byval = (bool *) palloc(attr_count * sizeof(bool));

for (i = 0; i < attr_count; i++)
{
nulls[i] = ' ';
index_nulls[i] = ' ';
byval[i] = (bool) IsTypeByVal(attr[i]->atttypid);
}
values = (Datum *) palloc(sizeof(Datum) * attr_count);

lineno = 0;
while (!done)
{
values = (Datum *) palloc(sizeof(Datum) * attr_count);
if (!binary)

---------------------------------------------------------------------------

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jackson, DeJuan 1999-02-01 23:30:42 RE: [HACKERS] Patches
Previous Message Jan Wieck 1999-02-01 20:35:29 Small patches in copy.c and trigger.c