Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA27742; Thu, 30 Jul 92 16:27:57 -0700
Message-Id: <9207302327.AA27742@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: Bug in copy binary of variable length fields
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Reply-To: mer@postgres.berkeley.edu
In-Reply-To: Your message of "Tue, 28 Jul 92 12:28:20 CST."
             <9207280258.AA08427@pangaea.dme> 
Date: Thu, 30 Jul 92 16:27:09 PDT

you write:
> Description: 
> "copy binary" would crash if any of the attributes had a varlena stucture 
> ( eg text ). 
>  
> Source Files Changed: ~postgres/src/commands/copy.c 
>  
> Procedure Changed : CopyFrom() 
>  
>         line number : 378 
>         was         : values[i] = (Datum) (ptr + 4); 
>         now         : values[i] = (Datum) ptr; 
>          
>         line number : 379
>         was         : LONGALIGN(ptr + * (unsigned long *) ptr + 4);
>         now         : LONGALIGN(ptr + * (unsigned long *) ptr); 
>          
> Explanation: 
>         The varlena type is 
>         /* ---------------- 
>          *      struct varlena 
>          * ---------------- 
>          */ 
>          struct varlena { 
>                 long    vl_len;
>                 char    vl_dat[1]; 
>            };
>         the original source was skipping over the vl_len field.  
>         When the code for copy was expecting to find the vl_len is was
>         instead finding the fist four bytes of the vl_dat field. 

You have it exactly right.  This bug depended on another bug that was
fixed not too long ago.  We used to write the length of varlenas to disk
twice.  Thus skipping 4 bytes wouldn't have caused any problems.  When
we stopped the duplication we didn't test everything very thoroughly.
Thanks for the diffs.


Jeff Meredith
mer@postgres.berkeley.edu