| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
mean stress ... system is orders of magnitude slower with this enabled).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
index's support-function cache (in index_getprocinfo). Since none of that
data can change for an index that's in active use, it seems sufficient to
treat all open indexes the same way we were treating "nailed" system indexes
--- that is, just re-read the pg_class row and leave the rest of the relcache
entry strictly alone. The pg_class re-read might not be strictly necessary
either, but since the reltablespace and relfilenode can change in normal
operation it seems safest to do it. (We don't support changing any of the
other info about an index at all, at the moment.)
Back-patch as far as 8.0. It might be possible to adapt the patch to 7.4,
but it would take more work than I care to expend for such a low-probability
problem. 7.3 is out of luck for sure.
|
| |
|
|
| |
now /lib.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
occurs when it tries to heap_open pg_tablespace. When control returns to
smgrcreate, that routine will be holding a dangling pointer to a closed
SMgrRelation, resulting in mayhem. This is of course a consequence of
the violation of proper module layering inherent in having smgr.c call
a tablespace command routine, but the simplest fix seems to be to change
the locking mechanism. There's no real need for TablespaceCreateDbspace
to touch pg_tablespace at all --- it's only opening it as a way of locking
against a parallel DROP TABLESPACE command. A much better answer is to
create a special-purpose LWLock to interlock these two operations.
This drops TablespaceCreateDbspace quite a few layers down the food chain
and makes it something reasonably safe for smgr to call.
|
| |
|
|
|
|
|
| |
This is utterly insignificant in normal operation, but it becomes a
problem during cache inval stress testing. The original coding in fact
had no leak --- the 8.0 List rewrite created the issue. I wonder whether
list_concat should pfree the discarded header?
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
files: avoid creating stats hashtable entries for tables that aren't being
touched except by vacuum/analyze, ensure that entries for dropped tables are
removed promptly, and tweak the data layout to avoid storing useless struct
padding. Also improve the performance of pgstat_vacuum_tabstat(), and make
sure that autovacuum invokes it exactly once per autovac cycle rather than
multiple times or not at all. This should cure recent complaints about 8.1
showing much higher stats I/O volume than was seen in 8.0. It'd still be a
good idea to revisit the design with an eye to not re-writing the entire
stats dataset every half second ... but that would be too much to backpatch,
I fear.
|
| |
|
|
| |
assuming it always is on Darwin. Per report from Neil Brandt.
|
| |
|
|
|
|
|
| |
discarded by cache flush while still in use. This is a minimal patch that
just copies the tupdesc anywhere it could be needed across a flush. Applied
to back branches only; Neil Conway is working on a better long-term solution
for HEAD.
|
| |
|
|
|
|
| |
a va_list. Christof Petig's previous patch made this change, but neglected
to update ecpglib/descriptor.c, resulting in a compiler warning (and a
likely runtime crash) on AMD64 and PPC.
|
| |
|
|
| |
by Magnus Hagander
|
| |
|
|
| |
prepared statements, per report from David Wheeler.
|
| |
|
|
|
|
|
|
| |
our own command (or more generally, xmin = our xact and cmin >= current
command ID) should not be seen as good. Else we may try to update rows
we already updated. This error was inserted last August while fixing the
even bigger problem that the old coding wouldn't see *any* tuples inserted
by our own transaction as good. Per report from Euler Taveira de Oliveira.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
one argument at a time and then inserting the argument into a Python
list via PyList_SetItem(). This "steals" the reference to the argument:
that is, the reference to the new list member is now held by the Python
list itself. This works fine, except if an elog occurs. This causes the
function's PG_CATCH() block to be invoked, which decrements the
reference counts on both the current argument and the list of arguments.
If the elog happens to occur during the second or subsequent iteration
of the loop, the reference count on the current argument will be
decremented twice.
The fix is simple: set the local pointer to the current argument to NULL
immediately after adding it to the argument list. This ensures that the
Py_XDECREF() in the PG_CATCH() block doesn't double-decrement.
|
| |
|
|
|
|
| |
operator names. This is needed when dumping operator definitions that have
COMMUTATOR (or similar) links to operators in other schemas.
Apparently Daniel Whitter is the first person ever to try this :-(
|
| | |
|
| |
|
|
|
|
| |
use it. While it normally has been opened earlier during btree index
build, testing shows that it's possible for the link to be closed again
if an sinval reset occurs while the index is being built.
|
| |
|
|
|
|
|
|
|
| |
dead and have become unreferenced. Before 8.1, such members were left
for AtEOXact_CatCache() to clean up, but now AtEOXact_CatCache isn't
supposed to have anything to do. In an assert-enabled build this bug
leads to an assertion failure at transaction end, but in a non-assert
build the dead member is effectively just a small memory leak.
Per report from Jeremy Drake.
|
| |
|
|
| |
an INSERT target list during rule rewriting. Per report from John Supplee.
|
| |
|
|
|
|
|
| |
rather than elog(FATAL), when there is no more room in ShmemBackendArray.
This is a security issue since too many connection requests arriving close
together could cause the postmaster to shut down, resulting in denial of
service. Reported by Yoshiyuki Asaba, fixed by Magnus Hagander.
|
| |
|
|
|
| |
The consequences of overwriting a non-empty page are bad enough that
we should not omit this test in production builds.
|
| |
|
|
|
|
|
|
|
| |
the relation but it finds a pre-existing valid buffer. The buffer does not
correspond to any page known to the kernel, so we *must* do smgrextend to
ensure that the space becomes allocated. The 7.x branches all do this
correctly, but the corner case got lost somewhere during 8.0 bufmgr rewrites.
(My fault no doubt :-( ... I think I assumed that such a buffer must be
not-BM_VALID, which is not so.)
|
| | |
|
| | |
|
| |
|
|
| |
Back-patch of previous fix in HEAD for plperl-vs-locale issue.
|
| |
|
|
| |
expressional indexes. Per report from Brian Hirt.
|
| |
|
|
| |
per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343616 via Martin Pitt.
|
| |
|
|
|
| |
returning the rowtype it's supposed to return. Per reports from David Niblett
and Michael Fuhr.
|
| | |
|
| |
|
|
|
|
|
|
| |
from Andrus Moor. The former state-machine-style coding wasn't actually
doing much except obscuring the control flow, and it didn't extend
readily to fix this case, so I just took it out. Also, add a
YY_FLUSH_BUFFER call to ensure the lexer is reset correctly if the
previous scan failed partway through the file.
|
| |
|
|
|
| |
are inconsistent with the rest of the .po files, and apparently cause
problems for Sun's cc. Per report on IRC from "bitvector2".
|
| |
|
|
|
|
| |
selection of a field from the result of a function returning RECORD.
I believe this case is new in 8.1; it's due to the addition of OUT parameters.
Per example from Michael Fuhr.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
===================================================================
RCS file: /Users/neilc/postgres/cvs_root/pgsql/src/pl/plpython/plpython.c,v
retrieving revision 1.67
diff -c -r1.67 plpython.c
*** src/pl/plpython/plpython.c 26 Dec 2005 04:28:48 -0000 1.67
--- src/pl/plpython/plpython.c 29 Dec 2005 16:54:57 -0000
***************
*** 2,8 ****
* plpython.c - python as a procedural language for PostgreSQL
*
* This software is copyright by Andrew Bosma
! * but is really shameless cribbed from pltcl.c by Jan Weick, and
* plperl.c by Mark Hollomon.
*
* The author hereby grants permission to use, copy, modify,
--- 2,8 ----
* plpython.c - python as a procedural language for PostgreSQL
*
* This software is copyright by Andrew Bosma
! * but is really shamelessly cribbed from pltcl.c by Jan Wieck, and
* plperl.c by Mark Hollomon.
*
* The author hereby grants permission to use, copy, modify,
***************
*** 1996,2002 ****
int i,
rv;
PLyPlanObject *plan;
- char *nulls;
MemoryContext oldcontext;
if (list != NULL)
--- 1996,2001 ----
***************
*** 2018,2024 ****
if (nargs != plan->nargs)
{
char *sv;
-
PyObject *so = PyObject_Str(list);
if (!so)
--- 2017,2022 ----
***************
*** 2036,2048 ****
oldcontext = CurrentMemoryContext;
PG_TRY();
{
! nulls = palloc(nargs * sizeof(char));
for (i = 0; i < nargs; i++)
{
PyObject *elem,
*so;
- char *sv;
elem = PySequence_GetItem(list, i);
if (elem != Py_None)
--- 2034,2045 ----
oldcontext = CurrentMemoryContext;
PG_TRY();
{
! char *nulls = palloc(nargs * sizeof(char));
for (i = 0; i < nargs; i++)
{
PyObject *elem,
*so;
elem = PySequence_GetItem(list, i);
if (elem != Py_None)
***************
*** 2051,2070 ****
if (!so)
PLy_elog(ERROR, "function \"%s\" could not execute plan",
PLy_procedure_name(PLy_curr_procedure));
! sv = PyString_AsString(so);
! /*
! * FIXME -- if this elogs, we have Python reference leak
! */
! plan->values[i] =
! FunctionCall3(&(plan->args[i].out.d.typfunc),
! CStringGetDatum(sv),
! ObjectIdGetDatum(plan->args[i].out.d.typioparam),
! Int32GetDatum(-1));
! Py_DECREF(so);
! Py_DECREF(elem);
nulls[i] = ' ';
}
else
--- 2048,2073 ----
if (!so)
PLy_elog(ERROR, "function \"%s\" could not execute plan",
PLy_procedure_name(PLy_curr_procedure));
! Py_DECREF(elem);
! PG_TRY();
! {
! char *sv = PyString_AsString(so);
! plan->values[i] =
! FunctionCall3(&(plan->args[i].out.d.typfunc),
! CStringGetDatum(sv),
! ObjectIdGetDatum(plan->args[i].out.d.typioparam),
! Int32GetDatum(-1));
! }
! PG_CATCH();
! {
! Py_DECREF(so);
! PG_RE_THROW();
! }
! PG_END_TRY();
+ Py_DECREF(so);
nulls[i] = ' ';
}
else
|
| | |
|
| |
|
|
|
|
|
| |
single column dump that has a \. value, so the load works properly. I
also added documentation describing this issue.
Backpatch to 8.1.X.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
if (c == '\\' && cstate->line_buf.len == 0)
The problem with that is the because of the input and _output_
buffering, cstate->line_buf.len could be zero even if we are not on the
first character of a line. In fact, for a typical line, it is zero for
all characters on the line. The proper solution is to introduce a
boolean, first_char_in_line, that we set as we enter the loop and clear
once we process a character.
I have restructured the line-reading code in copy.c by:
o merging the CSV/non-CSV functions into a single function
o used macros to centralize and clarify the buffering code
o updated comments
o renamed client_encoding_only to encoding_embeds_ascii
o added a high-bit test to the encoding_embeds_ascii test for
performance
o in CSV mode, allow a backslash followed by a non-period to
continue being processed as a data value
There should be no performance impact from this patch because it is
functionally equivalent. If you apply the patch you will see copy.c is
much clearer in this area now and might suggest additional
optimizations.
I have also attached a 8.1-only patch to fix the CSV \. handling bug
with no code restructuring.
|
| |
|
|
|
|
|
|
|
|
|
| |
See:
Subject: [HACKERS] bugs with certain Asian multibyte charsets
From: Tatsuo Ishii <ishii@sraoss.co.jp>
To: pgsql-hackers@postgresql.org
Date: Sat, 24 Dec 2005 18:25:33 +0900 (JST)
for more details.
|
| |
|
|
|
|
|
|
|
|
|
| |
Also make the code more robust by searching for target encoding
in the internal charset map.
Problem reported by Sagi Bashari on 2005/12/21.
See "[BUGS] BUG #2120: Crash when doing UTF8<->ISO_8859_8 encoding conversion"
on pgsql-bugs list for more details.
Back patch for 8.1_STABLE.
|
| |
|
|
|
|
|
|
|
|
|
| |
differ by more than the last directory component. Instead of insisting
that they match up to the last component, accept whatever common prefix
they have, and try to replace the non-matching part of bin_path with
the non-matching part of target_path in the actual executable's path.
In one way this is tighter than the old code, because it insists on
a match to the part of bin_path we want to substitute for, rather than
blindly stripping one directory component from the executable's path.
Per gripe from Martin Pitt and subsequent discussion.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
equal: if strcoll claims two strings are equal, check it with strcmp, and
sort according to strcmp if not identical. This fixes inconsistent
behavior under glibc's hu_HU locale, and probably under some other locales
as well. Also, take advantage of the now-well-defined behavior to speed up
texteq, textne, bpchareq, bpcharne: they may as well just do a bitwise
comparison and not bother with strcoll at all.
NOTE: affected databases may need to REINDEX indexes on text columns to be
sure they are self-consistent.
|
| |
|
|
|
|
| |
messages, when client attempts to execute these outside a transaction (start
one) or in a failed transaction (reject message, except for COMMIT/ROLLBACK
statements which we can handle). Per report from Francisco Figueiredo Jr.
|
| |
|
|
|
| |
example from Jim Dew. Add some simple regression tests, since this is
an area we seem to break regularly :-(
|
| |
|
|
|
|
| |
that simplify_boolean_equality() may leave behind. This is only relevant
if the user writes something a bit silly, like CASE x=y WHEN TRUE THEN.
Per example from Michael Fuhr; may or may not explain bug #2106.
|
| | |
|
| |
|
|
| |
introduced a copy-and-pasteo while trying to simplify the code.
|
| |
|
|
|
|
|
|
|
| |
However, Another problem newly occurred.
This solves the problem of snprintf and vsnprintf.
Patch to HEAD and 8.1.X.
Hiroshi Saito
|
| | |
|
| | |
|
