/*
 * Read above about cases when !ItemIdIsUsed(Citemid)
 * (child item is removed)... Due to the fact that
 * at the moment we don't remove unuseful part of
 * update-chain, it's possible to get too old
 * parent row here. Like as in the case which
 * caused this problem, we stop shrinking here.
 * I could try to find real parent row but want
 * not to do it because of real solution will
 * be implemented anyway, latter, and we are too
 * close to 6.5 release.        - vadim 06/11/99
 */
if (Ptp.t_data->t_xmax != tp.t_data->t_xmin)
...

locked buffer.

Hiroshi Inoue

This patch should enable 6.5 to build on Motorola 68000 architecture.
It comes from Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>.

1. Using 100 digits after decimal point on the default
   make runtest.

2. Using 1000 digits after decimal point in a new target
   make bigtest.

At the end of 'make runtest', a hint about the new bigtest is
printed.

Jan

   and possibly for other cases too:

   DO NOT cache status of transaction in unknown state
   (i.e. non-committed and non-aborted ones)

   Example:
   T1 reads row updated/inserted by running T2 and cache T2 status.
   T2 commits.
   Now T1 reads a row updated by T2 and with HEAP_XMAX_COMMITTED
   in t_infomask (so cached T2 status is not changed).
   Now T1 EvalPlanQual gets updated row version without HEAP_XMIN_COMMITTED
   -> TransactionIdDidCommit(t_xmin) and TransactionIdDidAbort(t_xmin)
   return FALSE and T2 decides that t_xmin is not committed and gets
   ERROR above.

   It's too late to find more smart way to handle such cases and so
   I just changed xact status caching and got rid TransactionIdFlushCache()
   from code.

   Changed: transam.c, xact.c, lmgr.c and transam.h - last three
   just because of TransactionIdFlushCache() is removed.

2. heapam.c:

   T1 marked a row for update. T2 waits for T1 commit/abort.
   T1 commits. T3 updates the row before T2 locks row page.
   Now T2 sees that new row t_xmax is different from xact id (T1)
   T2 was waiting for. Old code did Assert here. New one goes to
   HeapTupleSatisfiesUpdate. Obvious changes too.

3. Added Assert to vacuum.c
4. bufmgr.c: break
   Assert(buf->r_locks == 0 && !buf->ri_lock)
   into two Asserts.

ye proverbial one-line patch (not counting five lines of comment so's
maybe it won't happen again)

Add id tags to chapter and section headings to ensure good labels
 on output html files.

Adjust tags to get a clean build.

after ExecEndNode. It must be done! Or we'll be out of free
tuple slots very soon, though slots are freed by ExecEndNode
and ready for reusing.

We didn't see this problem before because of

int         nSlots = ExecCountSlotsNode(plan);
TupleTable  tupleTable = ExecCreateTupleTable(nSlots + 10);
    /* why add ten? - jolly */

code in InitPlan - i.e. extra 10 slots. Simple select uses
3 slots and so it was possible to re-use evaluation plan
3 additional times and didn't get

elog(NOTICE, "Plan requires more slots than are available");
elog(ERROR, "send mail to your local executor guru to fix this");

Changes are obvious and shouldn't be problems with them.
Though, I added Assert(epqstate->es_tupleTable->next == 0)
before EvalPlanQual():ExecInitNode and we'll notice if
something is still wrong. Is it better to change Assert
to elog(ERROR) ?

1. check whether the program is being executed in $PGDATA/..  This is
   necessary if the data tree is not in the standard place, as is the
   case with the Debian distribution (because of Debian policy).

2. give a clearer error message if the dumped data structure fails to
   be loaded.

Oliver Elphick

SHARED_LIB:

needs to be changed to:
SHARED_LIB:-lc

I think this was also needed on AIX 4.2. Comments Please !!

If nobody objects, I suggest to make this change, since it cannot
break AIX 4.2 and is necessary on AIX 4.3

Andreas

DO NOT EVEN TRY TO DO PageGetMaxOffsetNumber BEFORE
LockBuffer!
-:)

> (native win32, not cygnus).
> It does the following:
> Patches two win32.mak files to DEFINE HAVE_VSNPRINTF and
> HAVE_STRDUP. This is required to build at all.
> Bumps the version number on libpq.dll from 6.4 to 6.5.
> Required for install programs to work.
> Adds defintions for BLCKSZ and MAXIMUM_ALIGN to "win32.h" in
> the client-side libpiq directory.
>
> All these files are only used when building on native win32,
> so it should be safe I think.
>
> Again, really sorry to throw this in so late, but I would
> hate to do the same thing as with 6.4 (which required 6.4.1
> to at all compile on Win32).
>
> Thanks,
>
>   //Magnus

a non-leading % would be put into the >=/<= patterns.  Also, repair
longstanding confusion about whether %% means a literal %%.  The SQL92
doesn't say any such thing, and textlike() knows that, but gram.y didn't.

< 6.5 versions were just not affected by this bug due to locking.

2. varsup.c:ReadNewTransactionId(): don't read nextXid from disk -
   this func doesn't allocate next xid, so ShmemVariableCache->nextXid
   may be used (but GetNewTransactionId() must be called first).
3. vacuum.c: change elog(ERROR, "Child item....") to elog(NOTICE) -
   this is not ERROR, proper handling is just not implemented, yet.
4. s_lock.c: increase S_MAX_BUSY by 2 times.
5. shmem.c:GetSnapshotData(): have to call ReadNewTransactionId()
   _after_ SpinAcquire(ShmemIndexLock).

regression=> select sum(q1) from int8_tbl group by q2 order by sum(q1);
NOTICE:  equal: don't know whether nodes of type 107 are equal

and aggregate functions in queries that use inheritance.

inheritance ... basically it was completely busted :-(

EvalPlanQualNext() when implemented it... -:)
Uncommented...

index, etc is too long, truncate until it fits.

I have updated my contrib code for version 6.5. In the attachment you will
find the directories array, datetime, miscutil, string, tools and userlocks
which replace the corresponding directories under contrib.

In contrib/tools you will find some developement scripts which I use while
hacking the sources. I hope they will be useful for some other people.

I have also added a contrib/Makefile which tries to compile and install all
the contribs. Unfortunately many of them don't have a Makefile or don't
compile cleanly.

--
Massimo Dal Zotto