is redundant after a check has already been made for "num < 0". The "set"
variable can also be removed, as it is now no longer used. Per checking
with Karel, this is the right fix.

Per Coverity static analysis performed by EnterpriseDB.

next iteration of a loop. Update documentation and add regression tests.
Patch from Pavel Stehule, reviewed by Neil Conway.

using the recently added lo_create() function.  The restore logic in
pg_restore is greatly simplified as well, since there's no need anymore
to try to adjust database references to match a new set of blob OIDs.

Dave Page.  Also, cause it to emit rather than ignore any ACL and
datconfig options that may be set for these two databases.

unlike template0 and template1 does not have any special status in
terms of backend functionality.  However, all external utilities such
as createuser and createdb now connect to "postgres" instead of
template1, and the documentation is changed to encourage people to use
"postgres" instead of template1 as a play area.  This should fix some
longstanding gotchas involving unexpected propagation of database
objects by createdb (when you used template1 without understanding
the implications), as well as ameliorating the problem that CREATE
DATABASE is unhappy if anyone else is connected to template1.
Patch by Dave Page, minor editing by Tom Lane.  All per recent
pghackers discussions.

malformed ident map file.  This was introduced by the linked list
rewrite in 8.0 -- mea maxima culpa.

Per Coverity static analysis performed by EnterpriseDB.

only used in one branch of an if statement, so we can move its
declaration to that block. This also avoids an unnecessary syscache
lookup.

Per Coverity static analysis performed by EnterpriseDB.

NULL (e.g. due to the preceding strlen()). Therefore we needn't recheck
this before initializing 'e_text'.

Per Coverity static analysis performed by EnterpriseDB.

(due to the preceding strlen(), for example), so we needn't recheck this
before invoking pg_mbcliplen().

Per Coverity static analysis performed by EnterpriseDB.

It never leaked memory before PG 8.0, so none of the callers are
expecting this.  Cleanest fix seems to be to make it allocate the needed
memory in estate->eval_econtext, where it will be cleaned up by
the next exec_eval_cleanup.  Per report from Bill Rugolsky.

*fail*, to test that plpython didn't allow untrusted operations.
When we changed plpython to plpythonu because python didn't actually have
a secure sandbox mode, someone (probably me :-() misinterpreted the tests
as checking whether Python's file I/O works.  Which is a stupid thing for
us to be testing.  Remove it so we don't clutter the filesystem with
random temporary files.

copying/converting the new value, which meant that it failed badly on
"var := var" if var is of pass-by-reference type.  Fix this and a similar
hazard in exec_move_row(); not sure that the latter can manifest before
8.0, but patch it all the way back anyway.  Per report from Dave Chapeskie.

(a/k/a SELECT INTO).  Instead, flush and fsync the whole relation before
committing.  We do still need the WAL log when PITR is active, however.
Simon Riggs and Tom Lane.

2. improve vacuum for gist
   - use FSM
   - full vacuum:
      - reforms parent tuple if it's needed
        ( tuples was deleted on child page or parent tuple remains invalid
          after crash recovery )
      - truncate index file if possible
3. fixes bugs and mistakes

'register' qualifier, make some function declarations more consistent,
and so on.

buildfarm machines.

investigate buildfarm failures.

scankeys arrays that it needs can never have more than INDEX_MAX_KEYS
entries, so it's reasonable to just allocate them as fixed-size local
arrays, and save the cost of palloc/pfree.  Not a huge savings, but
a cycle saved is a cycle earned ...

includes error checking and an appropriate ereport(ERROR) message.
This gets rid of rather tedious and error-prone manipulation of errno,
as well as a Windows-specific bug workaround, at more than a dozen
call sites.  After an idea in a recent patch by Heikki Linnakangas.

given reasonably short lifespans for prepared transactions, this should
mean that only a small minority of state files ever need to be fsynced
at all.  Per discussion with Heikki Linnakangas.

Andreas Pflug

Michael Fuhr

not memcpy() to copy the offered key into the hash table during HASH_ENTER.
This avoids possible core dump if the passed key is located very near the
end of memory.  Per report from Stefan Kaltenbrunner.

old suggestion by Oliver Jowett.  Also, add a transaction column to the
pg_locks view to show the xid of each transaction holding or awaiting
locks; this allows prepared transactions to be properly associated with
the locks they own.  There was already a column named 'transaction',
and I chose to rename it to 'transactionid' --- since this column is
new in the current devel cycle there should be no backwards compatibility
issue to worry about.

releasing locks, so COMMIT PREPARED should too.

< * -Add two-phase commit [2phase]
> * -Add two-phase commit

< * Add two-phase commit [2phase]
> * -Add two-phase commit [2phase]

hacking by Alvaro Herrera and Tom Lane.

> * Auto-fill the free space map by scanning the buffer cache or by
>   checking pages written by the background writer
< * Auto-fill the free space map by scanning the buffer cache or by
<   checking pages written by the background writer

* Auto-fill the free space map by scanning the buffer cache or by
  checking pages written by the background writer

Kris Jurka