[PATCHES] Re: [HACKERS] pgsql: Fix for plpython functions; return true/false for boolean,
Peter Eisentraut wrote:
Guido Goldstein wrote:
Is it possible to tell me which python versions you want to
support?
The issue isn't so much which versions we want to support. There is
certainly some flexibility with that. But when a patch breaks the
buildfarm a) unannounced and b) without any apparent feature gain, then
people get annoyed.
If this breaks the buildfarm it's not my failure.
Except you can tell me what I've got to do with the
buildfarm.
If you mean that plpython didn't compile, fine; simply tell
the people what version they should consider when sending
in patches.
I've checked the patch with postgres 8.1.3 and 8.2.1
with python 2.4 and 2.5 on intel 32 bit and amd 64 bit
systems; all systems running linux.
*And* it's not a feature patch but a bug-fixing one!
Python is a language with strong typing, so silently
converting a datatype is a bug -- not a feature.
Btw, you'll lose the type information of boolean columns in
trigger functions (NEW and OLD dicts, no explicit parameters),
which does cause problems.
That said, we certainly try to support a few more versions of Python
[...]
If you want to support python 2.3 use the attached patch, which also
works for the newer python versions.
The Python 2.3 branch is the oldest _officially_ supported python version.
Anyway, to circumvent the above mentiond point a) I herewith anncounce
that the included patch might break the buildfarm.
Cheers
Guido
--- postgresql-8.2.1.orig/src/pl/plpython/plpython.c 2006-11-21 22:51:05.0 +0100
+++ postgresql-8.2.1/src/pl/plpython/plpython.c 2007-01-17 18:06:58.185497734 +0100
@@ -1580,8 +1580,8 @@
PLyBool_FromString(const char *src)
{
if (src[0] == 't')
- return PyInt_FromLong(1);
- return PyInt_FromLong(0);
+ return PyBool_FromLong(1);
+ return PyBool_FromLong(0);
}
static PyObject *
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] [BUGS] BUG #2221: Bad delimiters allowed in COPY ...
Bruce Momjian <[EMAIL PROTECTED]> writes: > FYI, Tom, old email from Feb 1, 2006, from your server: Wups. Sorry about that --- somehow I confused that with the current thread about copy delimiters. Should have looked harder at the date. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [BUGS] BUG #2221: Bad delimiters allowed in COPY ...
Tom Lane wrote: > Bruce Momjian writes: > > Attached is a patch that errors for \r and \n in delimiter and > > null. > > I am not convinced that this is a bug. Can you prove that there is no > use-case for asking COPY to emit data in this style? Sure, COPY itself > couldn't read it, but people sometimes feed COPY output to other > programs... FYI, Tom, old email from Feb 1, 2006, from your server: Received: from sss.pgh.pa.us ([EMAIL PROTECTED] [66.207.139.130]) by momjian.us (8.11.6/8.11.6) with ESMTP id l14HX7l21306 for ; Sun, 4 Feb 2007 12:33:08 -0500 (EST) Received: from sss2.sss.pgh.pa.us ([EMAIL PROTECTED] [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id l14HWWoj020066; Sun, 4 Feb 2007 12:32:32 -0500 (EST) To: Bruce Momjian cc: David Fetter <[EMAIL PROTECTED]>, Andrew Dunstan <[EMAIL PROTECTED]>, [EMAIL PROTECTED], PostgreSQL-patches Subject: Re: [PATCHES] [BUGS] BUG #2221: Bad delimiters allowed in COPY ... In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Comments: In-reply-to Bruce Momjian message dated "Wed, 01 Feb 2006 09:10:51 -0500" -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Heikki Linnakangas wrote: >> Tom Lane wrote: >>> BTW, I don't care much for the terminology "phantom cid" ... there's >>> nothing particularly "phantom" about them, seeing they get onto disk. >>> Can anyone think of a better name? The best I can do offhand is >>> "merged cid" or "cid pair", which aren't inspiring. >> >> MultiCid, like the MultiXacts? Maybe not, they're quite different beasts... > Dual cid? Double cid? "Double cid" doesn't sound too bad. Another thought that just came to mind is "cid interval" or some variant of that. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] TM formating patch
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> This patch correct bug, when localized day or month names was incorectly
> trnasformed to lower or upper string.
I really dislike the API you've chosen for upper_str/lower_str ---
overwriting the input on the assumption that it's long enough is a
buffer overrun bug waiting to happen, because (at least in utf8)
changing case doesn't preserve the byte length of the string.
Please make them return a freshly palloc'd string instead.
regards, tom lane
I correct it, and test it for czech latin2 and utf8 case.
Regards
Pavel Stehule
_
Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/
*** ./adt/formatting.c.orig 2007-02-04 13:09:09.0 +0100
--- ./adt/formatting.c 2007-02-05 21:45:26.0 +0100
***
*** 82,87
--- 82,88
#include "utils/int8.h"
#include "utils/numeric.h"
#include "utils/pg_locale.h"
+ #include "mb/pg_wchar.h"
#define _(x) gettext((x))
***
*** 113,118
--- 114,120
#define MAXFLOATWIDTH 64
#define MAXDOUBLEWIDTH 128
+
/* --
* External (defined in PgSQL datetime.c (timestamp utils))
* --
***
*** 946,951
--- 948,967
static char *localize_day_full(int index);
static char *localize_day(int index);
+ /*
+ * External (defined in oracle_compat.c
+ */
+ #if defined(HAVE_WCSTOMBS) && defined(HAVE_TOWLOWER)
+ #define USE_WIDE_UPPER_LOWER
+ extern char *wstring_upper(char *str);
+ extern char *wstring_lower(char *str);
+ static char *localized_str_toupper(char *buff);
+ static char *localized_str_tolower(char *buff);
+ #else
+ #define localized_str_toupper str_toupper
+ #define localized_str_tolower str_tolower
+ #endif
+
/* --
* Fast sequential search, use index for data selection which
* go to seq. cycle (it is very fast for unwanted strings)
***
*** 1500,1505
--- 1516,1522
*p_buff = pg_toupper((unsigned char) *p_buff);
++p_buff;
}
+
return buff;
}
***
*** 1523,1528
--- 1540,1600
return buff;
}
+
+ #ifdef USE_WIDE_UPPER_LOWER
+ /* --
+ * Convert localized string to upper string. Input string is modified in place.
+ * --
+ */
+ static char *
+ localized_str_toupper(char *buff)
+ {
+ if (!buff)
+ return NULL;
+
+ if (pg_database_encoding_max_length() > 1 && !lc_ctype_is_c())
+ return wstring_upper(buff);
+ else
+ {
+ char *p_buff = buff;
+
+ while (*p_buff)
+ {
+ *p_buff = pg_toupper((unsigned char) *p_buff);
+ ++p_buff;
+ }
+ }
+
+ return buff;
+ }
+
+ /* --
+ * Convert localized string to upper string. Input string is modified in place.
+ * --
+ */
+ static char *
+ localized_str_tolower(char *buff)
+ {
+ if (!buff)
+ return NULL;
+
+ if (pg_database_encoding_max_length() > 1 && !lc_ctype_is_c())
+ return wstring_lower(buff);
+ else
+ {
+ char *p_buff = buff;
+
+ while (*p_buff)
+ {
+ *p_buff = pg_tolower((unsigned char) *p_buff);
+ ++p_buff;
+ }
+ }
+
+ return buff;
+ }
+ #endif /* USE_WIDE_UPPER_LOWER */
+
/* --
* Sequential search with to upper/lower conversion
* --
***
*** 2188,2197
if (!tm->tm_mon)
return -1;
if (S_TM(suf))
strcpy(workbuff, localize_month_full(tm->tm_mon - 1));
else
strcpy(workbuff, months_full[tm->tm_mon - 1]);
! sprintf(inout, "%*s", (S_FM(suf) || S_TM(suf)) ? 0 : -9, str_toupper(workbuff));
return strlen(p_inout);
case DCH_Month:
--- 2260,2274
if (!tm->tm_mon)
return -1;
if (S_TM(suf))
+ {
strcpy(workbuff, localize_month_full(tm->tm_mon - 1));
+ sprintf(inout, "%*s", 0, localized_str_toupper(workbuff));
+ }
else
+ {
strcpy(workbuff, months_full[tm->tm_mon - 1]);
! sprintf(inout, "%*s", S_FM(suf) ? 0 : -9, str_toupper(workbuff));
! }
return strlen(p_inout);
case DCH_Month:
***
*** 2209,2218
if (!tm->tm_mon)
return -1;
if (S_TM(suf))
! sprintf(inout, "%*s", 0, localize_month_full(tm->tm_mon - 1));
else
sprintf(inout, "%*s", S_FM(suf) ? 0 : -9, months_full[tm->tm_mon - 1]);
! *inout = pg_tolower((unsigned char) *inout);
return strlen(p_inout);
case DCH_MON:
--- 2286,2300
if (!tm->tm_mon)
return -1;
if (S_TM(suf))
! {
! strcpy(workbuff, localize_month_full(tm->tm_mon - 1));
! sprintf(inout, "%*s", 0, localized_str_tolower(workbuff));
! }
else
+ {
sprintf(inout, "%*s", S_FM(suf) ? 0 : -9, months_full[tm->tm_mon - 1]);
! *inout = pg_tolower((unsigned char) *inout);
! }
return strlen(p_inout);
case DCH_MON:
***
*** 2220,2229
if (!tm->tm_mon)
return -1;
if (S_TM(suf))
! strcpy(inout, localize_month(tm
Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch
Heikki Linnakangas wrote: > Tom Lane wrote: > >Heikki Linnakangas <[EMAIL PROTECTED]> writes: > >>I think the patch is ready. Please remove the PHANTOMCID_DEBUG define > >>and ifdef blocks before applying. > > > >BTW, I don't care much for the terminology "phantom cid" ... there's > >nothing particularly "phantom" about them, seeing they get onto disk. > >Can anyone think of a better name? The best I can do offhand is > >"merged cid" or "cid pair", which aren't inspiring. > > MultiCid, like the MultiXacts? Maybe not, they're quite different beasts... Dual cid? Double cid? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch
Heikki Linnakangas wrote: > Tom Lane wrote: >> Heikki Linnakangas <[EMAIL PROTECTED]> writes: >>> I think the patch is ready. Please remove the PHANTOMCID_DEBUG define >>> and ifdef blocks before applying. >> >> BTW, I don't care much for the terminology "phantom cid" ... there's >> nothing particularly "phantom" about them, seeing they get onto disk. >> Can anyone think of a better name? The best I can do offhand is >> "merged cid" or "cid pair", which aren't inspiring. > > MultiCid, like the MultiXacts? Maybe not, they're quite different beasts... > > Alias cid? Mapped cid? Compressed cid? Hero cid? :) > > I'm happy with phantom cid myself. It sounds cool, and they are a bit > phantom-like because the true meaning of a phantom cid is lost when the > transaction ends. > Phantom was also a super hero ;) Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch
Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: I think the patch is ready. Please remove the PHANTOMCID_DEBUG define and ifdef blocks before applying. BTW, I don't care much for the terminology "phantom cid" ... there's nothing particularly "phantom" about them, seeing they get onto disk. Can anyone think of a better name? The best I can do offhand is "merged cid" or "cid pair", which aren't inspiring. MultiCid, like the MultiXacts? Maybe not, they're quite different beasts... Alias cid? Mapped cid? Compressed cid? Hero cid? :) I'm happy with phantom cid myself. It sounds cool, and they are a bit phantom-like because the true meaning of a phantom cid is lost when the transaction ends. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [previously on HACKERS] "Compacting" a relation
On Mon, 2007-02-05 at 11:55 +, Simon Riggs wrote:
> On Sat, 2007-02-03 at 22:11 -0500, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > > vacuumlazy.c contains a hint "Consider compacting this relation" but
> > > > AFAICT,
> > > > there is no indication anywhere how "compacting" is supposed to be
> > > > achieved.
> > > > I guess this means VACUUM FULL or CLUSTER, but I don't think the hint
> > > > can be
> > > > processed effectively by a user.
> > >
> > > So change it ...
> >
> > New message is:
> >
> > errhint("Consider using VACUUM FULL on this relation or increasing the
> > configuration parameter \"max_fsm_pages\".")));
> >
>
> The change of wording may be appropriate, but it is triggered when
>
> if (vacrelstats->tot_free_pages > MaxFSMPages)
>
> So if you VACUUM a 15+GB table and it has only 1% freespace then it will
> still generate this message. Hopefully you'd agree that the message
> would be inappropriate in that case.
>
> It's also inappropriate because this message is generated *prior* to
> doing lazy_truncate_heap(), which could easily remove lots of empty
> pages anyhow. That might reduce it to less than MaxFSMPages anyhow, so
> it can currently be triggered in wholly inappropriate situations.
>
> So I suggest that we move this wording after lazy_truncate_heap() in
> lazy_vacuum_rel() *and* we alter the hint so that it only suggests
> VACUUM FULL if the table has 20% fragmentation, whatever its size.
>
> Happy to drop a patch for this, if people agree.
Enclose 2 versions:
v1 - move test and WARNING
v2 - move test and WARNING, plus adjust hint according to relation size
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/commands/vacuumlazy.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/vacuumlazy.c,v
retrieving revision 1.83
diff -c -r1.83 vacuumlazy.c
*** src/backend/commands/vacuumlazy.c 4 Feb 2007 03:10:55 - 1.83
--- src/backend/commands/vacuumlazy.c 5 Feb 2007 17:19:55 -
***
*** 180,185
--- 180,192
/* Update shared free space map with final free space info */
lazy_update_fsm(onerel, vacrelstats);
+ if (vacrelstats->tot_free_pages > MaxFSMPages)
+ ereport(WARNING,
+ (errmsg("relation \"%s.%s\" contains more than \"max_fsm_pages\" pages with useful free space",
+ get_namespace_name(RelationGetNamespace(onerel)),
+ RelationGetRelationName(onerel)),
+ errhint("Consider using VACUUM FULL on this relation or increasing the configuration parameter \"max_fsm_pages\".")));
+
/* Update statistics in pg_class */
vac_update_relstats(RelationGetRelid(onerel),
vacrelstats->rel_pages,
***
*** 507,519
vacrelstats->tot_free_pages,
empty_pages,
pg_rusage_show(&ru0;
-
- if (vacrelstats->tot_free_pages > MaxFSMPages)
- ereport(WARNING,
- (errmsg("relation \"%s.%s\" contains more than \"max_fsm_pages\" pages with useful free space",
- get_namespace_name(RelationGetNamespace(onerel)),
- relname),
- errhint("Consider using VACUUM FULL on this relation or increasing the configuration parameter \"max_fsm_pages\".")));
}
--- 514,519
Index: src/backend/commands/vacuumlazy.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/vacuumlazy.c,v
retrieving revision 1.83
diff -c -r1.83 vacuumlazy.c
*** src/backend/commands/vacuumlazy.c 4 Feb 2007 03:10:55 - 1.83
--- src/backend/commands/vacuumlazy.c 5 Feb 2007 17:10:16 -
***
*** 66,71
--- 66,73
#define REL_TRUNCATE_MINIMUM 1000
#define REL_TRUNCATE_FRACTION 16
+ /* multiplier for acceptable fragmentation before WARNING */
+ #define REL_FRAGMENTATION_FACTOR 5
typedef struct LVRelStats
{
***
*** 180,185
--- 182,196
/* Update shared free space map with final free space info */
lazy_update_fsm(onerel, vacrelstats);
+ if (vacrelstats->tot_free_pages > MaxFSMPages)
+ ereport(WARNING,
+ (errmsg("relation \"%s.%s\" contains more than \"max_fsm_pages\" pages with useful free space",
+ get_namespace_name(RelationGetNamespace(onerel)),
+ RelationGetRelationName(onerel)),
+ errhint("Consider%sincreasing the configuration parameter \"max_fsm_pages\".",
+ (REL_FRAGMENTATION_FACTOR * vacrelstats->tot_free_pages > vacrelstats->rel_pages
+ ? " using VACUUM FULL on this relation or ": " ";
+
/* Update statistics in pg_class */
vac_update_relstats(RelationGetRelid(onerel),
vacrelstats->rel_pages,
***
*** 507,519
vacrelstats->tot_free_pages,
empty_pages,
pg_rusage_show(&ru0;
-
- if (vacrelstats->tot_free_pages > MaxFSMPages)
- ereport(WARNING,
- (errmsg("relation \"%s.%s
Re: [PATCHES] [HACKERS] Configuring BLCKSZ and XLOGSEGSZ (in 8.3)
Patch already applied by Tom. Removed from queue. --- Simon Riggs wrote: > On Tue, 2006-12-05 at 17:26 -0500, Tom Lane wrote: > > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > > On Tue, 2006-12-05 at 16:24 -0500, Tom Lane wrote: > > >> Sure, what would happen is that every backend passing through this code > > >> would execute the several lines of computation needed to decide whether > > >> to call RequestCheckpoint. > > > > > Right, but the calculation uses RedoRecPtr, which may not be completely > > > up to date. So presumably you want to re-read the shared memory value > > > again to make sure we are exactly accurate and allow only one person to > > > call checkpoint? Either way we have to take a lock. Insert lock causes > > > deadlock, so we would need to use infolock. > > > > Not at all. It's highly unlikely that RedoRecPtr would be so out of > > date as to result in a false request for a checkpoint, and if it does, > > so what? Worst case is we perform an extra checkpoint. > > On its own, I wouldn't normally agree... > > > Also, given the current structure of the routine, this is probably not > > the best place for that code at all --- it'd make more sense for it to > > be in the just-finished-a-segment code stretch, which would ensure that > > it's only done by one backend once per segment. > > But thats a much better plan since it requires no locking. > > There's a lot more changes there for such a simple fix though and lots > more potential bugs, but I've coded it as you suggest and removed the > fields from pg_control. > > Patch passes make check, applies cleanly on HEAD. > pg_resetxlog and pgcontroldata tested. > > > -- > Simon Riggs > EnterpriseDB http://www.enterprisedb.com > [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [pgsql-patches] [GENERAL] Corrupt database? 8.1/FreeBSD6.0
Bruce Momjian wrote: > > What is the status of this patch? This was applied: 2007-01-14 17:18 alvherre * src/backend/postmaster/autovacuum.c: Fix autovacuum to avoid leaving non-permanent Xids in non-connectable databases. Apply to the 8.1 branch only, as the new 8.2 (and HEAD) coding does not have this problem. > --- > > Alvaro Herrera wrote: > > Tom Lane wrote: > > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > > > > Maybe we could forcibly activate the freeze mode on a template database? > > > > > > Might not be a bad idea. And even more to the point, forcibly disable > > > analyze. > > > > Patch implementing this (albeit untested!) attached. I'll try to > > reproduce the problem without the patch, and then test with the patch > > applied. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] TM formating patch
"Pavel Stehule" <[EMAIL PROTECTED]> writes: > This patch correct bug, when localized day or month names was incorectly > trnasformed to lower or upper string. I really dislike the API you've chosen for upper_str/lower_str --- overwriting the input on the assumption that it's long enough is a buffer overrun bug waiting to happen, because (at least in utf8) changing case doesn't preserve the byte length of the string. Please make them return a freshly palloc'd string instead. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > I think the patch is ready. Please remove the PHANTOMCID_DEBUG define > and ifdef blocks before applying. BTW, I don't care much for the terminology "phantom cid" ... there's nothing particularly "phantom" about them, seeing they get onto disk. Can anyone think of a better name? The best I can do offhand is "merged cid" or "cid pair", which aren't inspiring. Now would be a good time to change it while it'd still be an easy search-and-replace over a patch file ... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] \copy (query) delimiter syntax error
Andrew Dunstan wrote: Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: The consequence will be, though, that psql will accept a syntax for "\copy (query) ..." that the corresponding backend command would reject were we not transforming it. That strikes me as potentially confusing. Perhaps. What about plan B: remove the legacy syntax support in \copy? IIRC it has not been documented since 7.2, so maybe we can finally throw it overboard. Thoughts? I like it for 8.3 - but maybe my present patch would be better for 8.2, as it involves less behaviour change. While we decide this issue, which can be worked around in any case, I am going to commit the part of the patch that nobody has objected to (and which will fix Michael's original complaint), on HEAD and 8.2 stable, so we can get some testing going. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
