Tom Lane [Fri, 19 May 2000 23:00:00 +0000 (23:00 +0000)]
pg_dump barfs on negative values for index column numbers --- like, say,
an index on a table's OID column. Mea maxima culpa ... but how'd we get
through beta with no one noticing this?
Tom Lane [Fri, 19 May 2000 03:22:31 +0000 (03:22 +0000)]
Revise FlushRelationBuffers/ReleaseRelationBuffers per discussion with
Hiroshi. ReleaseRelationBuffers now removes rel's buffers from pool,
instead of merely marking them nondirty. The old code would leave valid
buffers for a deleted relation, which didn't cause any known problems
but can't possibly be a good idea. There were several places which called
ReleaseRelationBuffers *and* FlushRelationBuffers, which is now
unnecessary; but there were others that did not. FlushRelationBuffers
no longer emits a warning notice if it finds dirty buffers to flush,
because with the current bufmgr behavior that's not an unexpected
condition. Also, FlushRelationBuffers will flush out all dirty buffers
for the relation regardless of block number. This ensures that
pg_upgrade's expectations are met about tuple on-row status bits being
up-to-date on disk. Lastly, tweak BufTableDelete() to clear the
buffer's tag so that no one can mistake it for being a still-valid
buffer for the page it once held. Formerly, the buffer would not be
found by buffer hashtable searches after BufTableDelete(), but it would
still be thought to belong to its old relation by the routines that
sequentially scan the shared-buffer array. Again I know of no bugs
caused by that, but it still can't be a good idea.
Tom Lane [Thu, 18 May 2000 01:52:45 +0000 (01:52 +0000)]
Reduce COPY IN lock from AccessExclusive to a more reasonable
RowExclusive (my fault). Also, install a check to prevent people
from trying COPY BINARY to stdout/from stdin. No way that will
work unless we redesign the frontend COPY protocol ... which is
not worth the trouble in the near future ...
Bruce Momjian [Wed, 17 May 2000 16:57:41 +0000 (16:57 +0000)]
The check of class string in configure (line 1732) fails because this class
is in <string> and not in <string.h> on QNX4/egcs-2.91.60.
Probably this can be changed for all platforms. The test in line 1705 uses
<string> as well. Because I am not sure, I havn't this included into the
patch.
doc/Makefile has to be sligthly modified as it has been done for
src/backend/Makefile due to a QNX4 problem (patch attached)
Furthermore src/test/regress/run_check.sh needs to be patched as it has been
done for regress.sh (patch attached). Please note that in the patch the
postmaster is started always with the -i option.
run_check.sh reports the test "limit" as failed, but in reallity it is OK.
regress.sh reports it as OK.
Bruce Momjian [Tue, 16 May 2000 20:48:52 +0000 (20:48 +0000)]
Several compilation and run-time problems occur when building on SGI
IRIX systems using the native compilers. A summary is:
- Various files use "//" as a comment delimiter in c files.
- Problems caused by assuming "char" is signed.
cash.in: building -signed the rules regression test fails as described
in FAQ_QNX4. If CHAR_MAX is "255U" then ((signed char)CHAR_MAX) is -1.
postmaster.c: random number regression test failed without this change.
- Some generic build issues and warning message cleanup.
Tom Lane [Tue, 16 May 2000 02:14:15 +0000 (02:14 +0000)]
Remove configure check for how to abbreviate 'tr A-Z a-z', and instead
just use the portable form,
tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz
There were a bunch of places that weren't paying attention to configure's
result anyway (including configure itself!?); clean them up too.
Peter Mount [Mon, 15 May 2000 21:32:51 +0000 (21:32 +0000)]
Fixed the message Makefile produces after compiling. It still said
about the old Driver class, not the new package. Spotted by
Joseph Shraibman <jks@p1.selectacast.net>
Bruce Momjian [Fri, 12 May 2000 20:54:22 +0000 (20:54 +0000)]
Fix the off by one errors in ResultSet from 6.5.3, and more.
I'm including a diff of
postgresql-7.0/src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java.
I've clearly marked all the fixes I did. Would *someone* who has access
to the cvs please put this in?
Bruce Momjian [Fri, 12 May 2000 18:51:59 +0000 (18:51 +0000)]
This is the second time I've answered this exact same problem in two
days. It seems to be a FAQ, and I think I know why. When creating a 'c'
language function, CREATE FUNCTION is fed the shared object filename,
and seems to succeed. Only when trying to use the function is an error
thrown, by which time the coder thinks something's wrong with executing
the code, not with loading it.
I think I once saw it proposed to load shared objects at function creation
time, but that idea was shot down on the grounds of resident memory bloat,
ISTR. Here's a patch for a compromise: all it does is stat() the file,
just like the loader code does, so that the errors caused by non existent
files, and no directory 'x' permissions (the most common ones, it seems),
get caught while the developer is still thinking about code loading. It
doesn't catch all errors (like the code not being readable by the postgres
user) but seems to catch the most common, without actually opening the file.
Tom Lane [Fri, 12 May 2000 16:10:09 +0000 (16:10 +0000)]
Squash some more CLUSTER bugs. Never has worked on multiple-column
indexes, apparently, nor on functional indexes with more than one input
column (force of natts = 1 was in the wrong branch of IF statement).
Coredumped if source relation contained any uncommitted tuples, due to
failure to test for success return from heap_fetch. Fetched tuple
was passed directly to heap_insert, which clobbers the TID and commit
status in the tuple header it's given, which meant that the source
relation's tuples all got trashed as the copy proceeded. Abort partway
through, and you're left with a lot of missing tuples.
I wonder what else is lurking here ...
Marc G. Fournier [Fri, 12 May 2000 14:33:08 +0000 (14:33 +0000)]
this fixes the bug where setting the entry in he process table no longer works
under FreeBSD ... basically, if setproctitle() exists, use it ...
the draw back right now is the PS_SET_STATUS stuff doesn't work, but am looking
into that one right now ... at lesat now you can see who is connecting where
and from where ...
Tom Lane [Fri, 12 May 2000 01:33:56 +0000 (01:33 +0000)]
Repair list-vs-node confusion that resulted in failure for INNER JOIN ON.
Make it behave correctly when there are more than two tables being
joined, also. Update regression test expected outputs.
Bruce Momjian [Thu, 11 May 2000 04:00:00 +0000 (04:00 +0000)]
Oops, plpgsql didn't have the datetime->timestamp and timespan->interval
mappings. In fact, it had them backward because it was using the 6.5.*
code. Copied them from parser/gram.y, so it is fixed now. Looks like
our first 7.0.1 fix. Oops, seems Tom has beat me to it as I was typing
this.
Tom Lane [Thu, 11 May 2000 03:54:18 +0000 (03:54 +0000)]
Fix CLUSTER ... or at least undo the bit-rot it's suffered since 6.5.
It's still pretty fundamentally bogus :-(.
Freebie side benefit: ALTER TABLE RENAME works on indexes now.
Tom Lane [Fri, 5 May 2000 03:08:20 +0000 (03:08 +0000)]
Accept pg_group as well as pg_shadow data from dumpall script.
Rearrange handling of VACUUMs so that they are certain to be executed
as superuser not some random user; also, do not forget to vacuum
template1 itself.
Tatsuo Ishii [Tue, 2 May 2000 08:13:08 +0000 (08:13 +0000)]
Modify getdatabaseencoding(), pg_encoding_to_char()
pg_char_to_encoding() in multibyte disbaled case so that it does not
throw an error, rather return HARD CODED default value (currently SQL_ASCII).
This would solve the "non-mb backend vs. mb-enabled frontend" problem.
Tom Lane [Sun, 30 Apr 2000 21:29:23 +0000 (21:29 +0000)]
Reset CurrentMemoryContext to TopMemoryContext at the beginning of error
cleanup, ie, as soon as we have caught the longjmp. This ensures that
current context will be a valid context throughout error cleanup. Before
it was possible that current context was pointing at a context that would
get deleted during cleanup, leaving any subsequent pallocs in deep
trouble. I was able to provoke an Assert failure when compiled with
asserts + -DCLOBBER_FREED_MEMORY, if I did something that would cause
an error to be reported by the backend large-object code, because indeed
that code operates in a context that gets deleted partway through xact
abort --- and CurrentMemoryContext was still pointing at it! Boo hiss.