behavior of connectby() in the presence of infinite recursion. Please
apply this one in addition to the one sent earlier.

Joe Conway

> contrib/tablefunc/tablefunc.c:connectby. But, other unmanageable error
> seems to occur even if a table has commonplace tree data(see below).
>
> I would think the patch, ancestor check, should be
>
>   if (strstr(branch_delim || branchstr->data || branch_delim,
>                        branch_delim || current_key || branch_delim))
>
> This is my image, not a real code. However, if branchstr->data includes
> branch_delim, my image will not be perfect.

Good point. Thank you Masaru for the suggested fix.

Attached is a patch to fix the bug found by Masaru. His example now
produces:

regression=# SELECT * FROM connectby('connectby_tree', 'keyid',
'parent_keyid', '11', 0, '-') AS t(keyid int, parent_keyid int, level
int,
branch text);
  keyid | parent_keyid | level |  branch

-------+--------------+-------+----------
     11 |              |     0 | 11
     10 |           11 |     1 | 11-10
    111 |           11 |     1 | 11-111
      1 |          111 |     2 | 11-111-1
(4 rows)

While making the patch I also realized that the "no show branch" form of
the  function was not going to work very well for recursion detection.
Therefore  there is now a default branch delimiter ('~') that is used
internally, for  that case, to enable recursion detection to work. If
you need a different  delimiter for your specific data, you will have to
use the "show branch" form  of the function.

Joe Conway

client
utilities (libpq.dll and psql.exe) for win32 (missing defines,
adjustments to
includes, pedantic casting, non-existent functions) per:
   http://developer.postgresql.org/docs/postgres/install-win32.html.

It compiles cleanly under Windows 2000 using Visual Studio .net. Also
compiles clean and passes all regression tests (regular and contrib)
under Linux.

In addition to a review by the usual suspects, it would be very
desirable for  someone well versed in the peculiarities of win32 to take
a look.

Joe Conway

Neil Conway

> * Add schema, cast, and conversion backslash commands to psql

be able to do that, but the ability seems to have got lost in the
shuffle).  Add a -o nextOID switch for completeness.  Improve the
documentation to explain how and why to use these switches.

so that precision of result is always at least as good as you'd get from
float8 arithmetic (ie, always at least 16 digits of accuracy).  Per
pg_hackers discussion a few days ago.

Pass less-unsafe parameters to Darwin's NSLinkModule.  While this change prevents a backend coredump when loading a broken shlib, it also seems to suppress the error messages that might help debug the problem :-(.  Perhaps someone would like to supply a 'linkEdit' hook to get the best of both worlds.  But in the meantime, backend crash trumps error reporting.

 Modified Files:
 	OptionalTestSuite.java

patch submitted by ammulder@alumni.princeton.edu

 Modified Files:
 	jdbc.sgml

remove the special case in ALTER DROP COLUMN to prohibit dropping a
table's last column.

Vacuum must not advance pg_database.datvacuumxid nor truncate CLOG
unless it's processed *all* tables in the database.  Vacuums run by
unprivileged users don't count.

(Beats head against nearest convenient wall...)

Please apply the patch attached and this should be solved.

Alvaro Herrera

heap_addheader is wrong because it doesn't cope with varlena fields,
notably indpred.

no reason to worry about the tuple commit status bits until the tuple
is inserted in a relation by heapam.c.  Also, improve comments for
heap_addheader().

at this area in the code.

recent WAL activity has occurred.  Without this, it's possible that a
later crash might leave tuples on disk with un-updated commit status
bits.

VACUUM FULL tuple moves.  Store full-width t_infomask in WAL, rather
than storing low 8 bits and expecting to be able to reconstruct upper
bits.  While at it, remove redundant t_oid field from WAL headers
(the OID, if present, is now recorded in the data portion of the tuple).
WAL version number bumped --- this does not force an initdb, you can
instead run pg_resetxlog after a clean shutdown of the old postmaster.

causing  the postmaster to crash when the trigger was running on a table
without a  primary key.

I've also updated the docs to explicitly say that tables need primary
keys.

Steven Singer

let's say this patch superscedes the previous one.

I have also attached a patch addressing the similar memory leak problem in
plpython. This includes a slight adjustment of the tests in the source
directory. The patch also includes a cosmetic change to remove a compiler
warning although I think the change makes the code look worse though.

BTW, by my reckoning the memory leak would occur with prepared plans and
without. If that is not the case then I've been barking up the wrong tree.

Nigel J. Andrews

adding a missing sprintf().

Neil Conway

handling in the backend.

number of forward references in the admin guide.

ProcKill instead, where we still have a PGPROC with which to wait on
LWLocks.  This fixes 'can't wait without a PROC structure' failures
occasionally seen during backend shutdown (I'm surprised they weren't
more frequent, actually).  Add an Assert() to LWLockAcquire to help
catch any similar mistakes in future.  Fix failure to update MyProcPid
for standalone backends and pgstat processes.