config file if it exists.  This was already discussed as being a good
idea, and now seems the cleanest way to deal with initdb-time failures
on machines with small SHMMAX.  (The submitted patches instead modified
initdb.sh to pass the correct sizing parameters, but that would still
leave standalone backends prone to failure later.  An admin who needs
to use a standalone backend has enough trouble already, he shouldn't
have to manually configure its shmem settings...)

layout; therefore, this change forces REINDEX of hash indexes (though
not a full initdb).  Widen hashm_ntuples to double so that hash space
management doesn't get confused by more than 4G entries; enlarge the
allowed number of free-space-bitmap pages; replace the useless bshift
field with a useful bmshift field; eliminate 4 bytes of wasted space
in the per-page special area.

scheme.  A pleasant side effect is that it is *much* faster when deleting
a large fraction of the indexed tuples, because of elimination of
redundant hash_step activity induced by hash_adjscans.  Various other
continuing code cleanup.

libpq, talking to an old server, should assume SQL_ASCII as the default
client encoding, because that is what the server will actually use (not
the server encoding).

unneeded configure work.

yet).  Fix a couple of bugs that would only appear if multiple bitmap pages
are used, including a buffer reference leak and incorrect computation of bit
indexes.  Get rid of 'overflow address' concept, which accomplished nothing
except obfuscating the code and creating a risk of failure due to limited
range of offset field.  Rename some misleadingly-named fields and routines,
and improve documentation.

explanation of the remarkably confusing page addressing scheme.
The file also includes my planned-but-not-yet-implemented revision
of the hash index locking scheme.

slight resemblance to their actual behavior.

different object types.  Fix, and centralize logic to try to prevent
the same mistake in future.

rather than relying on OID order of pg_constraint entries.  Per gripe
from Greg Stark.

SQLSTATE error codes required by SQL99 (invalid format, datetime field
overflow, interval field overflow, invalid time zone displacement value).
Also emit a HINT about DateStyle in cases where it seems appropriate.
Per recent gripes.

this variable on the command line.

	http://developer.postgresql.org/~momjian/upgrade_tips_7.3

update to beta2

only scan plans.  Per observation from Rod Taylor.

lumping them into ERRCODE_UNDEFINED_OBJECT/ERRCODE_DUPLICATE_OBJECT.
This seems reasonable since 'object' was meant to refer to 'object in the
database' and a file is outside the database.  Per request from Dave
Cramer.

that HISTSIZE might take effect from my .psqlrc

Andriy Tkachuk

now all that is tested is Rod Taylor's recent addition to allow
this syntax:

    UPDATE ... SET <col> = DEFAULT;

If anyone else would like to add more UPDATE tests, go ahead --
I just wanted to write a test for the above functionality, and
couldn't see an existing test that it would be appropriate
to add to.

Neil Conway

interesting info in verbose mode about the analyzed relation (pages,
rows per block and rows).

Mark Kirkwood

max_connections at initdb time.  Get rid of DEF_NBUFFERS and DEF_MAXBACKENDS
macros, which aren't doing anything useful anymore, and put more likely
defaults into postgresql.conf.sample.

I think this should fix the problem, but since I don't have a reproducable test
case, I can't be sure.  This problem is reported by Kim Ho of redhat, who will
test this fix.  This also includes a test case for the original functionality.

 Modified Files:
 	jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
 	jdbc/org/postgresql/test/jdbc2/ResultSetTest.java

ACT and ACST were already present.  AMT and AMST conflict with the
existing entries for Armenia; no change there for the moment.

syntax '040506' for '04:05:06', as well as '0405' for '04:05:00'.  This
has been broken since 7.2 but was only recently complained of.