- 19 6月, 1999 4 次提交
-
-
由 Tom Lane 提交于
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 ...
-
由 Tom Lane 提交于
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...
-
由 Tom Lane 提交于
functions, in order to work around oversight in 6.5 release: rtree index functions haven't got any. Mea culpa ...
-
由 Bruce Momjian 提交于
-
- 18 6月, 1999 2 次提交
- 17 6月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
for Irix.
-
- 16 6月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 13 6月, 1999 5 次提交
-
-
由 Tom Lane 提交于
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 提交于
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 提交于
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 提交于
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 提交于
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.
-
- 12 6月, 1999 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
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
-
- 11 6月, 1999 3 次提交
-
-
由 Vadim B. Mikheev 提交于
/* * 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 提交于
locked buffer.
-
由 Bruce Momjian 提交于
Hiroshi Inoue
-
- 10 6月, 1999 2 次提交
-
-
由 Vadim B. Mikheev 提交于
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 提交于
ye proverbial one-line patch (not counting five lines of comment so's maybe it won't happen again)
-
- 09 6月, 1999 1 次提交
-
-
由 Vadim B. Mikheev 提交于
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) ?
-
- 07 6月, 1999 6 次提交
-
-
由 Vadim B. Mikheev 提交于
DO NOT EVEN TRY TO DO PageGetMaxOffsetNumber BEFORE LockBuffer! -:)
-
由 Tom Lane 提交于
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.
-
由 Vadim B. Mikheev 提交于
< 6.5 versions were just not affected by this bug due to locking.
-
由 Vadim B. Mikheev 提交于
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 提交于
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
-
由 Tom Lane 提交于
inheritance ... basically it was completely busted :-(
-
- 06 6月, 1999 2 次提交
-
-
由 Vadim B. Mikheev 提交于
EvalPlanQualNext() when implemented it... -:) Uncommented...
-
由 Tom Lane 提交于
index, etc is too long, truncate until it fits.
-
- 05 6月, 1999 4 次提交
-
-
由 Marc G. Fournier 提交于
trace.patch (compilation error) 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>
-
由 Tom Lane 提交于
given number of backends (-N), per recent discussion in pghackers list.
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
Get rid of it to make customization of NAMEDATALEN easier.
-
- 04 6月, 1999 1 次提交
-
-
由 Tom Lane 提交于
in the same transaction that created it.
-
- 03 6月, 1999 5 次提交
-
-
由 Vadim B. Mikheev 提交于
in CommitTransaction(). 2. Changes in GetSnapshotData().
-
由 Vadim B. Mikheev 提交于
vc_scanheap().
-
由 Vadim B. Mikheev 提交于
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 提交于
all the expected keys (it was returning uninitialized memory).
-
由 Tom Lane 提交于
libpq ...
-
- 02 6月, 1999 1 次提交
-
-
由 Jan Wieck 提交于
Jan
-