On 5/9/2007 11:13 AM, Gregory Stark wrote:
> The coding below from a recent commit to xxid.c is unfortunately unsafe.
> Packed varlenas are unaligned (even if the datum itself is aligned the data
> within will be unaligned since it follows a 1-byte header). That means
> snap->nxip which is an integer and should be 4-byte aligned on most
> architectures will land on random alignments.

I see. This data type currently is nowhere stored in the DB by Slony, it 
is just handed around in memory, but it is probably a good idea to not 
make any assumptions about alignment even then.

I'll fix it. Thanks for pointing that out.


Jan


> 
> In fact since the struct itself will require 4-byte alignment the compiler may
> not be happy with accessing even single bytes from it if it's in a packed
> varlena and stored unaligned.
> 
> In short, it's sad but you can't use PG_DETOAST_DATUM_PACKED unless you really
> don't care about the alignment of the data which means basically it's only
> useful for data like text and bytea which contain just unaligned bytes. Or
> perhaps for functions that are just going to memcpy or memcmp the data without
> accessing fields within it.
> 
> The alternative is to mark the data type as typstorage 'p' which disables
> packed storage altogether. That might make sense if you store relatively few
> such data and process them frequently so the cpu costs of copying them is
> actually greater than the i/o costs of storing padding bytes. int2vector and
> oidvector are set like that in part for reasons like that (plus others).
> 
> typedef struct
> {
> 	TransactionId xmin;
> 	TransactionId xmax;
> 	int			nxip;
> 	TransactionId xip[1];
> }	xxid_snapshot;
> 
> ...
> 
> Datum
> _Slony_I_xxid_snapshot_out(PG_FUNCTION_ARGS)
> {
> 	xxid_snapshot *snap = (xxid_snapshot *) VARDATA_ANY(PG_DETOAST_DATUM_PACKED((PG_GETARG_DATUM(0))));
> 
> 	char	   *str = palloc(28 + snap->nxip * 13);
> ...
> 
> 


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #