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 ...
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.
Andreas Kardos
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.
David Kaelbling
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.
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?
Joseph Shraibman
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.
What do you think?
Ross
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 ...
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 ...
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.
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.
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.
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.
cases where joinclauses were present but some joins have to be made
by cartesian-product join anyway. An example is
SELECT * FROM a,b,c WHERE (a.f1 + b.f2 + c.f3) = 0;
Even though all the rels have joinclauses, we must join two of them
in cartesian style before we can use the join clause...
than BIND_DEFERRED. That way, if the loaded library has unresolved
references, shl_load fails cleanly. As we had it, shl_load would
succeed and then the dynlinker would call abort() when we try to call
into the loaded library. abort()ing a backend is uncool.
always failed if Perl makefile's INSTALLSITELIB variable was specified
in terms of another variable. Fix by adding an echo-installdir target
to the Perl makefile, which the upper-level Makefile can invoke.
libpq++.h contained copies of the class declarations in the other libpq++
include files, which was bogus enough, but the declarations were not
completely in step with the real declarations. Remove these in favor
of including the headers with #include. Make PgConnection destructor
virtual (not absolutely necessary, but seems like a real good idea
considering the number of subclasses derived from it). Give all classes
declared private copy constructors and assignment operators, to prevent
compiler from thinking it can copy these objects safely.
compiler than the one selected to build Postgres with. It was trying
to feed Postgres-compiler switches to Tcl's compiler. (Seen this before
with the perl5 interface...) Fix to use only CFLAGS taken from Tcl's
configure information, plus -I which is pretty universal.
unless you feed it -Aa or -Ae switch. Autoconf does not know about this,
but we can fix it in the hpux_cc template file. I knew templates were
good for something ;-)
to give wrong results: it should be looking at inJoinSet not inFromCl.
Also, make 'modified' flag be local to ApplyRetrieveRule: we should
append a rule's quals to the query iff that particular rule applies,
not if we have fired any previously-considered rule for the query!
(SELECT FROM table*). Cause was reference to 'eref' field of an RTE,
which is null in an RTE loaded from a stored rule parsetree. There
wasn't any good reason to be touching the refname anyway...
table for an average of NTUP_PER_BUCKET tuples/bucket, but cost_hashjoin
was assuming a target load of one tuple/bucket. This was causing a
noticeable underestimate of hashjoin costs.
