- 17 5月, 2001 10 次提交
-
-
由 Tom Lane 提交于
PageGetFreeSpace() was being called while not holding the buffer lock, which not only could yield a garbage answer, but even if it's the right answer there might be less space available after we reacquire the buffer lock. Also repair potential deadlock introduced by my recent performance improvement in RelationGetBufferForTuple(): it was possible for two heap_updates to try to lock two buffers in opposite orders. The fix creates a global rule that buffers of a single heap relation should be locked in decreasing block number order. Currently, this only applies to heap_update; VACUUM can get away with ignoring the rule since it holds exclusive lock on the whole relation anyway. However, if we try to implement a VACUUM that can run in parallel with other transactions, VACUUM will also have to obey the lock order rule.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
ELF capability. While this is true to some extent, this assumption makes it impossible to compile PostgreSQL 7.1 and 7.2devel without the --disable-shared switch during configuration. Trond Endrest
-
由 Bruce Momjian 提交于
is of type Object, and is null Dave Cramer
-
由 Bruce Momjian 提交于
David Esposito
-
由 Bruce Momjian 提交于
(http://www.ideit.com/products/dbvis/) to work with Postgresql and I found out the following bug: if database has views then getTables() gets the null pointer exception ('order by relname' makes the listing tree in DbVisualizer a lot useful !!) This patch should propably be applied to the the jdbc1's DatabaseMetaData.java, too. Panu Outinen
-
由 Bruce Momjian 提交于
return ((c == 't') || (c == 'T')); int the getBoolean function on line 184:ish to: return ((c == 't') || (c == 'T') (c == '1')); Hunter Hillegas
-
由 Bruce Momjian 提交于
-
- 16 5月, 2001 7 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
public ResultSet getTables(String catalog, String schemaPattern, String Jeroen van Vianen
-
由 Bruce Momjian 提交于
Ola Sundell
-
由 Bruce Momjian 提交于
not properly handle 8-bit unsigned data as it blindly casts the byte to an int, which java most helpfully promotes to a signed type. This causes problems when you can only return -1 to indicated EOF. The following patch fixes the bug and has been tested locally on image data. Chad David
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
type never scans a relation directly, it can't be an EPQ target. Explicitly drop subplan's tuple table to ensure we have no buffer pin leaks.
-
- 15 5月, 2001 21 次提交
-
-
由 Bruce Momjian 提交于
with many NULLs ( inserting of NULL into indexed field cause ERROR: MemoryContextAlloc: invalid request size) As a workaround 'vacuum analyze' could be used. This patch resolves the problem, please upply to 7.1.1 sources and current cvs tree. Oleg Bartunov
-
由 Bruce Momjian 提交于
-
由 D'Arcy J.M. Cain 提交于
-
由 Bruce Momjian 提交于
encode - is below. I even got the linefeed stuff wrong. -- marko
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
Re-add pg_index.indisclustered in a minimalist way. Also fix BSDi dynamic linker change. #include must be before #ifdef test.
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
trees (mostly my fault). Repair. Also fix long-standing bug in ExecReplace: after recomputing a concurrently updated tuple, we must recheck constraints. Make EvalPlanQual leak memory with somewhat less enthusiasm than before, although plugging leaks fully will require more changes than I care to risk in a dot-release.
-
由 Tom Lane 提交于
-
由 Bruce Momjian 提交于
-
由 Peter Eisentraut 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Peter Eisentraut 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
forced.
-
由 Tom Lane 提交于
for relations on the nullable side of an OUTER JOIN. For now I think we'd better refuse such queries.
-
由 Bruce Momjian 提交于
-
- 13 5月, 2001 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
> Postgres 7.1.0), and I think I've found a bug. > > I compiled Pgcrypto with OpenSSL, using gcc 2.95.4 and > OpenSSL 0.9.6a (the latest Debian 'unstable' packages). > web=> select encode(digest('blah', 'sha1'), 'base64'); > FATAL 1: pg_encode: overflow, encode estimate too small > pqReadData() -- backend closed the channel unexpectedly. > This probably means the backend terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Succeeded. > Is this a bug? Can it be fixed? This is a bug alright. And a silly one :) Marko Kreen
-