From: Jens Rathke <101602.1256@compuserve.com>
Date: 19 Apr 96 08:58:07 EDT
Subject: [PG95]: bug-report

============================================================================
                        POSTGRES95 BUG REPORT TEMPLATE
============================================================================

Your name		:	Helmar Spangenberg
Your email address	:	101602,1256@compuserve.com


System Configuration
- ---------------------
  Architecture (example: DEC Alpha AXP)  	:  Intel 386/486/586

  Operating System (example: OSF/1 3.2)  	:  Linux 1.2.13-ELF

  Postgres95 version (example: Postgres95-1.0) :   Postgres95-1.0

  Compiler used (example:  gcc 2.6.3)		:  gcc 2.7.0


Please enter a FULL description of your problem:
- ------------------------------------------------

Queries of tables containing more than 16 attributes may lead to
a hangng of the database, when the last attributes are empty (i.e.
no value was ever inserted into those attributes).



Please describe a way to repeat the problem.   Please try to provide a
concise reproducible example, if at all possible: 
- ----------------------------------------------------------------------

Create any Table with more than 16 (!) attributes.
Insert several instances, however populate nothing but the first
and the last column.
Do a SELECT * on that table --- the system will hang.




If you know how this problem might be fixed, list the solution below:
- ---------------------------------------------------------------------

I think, it's a minor bug in fe-exec.c. Since in the case described
above the backend returns zeros for all unset attributes in the
bitmap, the last bytes of the bitmap-stream contain byte-values
of 0. In line 134 of fe_exec.c you use the function pgGets (with
an additional parameter) to read the stream. Empty bytes, however,
trigger pgGets to stop reading, which will disturb the interpretation
of the following bytes (since there are bytes defining the length
of following attributes, results can be dramatic).

My solution was to use pqGetnchar instead of pqGets, in that case the
extra parameter makes sense ;^). Until now I did not realize any
side effects of that change.