tlist and qual are NULL. It ought to handle these the same as the cases
where tlist contains only constant expressions, ie, be willing to generate
a Result-node plan. This did not use to matter, but it does now because
union_planner will flatten the tlist when aggregates are present. Thus,
'select count(1) from table' now causes query_planner to be given a null
tlist, and to duplicate 6.4's behavior we need it to give back a Result
plan rather than refusing the query. 6.4 was arguably doing the Wrong
Thing for this query, but I'm not going to open a semantics issue right
before 6.5 release ... can revisit that problem later.
returned NULL, which it will do in some cases where an elog(ERROR) would
probably be more appropriate. For the moment, generate a not-very-
informative error message rather than proceeding to certain coredump.
Probably ought to think about making query_planner elog instead of
returning NULL, but this is at least a safe change for now.
pointer to palloc'd but uninitialized memory. This is not cool; anyone looking
at the returned 'tuple' would at best coredump and at worst behave in a
bizarre and irreproducible way. Fix it to return a predictable value,
namely a correctly-set-up palloc'd tuple containing zero attributes.
I believe this fix is both safe and critical.
this one could be useful for people experiencing out-of-memory crashes while
executing queries which retrieve or use a very large number of tuples.
The problem happens when storage is allocated for functions results used in
a large query, for example:
select upper(name) from big_table;
select big_table.array[1] from big_table;
select count(upper(name)) from big_table;
This patch is a dirty hack that fixes the out-of-memory problem for the most
common cases, like the above ones. It is not the final solution for the
problem but it can work for some people, so I'm posting it.
The patch should be safe because all changes are under #ifdef. Furthermore
the feature can be enabled or disabled at runtime by the `free_tuple_memory'
options in the pg_options file. The option is disabled by default and must
be explicitly enabled at runtime to have any effect.
To enable the patch add the follwing line to Makefile.custom:
CUSTOM_COPT += -DFREE_TUPLE_MEMORY
To enable the option at runtime add the following line to pg_option:
free_tuple_memory=1
Massimo
/*
* Read above about cases when !ItemIdIsUsed(Citemid)
* (child item is removed)... Due to the fact that
* at the moment we don't remove unuseful part of
* update-chain, it's possible to get too old
* parent row here. Like as in the case which
* caused this problem, we stop shrinking here.
* I could try to find real parent row but want
* not to do it because of real solution will
* be implemented anyway, latter, and we are too
* close to 6.5 release. - vadim 06/11/99
*/
if (Ptp.t_data->t_xmax != tp.t_data->t_xmin)
...
1. Using 100 digits after decimal point on the default
make runtest.
2. Using 1000 digits after decimal point in a new target
make bigtest.
At the end of 'make runtest', a hint about the new bigtest is
printed.
Jan
and possibly for other cases too:
DO NOT cache status of transaction in unknown state
(i.e. non-committed and non-aborted ones)
Example:
T1 reads row updated/inserted by running T2 and cache T2 status.
T2 commits.
Now T1 reads a row updated by T2 and with HEAP_XMAX_COMMITTED
in t_infomask (so cached T2 status is not changed).
Now T1 EvalPlanQual gets updated row version without HEAP_XMIN_COMMITTED
-> TransactionIdDidCommit(t_xmin) and TransactionIdDidAbort(t_xmin)
return FALSE and T2 decides that t_xmin is not committed and gets
ERROR above.
It's too late to find more smart way to handle such cases and so
I just changed xact status caching and got rid TransactionIdFlushCache()
from code.
Changed: transam.c, xact.c, lmgr.c and transam.h - last three
just because of TransactionIdFlushCache() is removed.
2. heapam.c:
T1 marked a row for update. T2 waits for T1 commit/abort.
T1 commits. T3 updates the row before T2 locks row page.
Now T2 sees that new row t_xmax is different from xact id (T1)
T2 was waiting for. Old code did Assert here. New one goes to
HeapTupleSatisfiesUpdate. Obvious changes too.
3. Added Assert to vacuum.c
4. bufmgr.c: break
Assert(buf->r_locks == 0 && !buf->ri_lock)
into two Asserts.
after ExecEndNode. It must be done! Or we'll be out of free
tuple slots very soon, though slots are freed by ExecEndNode
and ready for reusing.
We didn't see this problem before because of
int nSlots = ExecCountSlotsNode(plan);
TupleTable tupleTable = ExecCreateTupleTable(nSlots + 10);
/* why add ten? - jolly */
code in InitPlan - i.e. extra 10 slots. Simple select uses
3 slots and so it was possible to re-use evaluation plan
3 additional times and didn't get
elog(NOTICE, "Plan requires more slots than are available");
elog(ERROR, "send mail to your local executor guru to fix this");
Changes are obvious and shouldn't be problems with them.
Though, I added Assert(epqstate->es_tupleTable->next == 0)
before EvalPlanQual():ExecInitNode and we'll notice if
something is still wrong. Is it better to change Assert
to elog(ERROR) ?
1. check whether the program is being executed in $PGDATA/.. This is
necessary if the data tree is not in the standard place, as is the
case with the Debian distribution (because of Debian policy).
2. give a clearer error message if the dumped data structure fails to
be loaded.
Oliver Elphick
SHARED_LIB:
needs to be changed to:
SHARED_LIB:-lc
I think this was also needed on AIX 4.2. Comments Please !!
If nobody objects, I suggest to make this change, since it cannot
break AIX 4.2 and is necessary on AIX 4.3
Andreas
> (native win32, not cygnus).
> It does the following:
> Patches two win32.mak files to DEFINE HAVE_VSNPRINTF and
> HAVE_STRDUP. This is required to build at all.
> Bumps the version number on libpq.dll from 6.4 to 6.5.
> Required for install programs to work.
> Adds defintions for BLCKSZ and MAXIMUM_ALIGN to "win32.h" in
> the client-side libpiq directory.
>
> All these files are only used when building on native win32,
> so it should be safe I think.
>
> Again, really sorry to throw this in so late, but I would
> hate to do the same thing as with 6.4 (which required 6.4.1
> to at all compile on Win32).
>
> Thanks,
>
> //Magnus
a non-leading % would be put into the >=/<= patterns. Also, repair
longstanding confusion about whether %% means a literal %%. The SQL92
doesn't say any such thing, and textlike() knows that, but gram.y didn't.
2. varsup.c:ReadNewTransactionId(): don't read nextXid from disk -
this func doesn't allocate next xid, so ShmemVariableCache->nextXid
may be used (but GetNewTransactionId() must be called first).
3. vacuum.c: change elog(ERROR, "Child item....") to elog(NOTICE) -
this is not ERROR, proper handling is just not implemented, yet.
4. s_lock.c: increase S_MAX_BUSY by 2 times.
5. shmem.c:GetSnapshotData(): have to call ReadNewTransactionId()
_after_ SpinAcquire(ShmemIndexLock).
PgDatabase::DisplayTuples and PgDatabase::PrintTuples. This is incorrect
according to strict interpretation of the C++ spec, and some compilers
will reject it. Also silence g++ warning about unused parameter.
the gettimeofday doesn't compile under Linux with glibc2 because
the DST_NONE constant is no more defined. It seems that this code
(written by me) has always be wrong but for some reason working.
From: Massimo Dal Zotto <dz@cs.unitn.it>
the default target is 'install' instead of 'all'. So if you do a
make without target you actually do a make install, which is not
what one normally expects from a standard makefile.
From: Massimo Dal Zotto <dz@cs.unitn.it>
the ecpg Makefiles use a variable DESTDIR which is never defined
except by debian/rules makefile, in which case the ecpg makefiles
expand wrong pathnames. If we want to support a DESTDIR root it
must be done consistently in all the makefiles, not just in ecpg.
From: Massimo Dal Zotto <dz@cs.unitn.it>
they were confusing because the large object tables themselves are not
shown. (Besides, if you've got hundreds or thousands of large objects,
you really don't want to see 'em at all.)
Also, suppress all indexes from the \z ACL listing, since indexes have
no meaningful protection information.
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
^^^^ required
Also note that SET TRANSACTION ISOLATION LEVEL change
isolevel for _current_ transaction, in accordance with
standard, not for session (ALTER SESSION is used in Oracle,
but it's not implemented currently).
And I would don't mention SET XACTISOLEVEL TO ...
form at all.
Please update set.sgml - I failed to understand all these
SET TIME ZONE { '<REPLACEABLE CLASS="PARAMETER">
now.
for Vadim
transactions will not assume that MyProc transaction was committed
before snapshot calculations. With old MyProc->xid assignment
(in xact.c:StartTransaction()) there was ability to see the same
row twice (I used gdb for this)!...
2. Assignments of InvalidTransactionId to MyProc->xid and MyProc->xmin
are moved from xact.c:CommitTransaction() to
xact.c:RecordTransactionCommit() - this invalidation must be done
before releasing transaction locks or bad (too high) XmaxRecent value
might be used by vacuum ("ERROR: Child itemid marked as unused"
reported by "Hiroshi Inoue" <Inoue@tpf.co.jp>; once again, gdb
allowed me reproduce this error).
{
Oid relId;
Oid dbId;
union
{
BlockNumber blkno;
TransactionId xid;
} objId;
>
> Added:
> /*
> * offnum should be part of objId.tupleId above, but would increase
> * sizeof(LOCKTAG) and so moved here; currently used by userlocks only.
> */
> OffsetNumber offnum;
uint16 lockmethod; /* needed by userlocks */
} LOCKTAG;
gmake clean required...
User locks are ready for 6.5 release...
2. Get rid of locking when updating statistics in vacuum.
3. Use QuerySnapshot in COPY TO and call SetQuerySnashot
in main tcop loop before FETCH and COPY TO.
redundant) SearchSysCache searches per table column in an INSERT, which
accounted for a good percentage of the CPU time for INSERT ... VALUES().
Now it only does two searches in the typical case.
through MAXBACKENDS array entries used to be fine when MAXBACKENDS = 64.
It's not so cool with MAXBACKENDS = 1024 (or more!), especially not in a
frequently-used routine like SIDelExpiredDataEntries. Repair by making
procState array size be the soft MaxBackends limit rather than the hard
limit, and by converting SIGetProcStateLimit() to a macro.
do the right thing: look for a NOTICE message from the backend before we
close our side of the socket. 6.4 libpq did not reliably print the backend's
hara-kiri message, 'The Postmaster has informed me ...', because it only
did the right thing if connection closure was detected during a read
attempt instead of a write attempt.
BT_READ/BT_WRITE are BUFFER_LOCK_SHARE/BUFFER_LOCK_EXCLUSIVE now.
Also get rid of #define BT_VERSION_1 - we use version 1 as default
for near two years now.
not be marked inFromCl any longer. Otherwise the planner gets confused
and joins over them where in fact it does not have to.
Adjust hasSubLinks now with a recursive lookup - could be wrong in
multi action rules because parse state isn't reset correctly and all
actions in the rule are marked hasSubLinks if one of them has.
Jan
aggregate functions, as in
select a, b from foo group by a;
The ungrouped reference to b is not kosher, but formerly we neglected to
check this unless there was an aggregate function somewhere in the query.
this file in interfaces/
It will all need to be checked in. I used the char *rcsid[] method for
cvs ids so it can be strings | grep'd to find version numbers. The new
version for the library is 3.0.
Run configure from src/ to create the Makefile and it should be good to
go.
I did minimal documentation references in the README, I'll see if I can
get something to Tom Lockhart rather quickly.
Vince.
SelectStmt and CursorStmt tried to parse FOR UPDATE ... / FOR READ ONLY.
Cursor now checks that it is read only by looking at forUpdate of Query.
SelectStmt handles FOR READ ONLY too.
Jan
will pass through rather than spitting up. This is necessary to handle
cases where coerce_type causes a subexpression to be retransformed, as in
SELECT count(*) + 1.0 FROM table
remove optimizer's arbitrary limit on how large a join it will use hashing
for. (The limit was too large to prevent the problems we'd been seeing,
anyway...)
fixed-size hashtable. This should prevent 'hashtable out of memory' errors,
unless you really do run out of memory. Note: target size for hashtable
is now taken from -S postmaster switch, not -B, since it is local memory
in the backend rather than shared memory.
looks
like someone just didn't add support for multiple segments for
truncation.
The following patch seems to do the right thing, for me at least.
It passed my tests, my data looks right(no data that shouldn't be in
there) and regression is ok.
Ole Gjerde
segments, and my indexes had 3(Yes, it DOES work!).
DROP TABLE removed ALL segments from the table, but only the main index
segment.
So it looks like removing the table itself is using mdunlink in md.c,
while removing indexes uses FileNameUnlink() which only unlinks 1 file.
As far as I can tell, calling FileNameUnlink() and mdunlink() is basically
the same, except mdunlink() deletes any extra segments.
I've done some testing and it seems to work. It also passes regression
tests(except float8, geometry and rules, but that's normal).
If this patch is right, this fixes all known multi-segment problems on
Linux.
Ole Gjerde
configtype.patch simply fixes a typo in config.h.in
pg_dump.c.patch Updates a bunch of error messages to include a reason
from
the backend, and also removes a couple of unnecessary
if's
Ole Gjerde
lists are now plain old garden-variety Lists, allocated with palloc,
rather than specialized expansible-array data allocated with malloc.
This substantially simplifies their handling and eliminates several
sources of memory leakage.
Several basic types of erroneous queries (syntax error, attempt to
insert a duplicate key into a unique index) now demonstrably leak
zero bytes per query.
The
offending code
has been removed, the action is now always dependent :-)
I suggest the following patch, to finally make trigger regression happy
again:
<<refint1.patch>>
After that you can remove the following from TODO:
Remove ERROR: check_primary_key: even number of arguments should be
specified
Trigger regression test fails
Andreas
and lock syntax as fully parsed tokens.
Two keywords for isolation are non-reserved SQL92
(COMMITTED, SERIALIZABLE).
All other new keywords are non-reserved Postgres (not SQL92)
(ACCESS, EXCLUSIVE, MODE, SHARE).
Add syntax to allow CREATE [GLOBAL|LOCAL] TEMPORARY TABLE, throwing an
error if GLOBAL is specified.
constraints. Reported by Tom Lane.
Now, check for duplicate indices and retain the one which is a primary-key.
Adjust elog NOTICE messages to surround table and column names with single
quotes.
-d4 now prints compressed trees from nodeToString()
-d5 prints pretty trees via nodeDisplay()
new pg_options: pretty_plan, pretty_parse, pretty_rewritten
Jan
on connection. This patch changes it to use PQconnectdb rather than
{fe_setauthsvc,PQsetdb}. This still isn't the complete solution, as
there
is no provision for user,password in class PgEnv, but it does get rid of
the error message. Tested with gcc version egcs-2.91.60 19981201
(egcs-1.1.1 release) under NetBSD-1.3K/i386.
Cheers,
Patrick Welche
files to be closed automatically at transaction abort or commit, should
they still be open. Also close any still-open stdio files allocated with
AllocateFile at abort/commit. This should eliminate problems with leakage
of file descriptors after an error. Also, put in some primitive buffered-IO
support so that psort.c can use virtual files without severe performance
penalties.
"SYSTEM", and unpack the files in the uuencoded .tar.gz file at the end in
src/test/regress so that the int2, int4 and geometry tests pass on NetBSD/i386.
They just fail on different wording of error messages and eg printing "0"
rather than "-0". At a guess the same will be true for the other NetBSD ports,
but I can't test them.
Cheers,
Patrick
about certain to fail anytime it decided the relation to be hashed was
too big to fit in memory --- the code for 'batching' a series of hashjoins
had multiple errors. I've fixed the easier problems. A remaining big
problem is that you can get 'hashtable out of memory' if the code's
guesstimate about how much overflow space it will need turns out wrong.
That will require much more extensive revisions to fix, so I'm committing
these fixes now before I start on that problem.
arrayfuncs.patch fixes a small bug in my previous patches for
arrays
array-regress.patch adds _bpchar and _varchar to regression tests
--
Massimo Dal Zotto
been applied. The patches are in the .tar.gz attachment at the end:
varchar-array.patch this patch adds support for arrays of bpchar() and
varchar(), which where always missing from postgres.
These datatypes can be used to replace the _char4,
_char8, etc., which were dropped some time ago.
block-size.patch this patch fixes many errors in the parser and other
program which happen with very large query statements
(> 8K) when using a page size larger than 8192.
This patch is needed if you want to submit queries
larger than 8K. Postgres supports tuples up to 32K
but you can't insert them because you can't submit
queries larger than 8K. My patch fixes this problem.
The patch also replaces all the occurrences of `8192'
and `1<<13' in the sources with the proper constants
defined in include files. You should now never find
8192 hardwired in C code, just to make code clearer.
--
Massimo Dal Zotto
to save a little bit of backend startup time. This way, the first
backend started after a VACUUM will rebuild the init file with up-to-date
statistics for the critical system indexes.
the database encoding and the client encoding match the encoding expected
by the test. So, force both of them to be set from the MULTIBYTE
environment var. This allows regress tests to be run successfully in
multibyte environments other than the compiled-in default.
it failed to cover the case where high bits of char are 100 or 101.
Not sure if fix is right, but it agrees with pg_utf_mblen ... and it
doesn't lock up ...
can be generated in a buffer and then sent to the frontend in a single
libpq call. This solves problems with NOTICE and ERROR messages generated
in the middle of a data message or COPY OUT operation.
instead of doing a kill(self, SIGQUIT) and expecting the signal handler
to do it. Also, clean up inconsistent definitions of the sigjmp buffer
in the several files that already referenced it.
and related files. Also remove float.c's gratuitous redeclaration of
isinf() ... looks like there are more decls in there that ought to be
in config.h, but I'll leave well enough alone for now ...
expression context (ie, not at the top level of a WHERE clause). Examples
like this one work now:
SELECT name, value FROM t1 as touter WHERE
(value/(SELECT AVG(value) FROM t1 WHERE name = touter.name)) > 0.75;
delete the default argument from the node. This prevents the executor
from spitting up on the untransformed argument expression. Typical
failure was:
select (case f1 when 'val' then 'subst' else f1 end) from t1;
ERROR: copyObject: don't know how to copy 704
MyProcPid global variable is set to 0 when postgres starts as a command
(not as a backend daemon). This leads issuing SIGQUIT to the process group,
not the process itself. As a result, parent sh gets core dumped in the
Wisconsin benchmark test.
- change temp -> temp_bench ("temp" is now a reserved word)
- fix bugs in queries
- add -B 256 option to run the postgres command
(without this, postgres seems to fail with hashjoin)
rather than reusing the input storage.
Also made the same fix to int8smaller(), though there wasn't a symptom,
and went through and verified that other pass-by-reference data types
do the same thing. Not an issue for the by-value types.
relation, rather than zeroes. This prevents the optimizer from making
foolish choices (ie, using nested-loop plans) on never-yet-vacuumed tables.
This is a hack, of course. Keeping accurate track of these statistics
would be a cleaner solution, but it's far from clear that it'd be worth
the cost of doing so. In any case we're not going to do that for 6.5.
In the meantime, this quick hack provides a useful performance improvement
in the regression tests and in many real-world scenarios.
in rules regression test, in order to eliminate bogus test 'failures'
that occur due to platform-dependent and join-implementation-dependent
ordering of tuples. I'm not sure that I got all of the SELECTs that need
ordering clauses --- we may need some more. But this takes care of the
diffs between my platform and Jan's.
sourced with \i (tried to read data from the terminal, rather than from
the source file; this breaks pg_dump scripts read with \i). Also, \o file
followed by COPY TO STDOUT wrote to terminal not designated file.
All better now.
time zone.
Previously, localtime() rotated a date with a day of month field which
exceeded the actual range into the next months, masking the fact that
a bad date had been specified.
Regression tests pass.
Previously, dates falling within Unix system time range were run through
a call to localtime() to get the time zone, if it was not specified.
This had the effect that dates with DOMs which were larger than would be
valid for that month were "rotated" into the following months.
syntax for CREATE OPERATOR with SORT parameters. Fixed.
It is now actually possible to dump and reload a database containing
fully specified user-definable operators ...
indexes.
1. Index Scan using plural indexids never scan backward
as to the order of indexids.
2. The cursor using Index scan is not usable after moving
past the end.
This patch solves above bugs.
Moreover the change of _bt_first() would be useful to extend
ORDER BY patch by Jan Wieck for all descending order cases.
Hiroshi Inoue
not-yet-defined operator in commutator, negator, etc links. This is
necessary in order to ensure that a pg_dump dump of user-defined operators
can be reloaded. There may still be a bug lurking here, because it's
provoking a 'Buffer Leak' notice message in one case. See my mail to
pgsql-hackers.
hashjoin's hashFunc() so that it does the right thing with pass-by-value
data types (the old code would always return 0 for int2 or char values,
which would work but would slow things down a lot). Extend opr_sanity
regress test to catch more kinds of errors.
called through fmgr. Someday we should try to actually execute the function,
but that looks like it might be a major feature addition.
Not something to try during beta phase.
it with configure-script tests to see whether const, inline, volatile, etc
work or not. (Curiously, configure was already doing the work to see if
const and inline were OK, but the results were not getting plugged into
config.h :-(.)
1. Fix problems of PAGER and \? command
2. Add -E option that shows actual queries sent by \dt and friends
3. Add version number in startup banners for psql
There are two subdirectories (ISO8859-7 and koi8-to-win1251) containing
tests for Greek locale and server<=>client recoding feature (recently
submitted by Tatsuo Ishii <t-ishii@sra.co.jp>; we've debugged his patches
together in the field of Cyrillic support).
function is found in prosrc field of pg_proc, not proname. This allows
multiple aliases of a built-in to all be implemented as direct builtins,
without needing a level of indirection through an SQL function. Replace
existing SQL alias functions with builtin entries accordingly.
Save a few K by not storing string names of builtin functions in fmgr's
internal table (if you really want 'em, get 'em from pg_proc...).
Update opr_sanity with a few more cross-checks.
2. Much faster btree tuples deletion in the case when first on page
index tuple is deleted (no movement to the left page(s)).
3. Remember blkno of new root page in BTPageOpaque of
left/right siblings when root page is splitted.
I have solved some problems with dynamic loading on NT. It is possible
to
run succesfully both trigger and plpgsql regression tests. The patch is
in
the included file "diff".
Dan
but others declare it as extern char *. gcc complains (quite rightly too).
Worked around it by rearranging the order of inclusions so that we don't
have to explicitly declare yytext; this should work with either variant.
change functionality, but makes the code more ANSI C'ish.
My AIX xlc compiler barfs on all of these. Can someone please
review and apply to current.
<<port.patch>>
Thanks
Andreas
