Tom Lane [Sat, 12 Jun 1999 22:17:24 +0000 (22:17 +0000)]
Move default NBuffers setting into config.h, and rename it
to DEF_NBUFFERS for readability. Make sure the default value is OK
according to postmaster.c's new sanity check for -B values.
Tom Lane [Sat, 12 Jun 1999 20:41:25 +0000 (20:41 +0000)]
Fix critical error noticed by Massimo: copy.c used to have a
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.
Tom Lane [Sat, 12 Jun 1999 19:38:30 +0000 (19:38 +0000)]
Remove query_planner's overhasty rejection of cases where
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.
Tom Lane [Sat, 12 Jun 1999 19:27:41 +0000 (19:27 +0000)]
Plug hole in dike: planner would coredump if query_planner
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.
Tom Lane [Sat, 12 Jun 1999 19:22:40 +0000 (19:22 +0000)]
When targetlist is NULL, ExecTargetList was passing back a
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.
Bruce Momjian [Sat, 12 Jun 1999 14:05:41 +0000 (14:05 +0000)]
I don't like last minute patches before the final freeze, but I believe that
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:
Vadim B. Mikheev [Fri, 11 Jun 1999 09:35:08 +0000 (09:35 +0000)]
Change Assert(Ptp.t_data->t_xmax == tp.t_data->t_xmin) to :
/*
* 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)
...
Vadim B. Mikheev [Thu, 10 Jun 1999 14:17:12 +0000 (14:17 +0000)]
1. Fix for elog(ERROR, "EvalPlanQual: t_xmin is uncommitted ?!")
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.
Tom Lane [Thu, 10 Jun 1999 06:55:40 +0000 (06:55 +0000)]
Fix errors in SELECT ... GROUP BY ... UNION SELECT ...
ye proverbial one-line patch (not counting five lines of comment so's
maybe it won't happen again)
Reset evaluation plan tuple table next free slot counter to 0
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.
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) ?
Bruce Momjian [Mon, 7 Jun 1999 22:58:31 +0000 (22:58 +0000)]
I attach a patch for pg_upgrade. This does two things:
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.
Bruce Momjian [Mon, 7 Jun 1999 14:29:20 +0000 (14:29 +0000)]
> Here is a small patch that should only affect win32 building
> (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
Tom Lane [Mon, 7 Jun 1999 14:28:26 +0000 (14:28 +0000)]
Repair recently-introduced error in makeIndexable for LIKE:
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.
1. xact.c: update comments about changing MyProc->xid and MyProc->xmin.
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).
Tom Lane [Sun, 6 Jun 1999 17:46:40 +0000 (17:46 +0000)]
equal() needs a case for Aggref nodes, as shown by:
regression=> select sum(q1) from int8_tbl group by q2 order by sum(q1);
NOTICE: equal: don't know whether nodes of type 107 are equal
Bruce Momjian [Sat, 5 Jun 1999 19:09:48 +0000 (19:09 +0000)]
Hi,
I have updated my contrib code for version 6.5. In the attachment you will
find the directories array, datetime, miscutil, string, tools and userlocks
which replace the corresponding directories under contrib.
In contrib/tools you will find some developement scripts which I use while
hacking the sources. I hope they will be useful for some other people.
I have also added a contrib/Makefile which tries to compile and install all
the contribs. Unfortunately many of them don't have a Makefile or don't
compile cleanly.
Tom Lane [Sat, 5 Jun 1999 18:05:17 +0000 (18:05 +0000)]
Remove redeclarations of default parameter values from
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.
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.
ecpg.patch (wrong makefile expansion in some cases)
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.
Tom Lane [Fri, 4 Jun 1999 21:21:13 +0000 (21:21 +0000)]
Suppress indexes on large objects from psql's \d listing;
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.
Bruce Momjian [Thu, 3 Jun 1999 20:44:28 +0000 (20:44 +0000)]
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
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
Bruce Momjian [Thu, 3 Jun 1999 20:42:18 +0000 (20:42 +0000)]
Thanks for this, but SET TRANSACTION ISOLATION LEVEL
should be described like SET TIME ZONE: TO is not allowed, as well
as DEFAULT option. There are only two forms:
1. MyProc->xid assignment is moved to GetNewTransactionId so newer
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).
Tom Lane [Thu, 3 Jun 1999 04:01:16 +0000 (04:01 +0000)]
pg_dump failed on any database containing large objects,
because it ignored the LOs themselves but failed to ignore the indexes
on the LOs. How long has this been broken??