just the significant fields of FunctionCallInfoData, rather than MemSet'ing
the whole struct to zero. Unused positions in the arg[] array will
thereby contain garbage rather than zeroes. This buys back some of the
performance hit from increasing FUNC_MAX_ARGS. Also tweak tuplesort.c
code for more speed by marking some routines 'inline'. All together
these changes speed up simple sorts, like count(distinct int4column),
by about 25% on a P4 running RH Linux 7.2.
client
utilities (libpq.dll and psql.exe) for win32 (missing defines,
adjustments to
includes, pedantic casting, non-existent functions) per:
http://developer.postgresql.org/docs/postgres/install-win32.html.
It compiles cleanly under Windows 2000 using Visual Studio .net. Also
compiles clean and passes all regression tests (regular and contrib)
under Linux.
In addition to a review by the usual suspects, it would be very
desirable for someone well versed in the peculiarities of win32 to take
a look.
Joe Conway
be able to do that, but the ability seems to have got lost in the
shuffle). Add a -o nextOID switch for completeness. Improve the
documentation to explain how and why to use these switches.
so that precision of result is always at least as good as you'd get from
float8 arithmetic (ie, always at least 16 digits of accuracy). Per
pg_hackers discussion a few days ago.
Vacuum must not advance pg_database.datvacuumxid nor truncate CLOG
unless it's processed *all* tables in the database. Vacuums run by
unprivileged users don't count.
(Beats head against nearest convenient wall...)
no reason to worry about the tuple commit status bits until the tuple
is inserted in a relation by heapam.c. Also, improve comments for
heap_addheader().
VACUUM FULL tuple moves. Store full-width t_infomask in WAL, rather
than storing low 8 bits and expecting to be able to reconstruct upper
bits. While at it, remove redundant t_oid field from WAL headers
(the OID, if present, is now recorded in the data portion of the tuple).
WAL version number bumped --- this does not force an initdb, you can
instead run pg_resetxlog after a clean shutdown of the old postmaster.
let's say this patch superscedes the previous one.
I have also attached a patch addressing the similar memory leak problem in
plpython. This includes a slight adjustment of the tests in the source
directory. The patch also includes a cosmetic change to remove a compiler
warning although I think the change makes the code look worse though.
BTW, by my reckoning the memory leak would occur with prepared plans and
without. If that is not the case then I've been barking up the wrong tree.
Nigel J. Andrews
ProcKill instead, where we still have a PGPROC with which to wait on
LWLocks. This fixes 'can't wait without a PROC structure' failures
occasionally seen during backend shutdown (I'm surprised they weren't
more frequent, actually). Add an Assert() to LWLockAcquire to help
catch any similar mistakes in future. Fix failure to update MyProcPid
for standalone backends and pgstat processes.
executor should not return the tuple as successfully marked, because in
fact it's been deleted. Not clear that this case has ever been seen
in practice (I think you'd have to write a SELECT FOR UPDATE that calls
a function that deletes some row the SELECT will visit later...) but we
should be consistent. Also add comments to several other places that
got it right but didn't explain what they were doing.
up to
reaching the hard limit. After opening 16(=current REST_START value)
results via pg_exec, the next pg_exec tries to find an empty slot
forever :-( . In PgSetResultId file pgtclId.c in the for loop there
has to be done a break, if res_max ist reached. The piece of code
should look like
if (resid == connid->res_max)
{
resid = 0;
break; /* the break as to be added */
}
now everything works (double available results after reaching
RES_START up to reaching RES_HARD_MAX)
Gerhard Hintermayer
contains the correct statistics. This is a partial solution for the
problem of allowing concurrent CREATE INDEX commands: unless they commit
at nearly the same instant, the second one will see the first one's
pg_class updates as committed, and won't try to update again, thus
avoiding the 'tuple concurrently updated' failure.
even when dealing with a nailed-in-cache relation; otherwise, following
VACUUM truncation of a system catalog, other backends might have
unreasonably large values of these fields.
