| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
properly.
|
|
this would fix TODO
* elog() flushes cache, try invalidating just entries from
current xact, perhaps using invalidation cache
|
|
|
|
|
|
|
|
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.
|
|
specified by regular-expression patterns. Add some more files.
|
|
remove the no-longer-used files.
|
|
|
|
|
|
postmaster/postmaster.c so that
tcop/postgres.c can use them. Now we have an interlock between
postmaster and postgres.
|
|
tcop/postgres.c can use them. Now we have an interlock between
postmaster and postgres.
|
|
Do not start postmaster if postgres is running
|
|
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.
|
|
|
|
|
|
Note: don't put any of these back till you've grokked the new code for
platform-specific comparisons that I'm about to commit...
|
|
them --- it is just *way* too painful to keep expected results in sync
when these are present.
|
|
|
|
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???
|
|
|
|
code cleanup; no major improvements yet. However, EXPLAIN does produce
more intuitive outputs for nested loops with indexscans now...
|
|
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.
|
|
as well as when inserting entries into an existing index.
|
|
still
without answer. I want continue with to_char(), but I need any answer
for this patch. Please.
Thank! (and sorry of my impatient :-)
Karel
|
|
|
|
|
|
|
|
in trigger manager.
Jan
|
|
SET DEFAULT referential action triggers.
Jan
|
|
|
|
|
|
|
|
|
|
|
|
Update output to new psql conventions.
|
|
|
|
|
|
Remove older "::" type coersion syntax in favor of extended SQL92 style.
Include a few new tests for datetime/timespan arithmetic.
|
|
Include a few new tests for datetime/timespan arithmetic.
|
|
|
|
rather than the Postgres "::" notation.
All of these tests have been completely inspected and give correct results.
|
|
All of these tests have been completely inspected and give correct results.
|
|
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.
|
|
|
|
|
|
to be Y2K safe.
|
