errors. VACUUM normally compacts the table back-to-front, and stops
as soon as it gets to a page that it has moved some tuples onto.
(This logic doesn't make for a complete packing of the table, but it
should be pretty close.) But the way it was checking whether it had
got to a page with some moved-in tuples was to look at whether the
current page was the same as the last page of the list of pages that
have enough free space to be move-in targets. And there was other
code that would remove pages from that list once they got full.
There was a kluge that prevented the last list entry from being
removed, but it didn't get the job done. Fixed by keeping a separate
variable that contains the largest block number into which a tuple
has been moved. There's no longer any need to protect the last element
of the fraged_pages list.
Also, fix NOTICE messages to describe elapsed user/system CPU time
correctly.
Instead of hard-wiring one result file per platform, there is a map file
'resultmap' that says which one to use --- a lot like template/.similar.
I have only created entries in resultmap for my own platform (HPUX) so
far; feel free to add lines for other platforms.
which is broken in some weird way that I don't understand. I think it
may be exposing a bug in the new psql --- for one thing, I get different
results when I run psql by hand than the regress script gets. What
the heck???
quote_postgres(...) in ecpglib.c.
The code in CVS reads:
quote_postgres(char *arg, int lineno)
{
char *res = (char *) ecpg_alloc(2 * strlen(arg) + 3, lineno);
int i,
ri = 0;
if (!res)
return (res);
res[ri++] = '\'';
for (i = 0, ri=0; arg[i]; i++, ri++)
{
switch (arg[i])
{
case '\'':
res[ri++] = '\'';
break;
case '\\':
res[ri++] = '\\';
break;
default:
;
}
The problem here is that ri is reset to 0, thus overwriting the initial
quote.
Stephen Birch
if presented an uninitialized (all zeroes) page. The system no longer
crashes hard if an all-zeroes page is present in a relation. There seem
to be some boundary conditions where a page will be appended to a relation
and zeroed, but its page header is never initialized; until we can track
down and fix all of those, robustness seems like a good idea.
Also, clean up some obsolete and downright wrong comments.
1) datetime_pl_span() added the seconds field before adding the months
field. This lead to erroneous results for e.g.
select datetime '1999-11-30' + timespan '1 mon - 1 sec';
Reverse the order of operations to add months first.
2) tm2timespan() did all intermediate math as integer, converting to double
at the very end. This resulted in hidden overflows when given very large
integer days, hours, etc. For example,
select '74565 days'::timespan;
produced the wrong result. Change code to ensure that doubles are used
for intermediate calculations.
Thanks to Olivier PRENANT <ohp@pyrenet.fr> and
Tulassay Zsolt <zsolt@tek.bke.hu> for problem reports and to Tom Lane for
accurate analyses.
during InitProcessingMode and the CurrentTransactionState was neither
TRANS_DEFAULT nor TRANS_DISABLED. Unfortunately, after someone's recent
change to start the transaction manager earlier in startup than it used
to be started, that caused an abort() and consequent database system
reset on quite harmless errors (such as rejecting an invalid user name!).
As far as I can see, the test on CurrentTransactionState was completely
useless anyway, so I've removed it.
relcache entry no longer leaks a small amount of memory. index_endscan
now releases all the memory acquired by index_beginscan, so callers of it
should NOT pfree the scan descriptor anymore.
I finally got around to schlepping through pg_dump, to finish what I started
about three months (or more) ago. Attached is a gzipped diff file to apply
in the bin/pg_dump directory. This should remove all string length
dependencies, except one, which I'm working on. It has been through some
rudimentary unit testing, but that's about it, so if any of you would give
it a more strenuous run-through, I'd be grateful for the feedback.
Cheers...
Ansley, Michael
SELECT null::text;
SELECT int4fac(null);
work as expected now. In some cases a NULL must be surrounded by
parentheses:
SELECT 2 + null; fails
SELECT 2 + (null); OK
This is a grammatical ambiguity that seems difficult to avoid. Other
than that, NULLs seem to behave about like you'd expect. The internal
implementation is that NULL constants are typed as UNKNOWN (like
untyped string constants) until the parser can deduce the right type.
Locate path of postmaster in a portable way (stolen from initdb)
Add postmaster.opts.default.sample which should be copied into
$PGLIB in the installtion process. Also, it will be installed into
$PGDATA while initdb is running.
a ".pgc " extension. The second patch fixes a coredump when there is
more than one input file (in that case, cur and types were not set to
NULL before processing the second f ile)
The patch below modifies the accepted grammar of ecpg to accept
FETCH [direction] [amount] cursor name
i.e. the IN|FROM clause becomes optional (as in Oracle and Informix).
This removes the incompatibility mentioned in section "Porting From
Other RDBMS Packages" p169, PostgreSQL Programmer's Guide. The grammar
is modified in such a way as to avoid shift/reduce conflicts. It does
not accept the statement "EXEC SQL FETCH;" anymore, as the old grammar
did (this seems to be a bug of the old grammar anyway).
This patch cleans up the handling of space characters in the scanner;
some patte rns require \n to be in {space}, some do not. A second fix is
the handling of cpp continuati on lines; the old pattern did not match
these. The parser is patched to fix an off-by-one error in the #line
directives. The pa rser is also enhanced to report the correct location
of errors in declarations in the "E XEC SQL DECLARE SECTION". Finally,
some right recursions in the parser were replaced by left-recursions.
This patch adds preprocessor directives to ecpg; in particular
EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF and EXEC SQL ENDIF
"EXEC SQL IFDEF" is used with defines made with "EXEC SQL DEFINE" and
defines, specified on the command line with -D. Defines, specified on
the command line are persistent across multiple input files. Defines can
be nested up to a maximum level of 128 (see patch). There is a fair
amount of error checking to make sure directives are matched properly. I
need preprocessor directives for porting code, that is written for an
Informix database, to a PostgreSQL database, while maintaining
compatibility with the original code. I decided not to extend the
already large ecpg grammar. Everything is done in the scanner by adding
some states, e.g. to skip all input except newlines and directives. The
preprocessor commands are compatible with Informix. Oracle uses a cpp
replacement.
Rene Hogendoorn
with DEC C.
DEC C doesn't handle double values greater than DBL_MAX, but some
PostgreSQL geo functions assign greater than DBL_MAX values to some vars
in some special cases - that couses SIGFPE. I dunno if that is the only place
to fix to work well with DEC C.
Kirill Nosov.
rather than returning a NaN for bogus input to pow(). Namely, HPUX 10.20.
I think this is sufficient evidence for what I thought all along, which
is that the float.c code *must* look at errno whether finite() exists or
not.
> > for them to actually set out and do it. Many new users are
> > of the not-so-knowledgable variety, and shell scripting isn't
> > something they want to undertake.
>
> Can someone modify the vacuumdb shell script to do that?
i tried it... it seems to work
neko@kredit.sth.sz
initdb. No more obscure dependencies on environment variables or paths.
It
now finds the templates and the right postgres itself (with cmd line
options as fallback). It also no longer depends on $USER (su safe), and
doesn't advertise that --username allows you to install the db as a
different user, since that doesn't work anyway. Also, recovery and
cleanup
on all errors. Consistent options, clearer documentation.
Please take a look at this and adopt it if you feel it's safe enough. I
have simulated all the stupid circumstances I could think of, but you
never know with shell scripts.
Oh yeah, you can give the postgres user a default password now.
--
Peter Eisentraut Sernanders väg 10:115
I sending promised patch with:
* getopt_long() - for pg_dump (portable)
* and "Usage: " changes in scripts in src/bin/
- this changes are cosmetic only, not change any
feature ...etc.
All PostgreSQL routines (scripts) support now long options and
help's output is alike for all scripts and all support -? or --help.
Karel
Karel Zak <zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/
>go about this. That will risk breaking existing applications that use
>those names as column names.
>
>It should actually almost work to write sq.nextval as things stand,
>because Postgres has for a long time considered table.function and
>function(table) to be interchangeable notations for certain kinds of
>functions. nextval doesn't seem to be one of that kind of function,
>at the moment. I'd suggest leaving the grammar as it was, and taking a
>look at ParseFuncOrColumn in parse_func.c to see if you can't persuade
>it to accept the sequence functions in that style.
OK, good point. I tried to implement it somewhere else and ended up
extending transformAttr. Attached you'll find the patch.
Jeroen van Vianen
didn't have time for documentation yet, but I'll write some. There are
still some things to work out what happens when you alter or drop users,
but the group stuff in and by itself is done.
--
Peter Eisentraut Sernanders väg 10:115
equality. The lobits macro is wrong and extracts the wrong set of
bits out of the structure.
To exhibit the problem:
select '000000:000000'::macaddr = '000000:110000'::macaddr ;
?column?
--------
t
(1 row)
Daniel Boyd
triggered
> function now returns the right datatype.
Oops, I got crossed up with Jan's improvements. Ignore this.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
anywhere from zero to two TODO items.
* Allow flag to control COPY input/output of NULLs
I got this:
COPY table .... [ WITH NULL AS 'string' ]
which does what you'd expect. The default is \N, otherwise you can use
empty strings, etc. On Copy In this acts like a filter: every data item
that looks like 'string' becomes a NULL. Pretty straightforward.
This also seems to be related to
* Make postgres user have a password by default
If I recall this discussion correctly, the problem was actually that the
default password for the postgres (or any) user is in fact "\N", because
of the way copy is used. With this change, the file pg_pwd is copied out
with nulls as empty strings, so if someone doesn't have a password, the
password is just '', which one would expect from a new account. I don't
think anyone really wants a hard-coded default password.
Peter Eisentraut Sernanders väg 10:115
* Document/trigger/rule so changes to pg_shadow recreate pg_pwd
I did it with a trigger and it seems to work like a charm. The function
that already updates the file for create and alter user has been made a
built-in "SQL" function and a trigger is created at initdb time.
Comments around the pg_pwd updating function seem to be worried about
this
routine being called concurrently, but I really don't see a reason to
worry about this. Verify for yourself. I guess we never had a system
trigger before, so treat this with care, and feel free to adjust the
nomenclature as well.
--
Peter Eisentraut Sernanders väg 10:115
at all, and because of shell quoting rules this can't be fixed, so I put
in error messages to that end.
Also, calling create or drop database in a transaction block is not so
good either, because the file system mysteriously refuses to roll back rm
calls on transaction aborts. :) So I put in checks to see if a transaction
is in progress and signal an error.
Also I put the whole call in a transaction of its own to be able to roll
back changes to pg_database in case the file system operations fail.
The alternative location issues I posted recently were untouched, awaiting
the outcome of that discussion. Other than that, this should be much more
fool-proof now.
The docs I cleaned up as well.
Peter Eisentraut Sernanders väg 10:115
yet, but at least we can give a better error message:
regression=> select count(distinct f1) from int4_tbl;
ERROR: aggregate(DISTINCT ...) is not implemented yet
instead of 'parser: parse error at or near distinct'.
I was able to crash postgres 6.5.3 when I did an 'alter user' command.
After I started a debugger I found the problem in the timezone handling
of
datetime (my Linux box lost its timezone information, that's how the
problem occurred).
Only 7 bytes are reserved for the timezone, without checking for
boundaries.
Attached is a patch that fixes this problem and emits a NOTICE if a
timezone is encountered that is longer than MAXTZLEN bytes, like this:
Jeroen van Vianen
against the sources from one hour ago and contain all the portable and
up
to date stuff.
A few other CVS "householding" things you might want to take care of:
* Remove the src/bin/cleardbdir directory
* Remove the file src/bin/psql/sql_help.h from the repository, as it is
a derived file and is build by the release_prep.
Peter Eisentraut
(which are palloc'd) instead of DLLists (which are malloc'd). Not very
significant, since this routine seldom has anything useful to do, but
a leak is a leak...
them into the scripts dir. I also added a --list option to show already
installed languages.
This whole moving and renaming totally confused CVS and my checked out
copy got completely fried last night. When you apply the source patch,
please make sure that all the directories src/bin/{create|destroy}* as
well as vacuumdb, cleardbdir are gone and that all the scripts (7) are
in
scripts/.
Meanwhile I am still puzzled about what happened with the docs patch.
Because I don't know what you got now, the second attachment contains
the
files
ref/allfiles.sgml
ref/commands.sgml
ref/createlang.sgml
ref/droplang.sgml
doc/src/sgml/Makefile
Peter Eisentraut Sernanders väg 10:115
parameter in some flavor of Unix, but Linux, HPUX, and SunOS all say
it's int. For now I'm just going to make it int so that I can compile.
If the other way is actually necessary on some Unix somewhere, I guess
we will need a configure test...
This one should work much better than the one I sent in previously. The
functionality is the same, but the patch was missing one file resulting
in
the compilation failing. The docs also received a minor fix.
Peter Eisentraut Sernanders väg 10:115
PQconnectStart
PQconnectPoll
PQresetStart
PQresetPoll
PQsetenvStart
PQsetenvPoll
PQsetenvAbort
and brings into the published interface
PQsetenv.
The first four are asynchronous analogues of PQconnectdb and PQreset -
they allow an application to connect to the DB without blocking on
remote I/O.
The PQsetenv functions perform an environment negotiation with the
server.
Internal to libpq, pqReadReady and pqWriteReady have been made available
across the library (they were previously static functions inside
fe-misc.c). A lot of internal rearrangement has been necessary to
support these changes.
The API documentation has been updated also.
Caveats:
o The Windows code does not default to using non-blocking sockets,
since I have no documentation: Define WIN32_NON_BLOCKING_CONNECTIONS to
do that.
o The SSL code still blocks.
Ewan Mellor.
You have CommLog and Debug enabled
You encounter in error in any operation (SQLConnect/SQLExec).
Previously, the extra logging didn't check for NULL pointers
when trying to print some of the strings- the socket error
message could frequently be NULL by design (if there was no socket
error)
and Solaris does not handle NULLS passed to things like printf
("%s\n",string);
gracefully.
This basically duplicates the functionality found in Linux where passing
a null pointer
to printf prints "(NULL)". No very elegant, but the logging is for debug
only anyway.
Dirk Niggemann
table owner in order to vacuum a table. This is mainly to prevent
denial-of-service attacks via repeated vacuums. Allow VACUUM to gather
statistics about system relations, except for pg_statistic itself ---
not clear that it's worth the trouble to make that case work cleanly.
Cope with possible tuple size overflow in pg_statistic tuples; I'm
surprised we never realized that could happen. Hold a couple of locks
a little longer to try to prevent deadlocks between concurrent VACUUMs.
There still seem to be some problems in that last area though :-(
expressions were written without spaces between operators and operands.
Problem was that something like "if new.f1=new.f2 then" would be translated
to "if $1=$2 then", and the Postgres lexer would tokenize that the wrong
way. Fix is to emit spaces around $paramno constructs to ensure they are
seen as separate tokens.
parallel --- and, not incidentally, removing a common reason for needing
manual cleanup by the DB admin after a crash. Remove initial global
delete of pg_statistics rows in VACUUM ANALYZE; this was not only bad
for performance of other backends that had to run without stats for a
while, but it was fundamentally broken because it was done outside any
transaction. Surprising we didn't see more consequences of that.
Detect attempt to run VACUUM inside a transaction block. Check for
query cancel request before starting vacuum of each table. Clean up
vacuum's private portal storage if vacuum is aborted.
By dropping stats rows here, we eliminate the need for VACUUM to do a
wholesale remove of stats rows. Before, pg_statistics was wiped clean
at the start of VACUUM, ensuring poor planning results for any backends
running in parallel until VACUUM got around to rebuilding the stats for
the relations they are accessing.
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
Make all system indexes unique.
Make all cache loads use system indexes.
Rename *rel to *relid in inheritance tables.
Rename cache names to be clearer.
for the case of errors in backend startup, and proc_exit's method for
coping with errors during proc_exit was *completely* busted. Fixed per
discussions on pghackers around 11/6/99.
it wants to release. This leads to a race condition: does the backend
that's trying to flush the buffer do so before the one that's deleting the
relation does so? Usually no problem, I expect, but on occasion this could
lead to hard-to-reproduce complaints from md.c, especially mdblindwrt.
returns a list of RelOptInfos, eliminating the need for static state
in index_info. That static state was a direct cause of coredumps; if
anything decided to elog(ERROR) partway through an index_info search of
pg_index, the next query would try to close a scan pointer that was
pointing at no-longer-valid memory. Another example of the reasons to
avoid static state variables...
of the index it wants to destroy. This ensures that no other backend is
actively scanning or updating that index. Getting exclusive access on
the index alone is NOT sufficient, because the executor is rather
cavalier about getting locks on indexes --- see ExecOpenIndices().
It might be better to grab index locks in the executor, but I'm not
sure the extra lockmanager traffic is really worth it just to make
index_destroy cleaner.
(whoever thought world-writable files were a good default????). Modify
the pg_pwd code so that pg_pwd is created with 600 permissions. Modify
initdb so that permissions on a pre-existing PGDATA directory are not
blindly accepted: if the dir is already there, it does chmod go-rwx
to be sure that the permissions are OK and the dir actually is owned
by postgres.
inval.c thought it could safely use the catcache to look up the OIDs of
system relations. Not good, considering that inval.c could be called
during catcache loading, if a shared-inval message arrives. Rip out the
lookup logic and instead use the known OIDs from pg_class.h.
table defaults or rules: translate them to a function call so that
parse_coerce doesn't reduce them to a date or time constant immediately.
Also, eliminate a lot of redundancy in the expression grammar by
defining a new nonterminal com_expr, which contains all the productions
that can be shared by a_expr and b_expr.
Warn_restart has been set by the backend main loop. This means that
elog(ERROR) or elog(FATAL) in the postmaster or during backend startup
now have well-defined behavior: proc_exit() rather than coredump.
In the case of elog() inside the postmaster, I think that proc_exit()
is probably not enough --- don't we want our child backends to be
forced to quit too? But I don't understand Vadim's recent changes in
this area, so I'll leave it to him to look over and tweak if needed.
subselects can only appear on the righthand side of a binary operator.
That's still true for quantified predicates like x = ANY (SELECT ...),
but a subselect that delivers a single result can now appear anywhere
in an expression. This is implemented by changing EXPR_SUBLINK sublinks
to represent just the (SELECT ...) expression, without any 'left hand
side' or combining operator --- so they're now more like EXISTS_SUBLINK.
To handle the case of '(x, y, z) = (SELECT ...)', I added a new sublink
type MULTIEXPR_SUBLINK, which acts just like EXPR_SUBLINK used to.
But the grammar will only generate one for a multiple-left-hand-side
row expression.
circumstances:
=> select * from foo\x\t\pset border 0 \p\g\\select * from bar;
Also the release prep update so the sql_help.h is generated before
packaging.
Peter.
nulls with non-nulls using proper three-valued boolean logic. Also clean
up ExecQual to make it clearer that ExecQual *does* follow the SQL spec
for boolean nulls. See '[BUGS] (null) != (null)' thread around 10/26/99
for more detail.
* Add use of 'const' for varibles in source tree
(which is misspelled, btw.)
I went through the front-end libpq code and did so. This affects in
particular the various accessor functions (such as PQdb() and
PQgetvalue()) as well as, by necessity, the internal helpers they use.
I have been really thorough in that regard, perhaps some people will find
it annoying that things like
char * foo = PQgetvalue(res, 0, 0)
will generate a warning. On the other hand it _should_ generate one. This
is no real compatibility break, although a few clients will have to be
fixed to suppress warnings. (Which again would be in the spirit of the
above TODO.)
In addition I replaced some int's by size_t's and removed some warnings
(and generated some new ones -- grmpf!). Also I rewrote PQoidStatus (so it
actually honors the const!) and supplied a new function PQoidValue that
returns a proper Oid type. This is only front-end stuff, none of the
communicaton stuff was touched.
The psql patch also adds some new consts to honor the new libpq situation,
as well as fixes a fatal condition that resulted when using the -V
(--version) option and there is no database listening.
So, to summarize, the psql you should definitely put in (with or without
the libpq). If you think I went too far with the const-mania in libpq, let
me know and I'll make adjustments. If you approve it, I will also update
the docs.
-Peter
--
Peter Eisentraut Sernanders vaeg 10:115
Now indexes of pg_class and pg_type are unique indexes
and guarantee the uniqueness of correponding attributes.
heap_create() was changed to take another boolean parameter
which allows to postpone the creation of disk file.
The name of rd_nonameunlinked was changed to rd_unlinked.
It is used generally(not only for noname relations) now.
Requires initdb.
Apparently, back in the dim reaches of prehistory, the parser couldn't
be trusted to label Const nodes with the correct constbyval value ...
and someone preferred to patch around this in copyObject rather than
fix the problem at the source. The problem is long gone, but the hack
lingered on. Until now.
in the TupleDesc that the caller already has (for call from ExecMain) or
can make just as easily as ExecInitJunkFilter() can (for call from
ExecAppend). Also, don't bother to build a junk filter for an INSERT
operation that doesn't actually need one, which is the normal case.
In particular, don't bother to look up type information for attributes
where we're not actually going to use it, and avoid copying entire tlist
structure when it's not necessary.
during initial run formation by keeping both current run and next-run
tuples in the same heap (yup, Knuth is smarter than I am). And, during
merge passes, make use of available sort memory to load multiple tuples
from any one input 'tape' at a time, thereby improving locality of
access to the temp file.
before calling execProject, when the outerPlan has returned zero tuples.
I took this out under the mistaken impression that the input tuple
couldn't be referenced by execProject if we weren't in GROUP BY mode.
But it can, if we're in an UPDATE or DELETE...
One, it now returns the previous hook. That way people don't have to dig
around in libpq-int.h for that information anymore. It previously
returned void, so there should be no incompatibilities.
Second, you cannot set the callback to NULL anymore. (Of course you can
still call it with NULL just to get the current hook.) The way libpq uses
the callback pointer, having a NULL there wasn't very healthy.
Peter Eisentraut
The following patch extends the COMMENT ON functionality to the
rest of the database objects beyond just tables, columns, and views. The
grammer of the COMMENT ON statement now looks like:
COMMENT ON [
[ DATABASE | INDEX | RULE | SEQUENCE | TABLE | TYPE | VIEW ] <objname>
|
COLUMN <relation>.<attribute> |
AGGREGATE <aggname> <aggtype> |
FUNCTION <funcname> (arg1, arg2, ...) |
OPERATOR <op> (leftoperand_typ rightoperand_typ) |
TRIGGER <triggername> ON relname>
Mike Mascari
(mascarim@yahoo.com)
eliminating some wildly inconsistent coding in various parts of the
system. I set MAXPGPATH = 1024 in config.h.in. If anyone is really
convinced that there ought to be a configure-time test to set the
value, go right ahead ... but I think it's a waste of time.
when an initdb-forcing change has been applied within a development cycle.
PG_VERSION serves this purpose for official releases, but we can't bump
the PG_VERSION number every time we make a change to the catalogs during
development. Instead, increase the catalog version number to warn other
developers that you've made an incompatible change. See my mail to
pghackers for more info.
fix recently applied to backend's lexer). I see that YY_USES_REJECT
still gets defined for this lexer, which means it's going to have trouble
parsing really long tokens. Not sure if it's worth doing anything about
that or not; I don't have the interest right now to understand why
ecpg's additions to the syntax cause this problem...
This patch fix a TODO list item.
* require SELECT DISTINCT target list to have all ORDER BY columns
example
ogawa=> select distinct x from t1 order by y;
ERROR: ORDER BY columns must appear in SELECT DISTINCT target list
---
Atsushi Ogawa
boundary-condition bug in myinput() which caused flex scanner to fail
on tokens larger than a bufferload. Turns out flex doesn't want null-
terminated input ... and if it gives you a 1-character buffer, you'd
better supply a character, not a null, lest you be thought to be
reporting end of input.
proc_exit time. I discovered that if the frontend closes the connection
when you're inside a transaction block, there is nothing ensuring that
temp files go away ... I wonder whether proc_exit ought to try to do an
explicit transaction abort?
a generalized module 'tuplesort.c' that can sort either HeapTuples or
IndexTuples, and is not tied to execution of a Sort node. Clean up
memory leakages in sorting, and replace nbtsort.c's private implementation
of mergesorting with calls to tuplesort.c.
recycle storage within sort temp file on a block-by-block basis. This
reduces peak disk usage to essentially just the volume of data being
sorted, whereas it had been about 4x the data volume before.
>From the ORACLE 7 SQL Language Reference Manual:
-----------------------------------------------------
COMMENT
Purpose:
To add a comment about a table, view, snapshot, or
column into the data dictionary.
Prerequisites:
The table, view, or snapshot must be in your own
schema
or you must have COMMENT ANY TABLE system privilege.
Syntax:
COMMENT ON [ TABLE table ] |
[ COLUMN table.column] IS 'text'
You can effectively drop a comment from the database
by setting it to the empty string ''.
-----------------------------------------------------
Example:
COMMENT ON TABLE workorders IS
'Maintains base records for workorder information';
COMMENT ON COLUMN workorders.hours IS
'Number of hours the engineer worked on the task';
to drop a comment:
COMMENT ON COLUMN workorders.hours IS '';
The current patch will simply perform the insert into
pg_description, as per the TODO. And, of course, when
the table is dropped, any comments relating to it
or any of its attributes are also dropped. I haven't
looked at the ODBC source yet, but I do know from
an ODBC client standpoint that the standard does
support the notion of table and column comments.
Hopefully the ODBC driver is already fetching these
values from pg_description, but if not, it should be
trivial.
Hope this makes the grade,
Mike Mascari
(mascarim@yahoo.com)
BufFile so that it handles multi-segment temporary files transparently.
This allows sorts and hashes to work with data exceeding 2Gig (or whatever
the local limit on file size is). Change psort.c to use relative seeks
instead of absolute seeks for backwards scanning, so that it won't fail
when the data volume exceeds 2Gig.
I have changed a bit the makefiles for the win32 port - the *.def files
(created when building shared libraries) are now clean from
Makefile.shlib.
I have also removed "-g" from CFLAGS in the "cygwin32" template - it can
be
enabled when running configure.
Dan
database, but they get truncated at the first NUL by lo_read
when they are read back. The reason for this is that lo_read in
Pg.xs is using the default:
OUTPUT:
RETVAL
buf
which uses C's strlen() to work out the length of the scalar.
The code ought to read something more like:
OUTPUT:
RETVAL
buf sv_setpvn((SV*)ST(2), buf, RETVAL);
I am not sure if this needs to be done on both lo_read methods
in this file, but I changed both and have not since had any
problems with truncated BLOBs.
Douglas Thomson <dougt@mugc.cc.monash.edu.au>
Cygwin snapshots (tested on 990115 which is recommended to use - it fixes
some errors in B20.1)
And I have another patch for including <sys/ipc.h> before <sys/sem.h> in
backend/storage/lmgr/proc.c - it is required due the design of cygipc
headers
Dan
mentioned in FROM but not elsewhere in the query: such tables should be
joined over anyway. Aside from being more standards-compliant, this allows
removal of some very ugly hacks for COUNT(*) processing. Also, allow
HAVING clause without aggregate functions, since SQL does. Clean up
CREATE RULE statement-list syntax the same way Bruce just fixed the
main stmtmulti production.
CAUTION: addition of a field to RangeTblEntry nodes breaks stored rules;
you will have to initdb if you have any rules.
quite the same way that transformInsertStatement does, so that an expression
could be accepted by CREATE TABLE and then fail when used. Also, put back
check that CONSTRAINT expressions must yield boolean...
expressions in CREATE TABLE. There is no longer an emasculated expression
syntax for these things; it's full a_expr for constraints, and b_expr
for defaults (unfortunately the fact that NOT NULL is a part of the
column constraint syntax causes a shift/reduce conflict if you try a_expr.
Oh well --- at least parenthesized boolean expressions work now). Also,
stored expression for a column default is not pre-coerced to the column
type; we rely on transformInsertStatement to do that when the default is
actually used. This means "f1 datetime default 'now'" behaves the way
people usually expect it to.
BTW, all the support code is now there to implement ALTER TABLE ADD
CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't
actually teach ALTER TABLE to call it, but it wouldn't be much work.
--enable-debug adds -g (unconditionally)
--disable-debug removes -g (if it was already in there somehow)
(giving neither does nothing)
Since none of the templates default CFLAGS with a -g you're not likely
to
end up with two -g flags. Not that they'd hurt though.
It doesn't do anything about C++.
Peter Eisentraut
not just C, so that ISCACHABLE attribute can be specified for user-defined
functions. Get rid of ParamString node type, which wasn't actually being
generated by gram.y anymore, even though define.c thought that was what
it was getting. Clean up minor bug in dfmgr.c (premature heap_close).
modifyAggrefQual. This routine really, really needs to be retired, but
until we have subselects in FROM there's no chance of doing the job right.
In the meantime try to respond to unhandlable cases with elog rather than
coredump.
in the Expr nodes they produce. This fixes a few cases of errors like
'typeidTypeRelid: Invalid type - oid = 0' caused by calling parser-related
routines on expression trees that have already been processed by planner-
related routines.
they have no hardwired limit on the length of a rule's text. Fix a couple
of minor bugs in passing --- deparsed UPDATE queries didn't have quotes
around relation name, and quotes and backslashes in constant values weren't
backslash-quoted.
expression_tree_mutator rather than ad-hoc tree walking code. This shortens
the code materially and fixes a fair number of sins of omission. Also,
change modifyAggrefQual to *not* recurse into subselects, since its mission
is satisfied if it removes aggregate functions from the top level of a
WHERE clause. This cures problems with queries of the form SELECT ...
WHERE x IN (SELECT ... HAVING something-using-an-aggregate), which would
formerly get mucked up by modifyAggrefQual. The routine is still
fundamentally broken, of course, but I don't think there's any way to get
rid of it before we implement subselects in FROM ...
Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands.
TODO:
Generic builtin trigger procedures
Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE
Support of new trigger type in pg_dump
Swapping of huge # of events to disk
Jan
functions. One problem that I have encountered with the function
manager is that it does not allow the user to define type conversion
functions that convert between user types. For instance if mytype1,
mytype2, and mytype3 are three Postgresql user types, and if I wish to
define Postgresql conversion functions like
I run into problems, because the Postgresql dynamic loader would look
for a single link symbol, mytype3, for both pieces of object code. If
I just change the name of one of the Postgresql functions (to make the
symbols distinct), the automatic type conversion that Postgresql uses,
for example, when matching operators to arguments no longer finds the
type conversion function.
The solution that I propose, and have implemented in the attatched
patch extends the CREATE FUNCTION syntax as follows. In the first case
above I use the link symbol mytype2_to_mytype3 for the link object
that implements the first conversion function, and define the
Postgresql operator with the following syntax
The patch includes changes to the parser to include the altered
syntax, changes to the ProcedureStmt node in nodes/parsenodes.h,
changes to commands/define.c to handle the extra information in the AS
clause, and changes to utils/fmgr/dfmgr.c that alter the way that the
dynamic loader figures out what link symbol to use. I store the
string for the link symbol in the prosrc text attribute of the pg_proc
table which is currently unused in rows that reference dynamically
loaded
functions.
Bernie Frankpitt
an empty targetlist *and* fails to return any tuples, as will happen
for example with 'SELECT COUNT(1) FROM table WHERE ...' if the where-
clause selects no tuples. It's so nice to make a fix by diking out code,
instead of adding more...
behavior as it was, apart from forbidding minus-terminated
operators. Seems that I have to break the habit of doing before
thinking properly :-/ The point is that my second patch breaks
constructs like a & b or a ! b. This patch is to be applied
instead of any of two other today's patches.
Leon
Two patches included:
- the first one enables the use of bool variables in fields which might
become NULL.
Up to now the lib told you that NULL is not a bool variable, even if
you provide a indicator.
- the second patch checks whether a value is null and issues an error if
no indicator is provided.
Sidenote: IIRC, the variable should be left alone if the value is NULL.
ECPGlib sets it's value to 0 on NULL. Is this a violation of the
standard?
Regards
Christof
is used to find start scan position of Indexscan-s.
To speed up finding scan start position,I have changed
_bt_first() to use as many keys as possible.
I'll attach the patch here.
Regards.
Hiroshi Inoue
When drawing up a very simple "text-drawing" of how the negotiation is done,
I realised I had done this last part (fallback) in a very stupid way. Patch
#4 fixes this, and does it in a much better way.
Included is also the simple text-drawing of how the negotiation is done.
//Magnus
with no input rows, per pghackers discussions around 7/22/99. Clean up
a bunch of ugly coding while at it; remove redundant re-lookup of
aggregate info at start of each new GROUP. Arrange to pfree intermediate
values when they are pass-by-ref types, so that aggregates on pass-by-ref
types no longer eat memory. This takes care of a couple of TODO items...
Frankpitt, plus some improvements from yours truly. The simplifier depends
on the proiscachable field of pg_proc to tell it whether a function is
safe to pre-evaluate --- things like nextval() are not, for example.
Update pg_proc.h to contain reasonable cacheability information; as of
6.5.* hardly any functions were marked cacheable. I may have erred too
far in the other direction; see recent mail to pghackers for more info.
This update does not force an initdb, exactly, but you won't see much
benefit from the simplifier until you do one.
* Buffer refcount cleanup (per my "progress report" to pghackers, 9/22).
* Add links to backend PROC structs to sinval's array of per-backend info,
and use these links for routines that need to check the state of all
backends (rather than the slow, complicated search of the ShmemIndex
hashtable that was used before). Add databaseOID to PROC structs.
* Use this to implement an interlock that prevents DESTROY DATABASE of
a database containing running backends. (It's a little tricky to prevent
a concurrently-starting backend from getting in there, since the new
backend is not able to lock anything at the time it tries to look up
its database in pg_database. My solution is to recheck that the DB is
OK at the end of InitPostgres. It may not be a 100% solution, but it's
a lot better than no interlock at all...)
* In ALTER TABLE RENAME, flush buffers for the relation before doing the
rename of the physical files, to ensure we don't get failures later from
mdblindwrt().
* Update TRUNCATE patch so that it actually compiles against current
sources :-(.
You should do "make clean all" after pulling these changes.
now that sequence names are properly quoted for field defaults, mixed
case sequence names are generated. These are properly quoted in the
CREATE SEQUENCE lines, but not in the SELECT nextval lines, as per
below:
CREATE SEQUENCE "Teams_TeamID_seq" start 10 increment 1 maxvalue
2147483647 minvalue 1 cache 1 ;
SELECT nextval ('Teams_TeamID_seq');
This needs to be:
SELECT nextval ('"Teams_TeamID_seq"');
Patch included below.
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
additional argument specifying the kind of lock to acquire/release (or
'NoLock' to do no lock processing). Ensure that all relations are locked
with some appropriate lock level before being examined --- this ensures
that relevant shared-inval messages have been processed and should prevent
problems caused by concurrent VACUUM. Fix several bugs having to do with
mismatched increment/decrement of relation ref count and mismatched
heap_open/close (which amounts to the same thing). A bogus ref count on
a relation doesn't matter much *unless* a SI Inval message happens to
arrive at the wrong time, which is probably why we got away with this
sloppiness for so long. Repair missing grab of AccessExclusiveLock in
DROP TABLE, ALTER/RENAME TABLE, etc, as noted by Hiroshi.
Recommend 'make clean all' after pulling this update; I modified the
Relation struct layout slightly.
Will post further discussion to pghackers list shortly.
See attached mail for more details.
-------------------------------------------------------------------
From: "Vadim Mikheev" <vadim@krs.ru>
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
References: <000201befa94$42fe04c0$2801007e@cadzone.tpf.co.jp>
Subject: Re: elog(ERROR) in vacuum
Date: Fri, 10 Sep 1999 10:27:10 +0900
Organization: OJSC Rostelecom (Krasnoyarsk)
Message-ID: <37D85E6E.5AFA126D@krs.ru>
Hiroshi Inoue wrote:
>
> Hello Vadim,
>
> I have a question about vacuum.
>
> VACUUM has a phase like commit which calls TransactionIdCommit().
> But if elog(ERROR) occured after that,the status of transaction is
> changed from XID_COMMIT to XID_ABORT.
>
> Seems to me this causes inconsistency.
> Shoudn't AbortTransaction() be changed not to call TransacionIdAbort()
> in case of vacuum.
You're right!
As usual -:)
Vadim
Almost worked before, but forgot one place to check.
Reported by Tatsuo Ishii.
Still does not do the right thing if inserting into a non-string target
column. Should look for a type coersion later, but doesn't.
message under a kernel that only returns one packet per recv() call. This
didn't use to matter much, but it starts to get annoying with multi-megabyte
EXPLAIN VERBOSE responses...
conditions. There are some pretty bogus heuristics in prepqual.c that
try to decide whether to output CNF or DNF format; they need to be replaced,
likely. Right now the code is probably too willing to choose DNF form,
which might hurt performance in some cases that used to work OK.
But at least we have a foundation to build on.
in or_normalize, remove detection of duplicate subexpressions (since it's
highly unlikely to be worth the amount of time it takes), and introduce
a dnfify() entry point so that unintelligible backwards logic in UNION
processing can be eliminated. This is just an intermediate step ---
next thing is to look at not forcing the qual into CNF form when it would
be better off in DNF form.
This change seems necessary in conjunction with long queries, and it
cleans up some bogosity in connection with long EXPLAIN texts anyway.
Note that current libpq will accept any length error message (at least
until it runs out of memory); prior versions have a limit of 8K, but
will cleanly discard excess error text, so there shouldn't be any
big compatibility problems with old clients.
transaction abort --- before it only worked if there was exactly one level
of allocation context stacked in the blank portal. Now it does the right
thing for any depth, including zero...
was rejecting negative attnums as bogus, which of course they are not.
Add code to get_attdisbursion to produce a useful value for OID attribute,
since VACUUM does not store stats for system attributes.
Also, repair bug that's been in eqjoinsel for a long time: it was taking
the max of the two columns' disbursions, whereas it should use the min.
space consumption in pull_args, and avoid doing the full CNF transform on
operands of operator clauses, where it's really not particularly helpful.
This answers the TODO item about large numbers of OR clauses, at least
partially. I was able to do a ten-thousand-OR-clause query with about
20Mb memory consumption ... it took an obscenely long time, but it worked...
corrects flex myinput() routine so that it doesn't assume there is only
one bufferload of data. We still have the issue of getting rid of
YY_USES_REJECT so that the scanner can cope with tokens larger than its
initial buffer size.
before comparison; if fields being joined are different widths then hashing
will yield wrong answer. Also, remove hashjoinable mark from all uses of
array_eq, because array structures may have padding bytes between elements
and the pad bytes are of uncertain content. This could be revisited if
array code is cleaned up.
Modify opr_sanity regress test to complain if array_eq operator is marked
hashjoinable.
offended my aesthestic sensibility that there was so much unreadable code
doing so little. Rewritten code is about half the size, faster, and
(I hope) much more intelligible.
current transaction) are not flushed by shared-cache-inval reset message.
SI reset actually works now, for probably the first time in a long time.
I was able to run initdb and regression tests with a 16-element SI message
array, with a lot of NOTICE: cache state reset messages but no crashes.
We can't support these properly, since once the relation's physical files
are unlinked, there's no way to roll back the transaction. I suppose
we could postpone the unlink till transaction commit, but then what of
BEGIN; DROP TABLE foo; CREATE TABLE foo; ?
The code does allow dropping a table/index created in the current
transaction block, however, since the post-abort state would be that
the table doesn't exist anyway.
real name before doing lookup. We only want to index temp tables by their
real names in the relcache, to ensure there's not more than one relcache
entry for them.
has positive refcount, it is rebuilt from pg_class data. This ensures
that relcache entries will track changes made by other backends. Formerly,
a shared inval report would just be ignored if it happened to arrive while
the relcache entry was in use. Also, fix relcache to reset ref counts
to zero during transaction abort. Finally, change LockRelation() so that
it checks for shared inval reports after obtaining the lock. In this way,
once any kind of lock has been obtained on a rel, we can trust the relcache
entry to be up-to-date.
the SInval spinlock while it is calling the passed invalFunction or
resetFunction. This is necessary to avoid deadlock with lmgr change;
InvalidateSharedInvalid can be called recursively now. It should be
a good performance improvement anyway --- holding a spinlock for more
than a very short interval is a no-no.
insight that RelationFlushRelation ought to invoke smgrclose, and that the
way to make that work is to ensure that mdclose doesn't fail if the relation
is already closed (or unlinked, if we are looking at a DROP TABLE). While
I was testing that, I was able to identify several problems that we had
with multiple-segment relations. The system is now able to do initdb and
pass the regression tests with a very small segment size (I had it set to
64Kb per segment for testing). I don't believe that ever worked before.
File descriptor leaks seem to be gone too.
I have partially addressed the concerns we had about mdtruncate(), too.
On a Win32 or NFS filesystem it is not possible to unlink a file that
another backend is holding open, so what md.c now does is to truncate
unwanted files to zero length before trying to unlink them. The other
backends will be forced to close their open files by relation cache
invalidation --- but I think it would take considerable work to make
that happen before vacuum truncates the relation rather than after.
Leaving zero-length files lying around seems a usable compromise.
error/notice message lengths, and number of fields per tuple. Add
pqexpbuffer.c/.h, a frontend version of backend's stringinfo module.
This is first step in applying Mike Ansley's long-query patches,
even though he didn't do any of these particular changes...
and 1370 (timestamp(datetime)). This does not force an initdb, exactly,
but you won't see the effects of the bug fix until you do one.
BTW, OID 1358 for timespan(time) is still broken:
select timespan('21:11:26'::time);
ERROR: No such function 'time_timespan' with the specified attributes
But I couldn't figure out what it ought to be defined as, so I left it be.
references or CASE expressions, didn't parenthesize complex expressions
properly. Also, always output variable references as fully qualified
names to eliminate ambiguity bug recently reported. (This could be
smarter, but reliability comes first.)
Most parts of the planner should ignore, or indeed never even see, uplevel
Vars because they will be or have been replaced by Params. There were a
couple of places that got it wrong though, probably my fault from recent
changes...
last loop which would return the *first* surviving-to-that-point candidate
regardless of which one actually passed the test. This was producing
such curious results as 'oid % 2' getting translated to 'int2(oid) % 2'.
documented intepretation of the lefthand and oper fields. Fix a number of
obscure problems while at it --- for example, the old code failed if the parser
decided to insert a type-coercion function just below the operator of a
SubLink.
CAUTION: this will break stored rules that contain subplans. You may
need to initdb.
It will keep track the number of pages allocated so that
vacuum could allocate twice of the previous allocation.
This will greatly reduce the total memory consumption of
vacuum.
ALLOC_BIGCHUNK_LIMIT are always allocated as separate malloc() blocks,
and are free()d immediately upon pfree(). Also, if such a chunk is enlarged
with repalloc(), translate the operation into a realloc() so as to
minimize memory usage. Of course, these large chunks still get freed
automatically if the alloc set is reset.
I have set ALLOC_BIGCHUNK_LIMIT at 64K for now, but perhaps another
size would be better?
match then it tried for a self-commutative operator with the reversed input
data types. This is pretty silly; there could never be such an operator,
except maybe in binary-compatible-type scenarios, and we have oper_inexact
for that. Besides which, the oprsanity regress test would complain about
such an operator. Remove nonfunctional code and simplify routine calling
convention accordingly.
and fix_opids processing to a single recursive pass over the plan tree
executed at the very tail end of planning, rather than haphazardly here
and there at different places. Now that tlist Vars do not get modified
until the very end, it's possible to get rid of the klugy var_equal and
match_varid partial-matching routines, and just use plain equal()
throughout the optimizer. This is a step towards allowing merge and
hash joins to be done on expressions instead of only Vars ...
sort order down into planner, instead of handling it only at the very top
level of the planner. This fixes many things. An explicit sort is now
avoided if there is a cheaper alternative (typically an indexscan) not
only for ORDER BY, but also for the internal sort of GROUP BY. It works
even when there is no other reason (such as a WHERE condition) to consider
the indexscan. It works for indexes on functions. It works for indexes
on functions, backwards. It's just so cool...
CAUTION: I have changed the representation of SortClause nodes, therefore
THIS UPDATE BREAKS STORED RULES. You will need to initdb.
above a Sort or Materialize node. As far as I can tell, the only place
that actually needed that was set_tlist_references, which was being lazy
about checking to see if it had a noname node to fix or not...
store all ordering information in pathkeys lists (which are now lists of
lists of PathKeyItem nodes, not just lists of lists of vars). This was
a big win --- the code is smaller and IMHO more understandable than it
was, even though it handles more cases. I believe the node changes will
not force an initdb for anyone; planner nodes don't show up in stored
rules.
commuted (ie, the index var appears on the right). These are now handled
the same way as merge and hash join quals that need to be commuted: the
actual reversing of the clause only happens if we actually choose the path
and generate a plan from it. Furthermore, the clause is only reversed in
the 'indexqual' field of the plan, not in the 'indxqualorig' field. This
allows the clause to still be recognized and removed from qpquals of upper
level join plans. Also, simplify and generalize match_clause_to_indexkey;
now it recognizes binary-compatible indexes for join as well as restriction
clauses.
contains much code that looks like it will handle indexquals with the index
key on either side of the operator, in fact indexquals must have the index
key on the left because of limitations of the ScanKey machinery. Perhaps
someone will be motivated to fix that someday...
work under a wider range of scenarios than it did --- it formerly did not
handle a multi-pass inner scan, nor cases in which the inner scan's
indxqualorig or non-index qual contained outer var references. I am not
sure that these limitations could be hit in the existing optimizer, but
they need to be fixed for future expansion.
> >
> > was implemented by Jan Wieck.
> > His work is for ascending order cases.
> >
> > Here is a patch to prevent sorting also in descending
> > order cases.
> > Because I had already changed _bt_first() to position
> > backward correctly before v6.5,this patch would work.
> >
Hiroshi Inoue
Inoue@tpf.co.jp
multi-scan indexscan plans; it tried to use the same table-to-index
attribute mapping for all the scans, even if they used different indexes.
It would klugily work as long as OR indexquals never used multikey indexes,
but that's not likely to hold up much longer...
to go along with expression_tree_walker. (_walker is not suitable for
routines that need to alter the tree structure significantly.) Other minor
cleanups in clauses.c.
Also, move responsibility for calling vc_abort into main xact.c list of
things-to-call-at-abort. What in the world was it doing down inside of
TransactionIdAbort()?
hashjoinable clause, not one path for a randomly-chosen element of each
set of clauses with the same join operator. That is, if you wrote
SELECT ... WHERE t1.f1 = t2.f2 and t1.f3 = t2.f4,
and both '=' ops were the same opcode (say, all four fields are int4),
then the system would either consider hashing on f1=f2 or on f3=f4,
but it would *not* consider both possibilities. Boo hiss.
Also, revise estimation of hashjoin costs to include a penalty when the
inner join var has a high disbursion --- ie, the most common value is
pretty common. This tends to lead to badly skewed hash bucket occupancy
and way more comparisons than you'd expect on average.
I imagine that the cost calculation still needs tweaking, but at least
it generates a more reasonable plan than before on George Young's example.
(it should just call the given operator, not look up an = operator).
Fix intltsel() so that all numeric data types are converted to double
before trying to estimate where the given comparison value is in the
known range of column values. intltsel() still needs work, or replacement,
for non-numeric data types ... but for nonintegral numeric types it
should now be delivering reasonable estimates.
configure.in to determine if a system is ELF or not. Note that some
of the tests earlier may be redundant but I took the safest route.
D'Arcy J.M. Cain
neqsel now behave as per my suggestions in pghackers a few days ago.
selectivity for < > <= >= should work OK for integral types as well, but
still need work for nonintegral types. Since these routines have never
actually executed before :-(, this may result in some significant changes
in the optimizer's choices of execution plans. Let me know if you see
any serious misbehavior.
CAUTION: THESE CHANGES REQUIRE INITDB. pg_statistic table has changed.
so that Case works in WHERE join clauses. Temporary patch --- this routine
is one of many that ought to be changed to use centralized expression-tree-
walking logic.
rels that the inner path needs to join to, but it was only checking for
the first one. Failure could only have been observed with an OR-clause
that mentions 3 or more tables, and then only if the bogus path was
actually selected as cheapest ...
optimizer rather than parser. This has many advantages, such as not
getting fooled by chance uses of operator names ~ and ~~ (the operators
are identified by OID now), and not creating useless comparison operations
in contexts where the comparisons will not actually be used as indexquals.
The new code also recognizes exact-match LIKE and regex patterns, and
produces an = indexqual instead of >= and <=.
This change does NOT fix the problem with non-ASCII locales: the code
still doesn't know how to generate an upper bound indexqual for non-ASCII
collation order. But it's no worse than before, just the same deficiency
in a different place...
Also, dike out loc_restrictinfo fields in Plan nodes. These were doing
nothing useful in the absence of 'expensive functions' optimization,
and they took a considerable amount of processing to fill in.
The only place it was being used was as temporary storage in indxpath.c,
and the logic was wrong: the same restrictinfo node could get chosen to
carry the info for two different joins. Right fix is to return a second
list of unjoined-relids parallel to the list of clause groups.
identified by Hiroshi (incorrect cost attributed to OR clauses
after multiple passes through set_rest_selec()). I think the code
was trying to allow selectivities of OR subclauses to be passed in
from outside, but noplace was actually passing any useful data, and
set_rest_selec() was passing wrong data.
Restructure representation of "indexqual" in IndexPath nodes so that
it is the same as for indxqual in completed IndexScan nodes: namely,
a toplevel list with an entry for each pass of the index scan, having
sublists that are implicitly-ANDed index qual conditions for that pass.
You don't want to know what the old representation was :-(
Improve documentation of OR-clause indexscan functions.
Remove useless 'notclause' field from RestrictInfo nodes. (This might
force an initdb for anyone who has stored rules containing RestrictInfos,
but I do not think that RestrictInfo ever appears in completed plans.)
the query string to handle any length, I discovered that under certain
conditions, psql will core dump when handling long strings. Thus, the
patch. It was caused by a buffer overrun, probably not noticeable in a lot
of cases, but pretty noticeable in mine.
Problem was caused by the fact that the length check is only performed after
the check for a ; to get the end of the query and execute.
Cheers...
MikeA
support, but which the grammar was accepting. Also, fix several bugs
having to do with failure to copy fields up from a subselect to a select
or insert node.
of the SELECT part of the statement is just like a plain SELECT. All
INSERT-specific processing happens after the SELECT parsing is done.
This eliminates many problems, e.g. INSERT ... SELECT ... GROUP BY using
the wrong column labels. Ensure that DEFAULT clauses are coerced to
the target column type, whether or not stored clause produces the right
type. Substantial cleanup of parser's array support.
creates a reduce/reduce conflict, which I resolved by changing the
'AexprConst -> Typename Sconst' rule to 'AexprConst -> SimpleTypename Sconst'.
In other words, a subscripted type declaration can't be used in that
syntax any longer. This seems a small price to pay for not having to
qualify subscripted columns anymore.
Other cleanups: rename res_target_list to update_target_list, and remove
productions for variants that are not legal in an UPDATE target list;
rename res_target_list2 to plain target_list; delete position_expr
in favor of using b_expr in that production; merge opt_indirection
into attr nonterminal, since there are no places where an unsubscripted
attr is wanted; fix typos in Param support; change case_arg so that
an arbitrary a_expr is allowed, not only a column name.
care of equal-key cases, eliminating bt_firsteq(). The linear search
formerly done by bt_firsteq() took a lot of time in the case where many
equal keys appear on the same page.
that contain null fields. Old code would produce erratic sort results
because comparisons of tuples containing nulls could produce inconsistent
answers.
> the DTK_MICROSEC case is just like the DTK_MILLISEC case.
> I think this is wrong and it ought to look like
> fsec = rint(fsec * 1000000) / 1000000;
> no?
Tom Lane.
"HAS_LONG_LONG" is defined based on the assumption that
strtol() would return ERANGE if a platform does not support
64-bit integers. In current PostgreSQL 6.5 (and 6.4.2)
distribution, "HAS_LONG_LONG" is defined only if platform
is "alpha". (See include/port/alpha.h) I think the int4
range check should apply to linux_alpha as well. (I have
not tested yet but I guess this might be applicable to
newer Linux/i386 distributions which includes new GCC which
implements long int as 64-bit int.)
with expression_tree_walker-based code. The former failed to cope with
expressions containing SubLinks, and the latter returned TRUE for both
SubLinks and Aggrefs (cut-and-paste bug?). There is a lot more scope for
using expression_tree_walker in this module, but I'll restrain myself
until the 6.6 split occurs from touching not-demonstrably-broken code.
is parse_aggs.c. This fixes its failure to cope with (at least) CaseExpr
and ArrayRef nodes, which is the reason why both of these fail in 6.5:
select coalesce(f1,0) from int4_tbl group by f1;
ERROR: Illegal use of aggregates or non-group column in target list
select sentence.words[0] from sentence group by sentence.words[0];
ERROR: Illegal use of aggregates or non-group column in target list
The array case still fails, but at least it's not parse_agg's fault
anymore ... considering that we now support CASE officially, I think
it's important to fix the first example ...
will gradually replace all of the boilerplate tree-walk-recursion code that
currently exists in O(N) slightly different forms in N subroutines.
I've had it with adding missing cases to these subroutines...
August 1994 draft standard.
Use the ecpg support libraries to write the CLI interface?
Date and Darwen claim that CLI is a more modern and flexible approach...
special hack to ensure it would close its output file even after failure
due to elog(ERROR) partway through the copy. This is now unnecessary
because fd.c takes care of cleaning up open files at transaction abort;
worse, after fd.c closed the file copy.c would try to do so *again* at
the start of the next COPY command. This would result in havoc in most
implementations of stdio library.
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
