Re: [PATCHES] ignore_killed_tuples is always true
On 2/10/06, Tom Lane <[EMAIL PROTECTED]> wrote: > ITAGAKI Takahiro <[EMAIL PROTECTED]> writes: > > I found IndexScanDesc->ignore_killed_tuples is always true. > > Is this still needed? > > What is the point of removing it? You cannot argue that saving > one if-test per tuple is a worthwhile speedup. > > regards, tom lane > to clean code? -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(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] contrib/xinetops for 8.1 "patch"
Patch applied. Thanks.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > A larger problem is this:
> >
> > > test=> SELECT '255.255.255.0'::inet - '1.1.1.1'::inet;
> > >?column?
> > > ---
> > >-16843265
> > > (1 row)
> >
> > > Should subtraction return int8?
> >
> > Probably, and for that matter the addition operators should take int8;
> > on IPV6 data even that's not really wide enough.
> >
> > > We don't have an unsigned data type. Of course we also have this
> > > excitement:
> >
> > > test=> SELECT '255.255.255.0'::inet + 100;
> > > ?column?
> > >
> > >0.15.65.64
> > > (1 row)
> >
> > > so we underflow and overflow cleanly. Not great, but it works.
> >
> > "Cleanly" isn't the adjective I'd use for that. There should be an
> > overflow error.
>
> OK, changed to int8, and overflow checks added.
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup.| Newtown Square, Pennsylvania 19073
> Index: doc/src/sgml/func.sgml
> ===
> RCS file: /cvsroot/pgsql/doc/src/sgml/func.sgml,v
> retrieving revision 1.303
> diff -c -c -r1.303 func.sgml
> *** doc/src/sgml/func.sgml26 Jan 2006 02:35:48 - 1.303
> --- doc/src/sgml/func.sgml10 Feb 2006 04:11:52 -
> ***
> *** 6787,6792
> --- 6787,6822
> contains or equals
> inet '192.168.1/24' >>= inet
> '192.168.1/24'
>
> +
> + ~
> + bitwise NOT
> + ~ inet '192.168.1.6'
> +
> +
> + &
> + bitwise AND
> + inet '192.168.1.6' & inet
> '0.0.0.255'
> +
> +
> + |
> + bitwise OR
> + inet '192.168.1.6' | inet
> '0.0.0.255'
> +
> +
> + +
> + addition
> + inet '192.168.1.6' + 25
> +
> +
> + -
> + subtraction
> + inet '192.168.1.43' - 36
> +
> +
> + -
> + subtraction
> + inet '192.168.1.43' - inet
> '192.168.1.19'
> +
>
>
>
> Index: src/backend/utils/adt/network.c
> ===
> RCS file: /cvsroot/pgsql/src/backend/utils/adt/network.c,v
> retrieving revision 1.63
> diff -c -c -r1.63 network.c
> *** src/backend/utils/adt/network.c 7 Feb 2006 17:04:04 - 1.63
> --- src/backend/utils/adt/network.c 10 Feb 2006 04:11:57 -
> ***
> *** 27,32
> --- 27,33
> static int bitncmp(void *l, void *r, int n);
> static bool addressOK(unsigned char *a, int bits, int family);
> static int ip_addrsize(inet *inetptr);
> + static Datum internal_inetpl(inet *ip, int64 iarg);
>
> /*
>* Access macros.
> ***
> *** 1250,1252
> --- 1251,1458
>
> PG_RETURN_DATUM(DirectFunctionCall1(int4in,
> CStringGetDatum(local_port)));
> }
> +
> +
> + Datum
> + inetnot(PG_FUNCTION_ARGS)
> + {
> + inet *ip = PG_GETARG_INET_P(0);
> + inet *dst;
> +
> + dst = (inet *) palloc0(VARHDRSZ + sizeof(inet_struct));
> +
> + {
> + int nb = ip_addrsize(ip);
> + unsigned char *pip = ip_addr(ip);
> + unsigned char *pdst = ip_addr(dst);
> +
> + while (nb-- > 0)
> + pdst[nb] = ~pip[nb];
> + }
> + ip_bits(dst) = ip_bits(ip);
> +
> + ip_family(dst) = ip_family(ip);
> + VARATT_SIZEP(dst) = VARHDRSZ +
> + ((char *) ip_addr(dst) - (char *) VARDATA(dst)) +
> + ip_addrsize(dst);
> +
> + PG_RETURN_INET_P(dst);
> + }
> +
> +
> + Datum
> + inetand(PG_FUNCTION_ARGS)
> + {
> + inet *ip = PG_GETARG_INET_P(0);
> + inet *ip2 = PG_GETARG_INET_P(1);
> + inet *dst;
> +
> + dst = (inet *) palloc0(VARHDRSZ + sizeof(inet_struct));
> +
> + if (ip_family(ip) != ip_family(ip2))
> + ereport(ERROR,
> + (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> + errmsg("mismatch in address family (%d) !=
> (%d)",
> + ip_family(ip),
> ip_family(ip2;
> + else
> + {
> + int nb = ip_addrsize(ip);
> + unsigned char *pip = ip_addr(ip);
> + unsigned char *pip2 = ip_addr(ip2);
> + unsigned char *pdst = ip_addr(dst);
> +
> + while (nb-- > 0)
> + pdst[nb] = pip[nb] & pip2[nb];
> + }
> + ip_bits(dst) = Max(ip_bits(ip), ip_bits(ip2));
> +
> + ip_family(dst) = ip_family(ip);
> + VARATT_SIZ
Re: [PATCHES] [COMMITTERS] pgsql: Allow psql multi-line column values to align
Martijn van Oosterhout writes: > Patch attached. Passes -pedantic on gcc 3.3.5 Applied with some cosmetic cleanups and further fixes for 64-bit problems. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] parallel builds with dependencies
When performing a parallel build (make -j N) with ./configure --enable-depend it often tries to create the .deps directory twice and bails out when it already exists due to a race condition of if doesn't exist, then create. This patch prevents mkdir from returning an error. Kris JurkaIndex: src/Makefile.global.in === RCS file: /projects/cvsroot/pgsql/src/Makefile.global.in,v retrieving revision 1.220 diff -c -r1.220 Makefile.global.in *** src/Makefile.global.in 27 Sep 2005 17:39:32 - 1.220 --- src/Makefile.global.in 10 Feb 2006 22:23:39 - *** *** 536,542 # This converts a .d file in the current directory to a .P file in the .deps # subdirectory, with the dummy targets as explained above. define postprocess-depend ! @if test ! -d $(DEPDIR); then mkdir $(DEPDIR); fi @cp $*.d $(df).P @sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$$//' \ -e '/^$$/ d' -e 's/$$/ :/' < $*.d >> $(df).P --- 536,542 # This converts a .d file in the current directory to a .P file in the .deps # subdirectory, with the dummy targets as explained above. define postprocess-depend ! @if test ! -d $(DEPDIR); then mkdir -p $(DEPDIR); fi @cp $*.d $(df).P @sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$$//' \ -e '/^$$/ d' -e 's/$$/ :/' < $*.d >> $(df).P ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Fix for running from admin account on win32
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > Attached is a patch for initdb only (the other patch stands unchanged). > It will make initdb re-exec itself with a restricted token when > available (since we can only control the security of subprocesses) Applied to HEAD. > There's a bit of shared code with pg_ctl (but not all of the exec stuff, > because there is no need for a job object for initdb). I'm unsure if > it's worth putting something in src/port instead for it, so this version > doesn't. I agree that it seems marginal at this point. But if we find ourselves adding the functionality anyplace else, you should probably factor out the common code into a /port module. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Fix for running from admin account on win32
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > Attached is a two part patch for the admin functionality on win32. > The first part is a simple bugfix to backend/port/win32/security.c. The > function that checks if the user has admin privileges didn't check it > the SID in the token was enabled or not. Applied back to 8.0. > The second part enables pg_ctl to give up admin privleges when starting > the server. Applied to HEAD only. regards, tom lane ---(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] [COMMITTERS] pgsql: Allow psql multi-line column values to align
On Fri, Feb 10, 2006 at 02:13:26PM -0500, Tom Lane wrote:
> For the most part we say "char" where we can and "unsigned char" only
> where it really matters, which is mostly inside code that's
> encoding-aware anyway.
Well, I've done this and avoided changing any public interfaces. ie the
libpq interface remains unsigned, as does the psql formatting code, but
the printTable stuff only is for the parts that actually do
formatting...
Patch attached. Passes -pedantic on gcc 3.3.5
Have a nice day,
--
Martijn van Oosterhout http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
Index: src/bin/psql/mbprint.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/mbprint.c,v
retrieving revision 1.19
diff -u -r1.19 mbprint.c
--- src/bin/psql/mbprint.c 10 Feb 2006 00:39:04 - 1.19
+++ src/bin/psql/mbprint.c 10 Feb 2006 21:46:49 -
@@ -158,11 +158,11 @@
{
int chlen, chwidth;
- chlen = PQmblen(pwcs, encoding);
+ chlen = PQmblen( (char*)pwcs, encoding);
if (chlen > len)
break; /* Invalid string */
- chwidth = PQdsplen(pwcs, encoding);
+ chwidth = PQdsplen( (char*)pwcs, encoding);
if (chwidth > 0)
width += chwidth;
@@ -191,10 +191,10 @@
for (; *pwcs && len > 0; pwcs += chlen)
{
- chlen = PQmblen(pwcs, encoding);
+ chlen = PQmblen( (char*)pwcs, encoding);
if (len < (size_t)chlen)
break;
- w = PQdsplen(pwcs, encoding);
+ w = PQdsplen( (char*)pwcs, encoding);
if (chlen == 1) /* ASCII char */
{
@@ -257,14 +257,14 @@
chlen = 0;
int linewidth = 0;
- char *ptr = lines->ptr; /* Pointer to data area */
+ unsigned char *ptr = lines->ptr; /* Pointer to data area */
for (; *pwcs && len > 0; pwcs += chlen)
{
- chlen = PQmblen(pwcs,encoding);
+ chlen = PQmblen( (char*)pwcs,encoding);
if (len < (size_t)chlen)
break;
- w = PQdsplen(pwcs,encoding);
+ w = PQdsplen( (char*)pwcs,encoding);
if (chlen == 1) /* single byte char char */
{
@@ -282,13 +282,13 @@
}
else if (*pwcs == '\r') /* Linefeed */
{
- strcpy(ptr, "\\r");
+ strcpy( (char*)ptr, "\\r");
linewidth += 2;
ptr += 2;
}
else if (w <= 0) /* Other control char */
{
- sprintf(ptr, "\\x%02X", *pwcs);
+ sprintf( (char*)ptr, "\\x%02X", *pwcs);
linewidth += 4;
ptr += 4;
}
@@ -301,13 +301,13 @@
else if (w <= 0) /* Non-ascii control char */
{
if (encoding == PG_UTF8)
- sprintf(ptr, "\\u%04X", utf2ucs(pwcs));
+ sprintf( (char*)ptr, "\\u%04X", utf2ucs(pwcs));
else
/* This case cannot happen in the current
* code because only UTF-8 signals multibyte
* control characters. But we may need to
* support it at some stage */
- sprintf(ptr, "\\u");
+ sprintf( (char*)ptr, "\\u");
ptr += 6;
linewidth += 6;
Index: src/bin/psql/print.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/print.c,v
retrieving revision 1.81
diff -u -r1.81 print.c
--- src/bin/psql/print.c10 Feb 2006 15:48:05 - 1.81
+++ src/bin/psql/print.c10 Feb 2006 21:46:49 -
@@ -357,8 +357,8 @@
{
unsigned int col_count = 0;
unsigned int cell_count = 0;
- unsigned int i,
- tmp;
+ unsigned int i;
+ int tmp;
unsigned int *widths,
total_w;
unsigned int *heights;
@@ -588,7 +588,7 @@
* this_line->width <
strlen(this_ptr) and we
Re: [PATCHES] [COMMITTERS] pgsql: Allow psql multi-line column values to align
Martijn van Oosterhout writes: > Does PostgreSQL have a policy on the signedness of strings? For the most part we say "char" where we can and "unsigned char" only where it really matters, which is mostly inside code that's encoding-aware anyway. It was only fairly recently that we cleaned the code up to avoid signedness warnings, but now that that's done I don't want to backtrack on it. What I'd suggest is taking a close look at the set of functions you have and trying to identify a layer that should be "unsigned char" versus upper layers that can just say "char". regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [COMMITTERS] pgsql: Allow psql multi-line column values to align
On Fri, Feb 10, 2006 at 06:16:07PM +0100, Martijn van Oosterhout wrote: > Thanks for the tip. I'm currently merging CVS with my version and > getting a lot of conflicts (whitespace variations). > > It's fairly simple changes AFAICS. Just need to fix the declarations of > a few variables. Does PostgreSQL have a policy on the signedness of strings? When I was making the patch I generally used "unsigned char" to try to emphasise that these are not characters, they are bytes of an encoding. But this doesn't play well with existing functions like PQdsplen and PQmblen. At this point I'm thinking of dropping the "unsigned" everywhere and just being really careful of comparisons. OTOH, it's really those two functions being inconsistant because the underlying functions do use unsigned. Thoughts? Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [COMMITTERS] pgsql: Allow psql multi-line column values to align
On Fri, Feb 10, 2006 at 12:09:13PM -0500, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian writes: > > > Martijn van Oosterhout wrote: > > >> I'll try to address these warnings (unless someone beats me to it). > > > > > I am looking at it now but I can't find the compiler flag to get those > > > warnings. I am gcc 2.95.3. > > > > You'd need a newer compiler. > > gcc -pedantic is showing it to me. Thanks for the tip. I'm currently merging CVS with my version and getting a lot of conflicts (whitespace variations). It's fairly simple changes AFAICS. Just need to fix the declarations of a few variables. -- Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. signature.asc Description: Digital signature
Re: [PATCHES] [COMMITTERS] pgsql: Allow psql multi-line column values
Tom Lane wrote: > Bruce Momjian writes: > > Martijn van Oosterhout wrote: > >> I'll try to address these warnings (unless someone beats me to it). > > > I am looking at it now but I can't find the compiler flag to get those > > warnings. I am gcc 2.95.3. > > You'd need a newer compiler. gcc -pedantic is showing it to me. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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] [COMMITTERS] pgsql: Allow psql multi-line column values to align
Bruce Momjian writes: > Martijn van Oosterhout wrote: >> I'll try to address these warnings (unless someone beats me to it). > I am looking at it now but I can't find the compiler flag to get those > warnings. I am gcc 2.95.3. You'd need a newer compiler. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [COMMITTERS] pgsql: Allow psql multi-line column values
Martijn van Oosterhout wrote: -- Start of PGP signed section. > On Fri, Feb 10, 2006 at 11:02:41AM -0500, Tom Lane wrote: > > Bruce Momjian writes: > > > OK, I have applied your patch to psql and Teodor has adjusted the > > > tsearch2 expected results. I can't seem to run pgcrypto without getting > > > PRNG errors, so I expect my SSL is too old. Would you send me your > > > pgcrypto/regression.diff? Thanks. > > > > I fixed that already. Please see about fixing the compiler warnings you > > introduced. On a 64-bit machine there are even more, and the int vs > > size_t ones are definitely portability problems. > > Ouch. I submitted this patch so long ago I figured it'd gotten lost. I > was actually considering preparing a new version against HEAD. We loose nothing! :-) > I'll try to address these warnings (unless someone beats me to it). I am looking at it now but I can't find the compiler flag to get those warnings. I am gcc 2.95.3. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [COMMITTERS] pgsql: Allow psql multi-line column values to align
On Fri, Feb 10, 2006 at 11:02:41AM -0500, Tom Lane wrote: > Bruce Momjian writes: > > OK, I have applied your patch to psql and Teodor has adjusted the > > tsearch2 expected results. I can't seem to run pgcrypto without getting > > PRNG errors, so I expect my SSL is too old. Would you send me your > > pgcrypto/regression.diff? Thanks. > > I fixed that already. Please see about fixing the compiler warnings you > introduced. On a 64-bit machine there are even more, and the int vs > size_t ones are definitely portability problems. Ouch. I submitted this patch so long ago I figured it'd gotten lost. I was actually considering preparing a new version against HEAD. I'll try to address these warnings (unless someone beats me to it). -- Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. signature.asc Description: Digital signature
Re: [PATCHES] [COMMITTERS] pgsql: Allow psql multi-line column values to align
Bruce Momjian writes: > OK, I have applied your patch to psql and Teodor has adjusted the > tsearch2 expected results. I can't seem to run pgcrypto without getting > PRNG errors, so I expect my SSL is too old. Would you send me your > pgcrypto/regression.diff? Thanks. I fixed that already. Please see about fixing the compiler warnings you introduced. On a 64-bit machine there are even more, and the int vs size_t ones are definitely portability problems. regards, tom lane print.c: In function 'print_aligned_text': print.c:408: warning: pointer targets in passing argument 4 of 'pg_wcssize' differ in signedness print.c:428: warning: pointer targets in passing argument 4 of 'pg_wcssize' differ in signedness print.c:479: warning: pointer targets in passing argument 4 of 'pg_wcssize' differ in signedness print.c:588: warning: pointer targets in passing argument 1 of 'format_numeric_locale' differ in signedness print.c:589: warning: field width should have type 'int', but argument 3 has type 'size_t' print.c: In function 'print_aligned_vertical': print.c:690: warning: pointer targets in passing argument 4 of 'pg_wcssize' differ in signedness print.c:714: warning: pointer targets in passing argument 4 of 'pg_wcssize' differ in signedness print.c:823: warning: pointer targets in passing argument 1 of 'format_numeric_locale' differ in signedness print.c:827: warning: field width should have type 'int', but argument 4 has type 'size_t' print.c: In function 'printQuery': print.c:1753: warning: pointer targets in passing argument 1 of 'mbvalidate' differ in signedness print.c:1753: warning: pointer targets in assignment differ in signedness print.c:1764: warning: pointer targets in passing argument 1 of 'mbvalidate' differ in signedness print.c:1764: warning: pointer targets in assignment differ in signedness mbprint.c: In function 'pg_wcswidth': mbprint.c:161: warning: pointer targets in passing argument 1 of 'PQmblen' differ in signedness mbprint.c:165: warning: pointer targets in passing argument 1 of 'PQdsplen' differ in signedness mbprint.c: In function 'pg_wcssize': mbprint.c:194: warning: pointer targets in passing argument 1 of 'PQmblen' differ in signedness mbprint.c:197: warning: pointer targets in passing argument 1 of 'PQdsplen' differ in signedness mbprint.c: In function 'pg_wcsformat': mbprint.c:260: warning: pointer targets in initialization differ in signedness mbprint.c:264: warning: pointer targets in passing argument 1 of 'PQmblen' differ in signedness mbprint.c:267: warning: pointer targets in passing argument 1 of 'PQdsplen' differ in signedness mbprint.c:281: warning: pointer targets in assignment differ in signedness print.c: In function 'print_aligned_text': print.c:408: warning: pointer targets in passing argument 4 of 'pg_wcssize' differ in signedness print.c:428: warning: pointer targets in passing argument 4 of 'pg_wcssize' differ in signedness print.c:479: warning: pointer targets in passing argument 4 of 'pg_wcssize' differ in signedness print.c:588: warning: pointer targets in passing argument 1 of 'format_numeric_locale' differ in signedness print.c:589: warning: field width should have type 'int', but argument 3 has type 'size_t' print.c: In function 'print_aligned_vertical': print.c:690: warning: pointer targets in passing argument 4 of 'pg_wcssize' differ in signedness print.c:714: warning: pointer targets in passing argument 4 of 'pg_wcssize' differ in signedness print.c:823: warning: pointer targets in passing argument 1 of 'format_numeric_locale' differ in signedness print.c:827: warning: field width should have type 'int', but argument 4 has type 'size_t' print.c: In function 'printQuery': print.c:1753: warning: pointer targets in passing argument 1 of 'mbvalidate' differ in signedness print.c:1753: warning: pointer targets in assignment differ in signedness print.c:1764: warning: pointer targets in passing argument 1 of 'mbvalidate' differ in signedness print.c:1764: warning: pointer targets in assignment differ in signedness mbprint.c: In function 'pg_wcswidth': mbprint.c:161: warning: pointer targets in passing argument 1 of 'PQmblen' differ in signedness mbprint.c:165: warning: pointer targets in passing argument 1 of 'PQdsplen' differ in signedness mbprint.c: In function 'pg_wcssize': mbprint.c:194: warning: pointer targets in passing argument 1 of 'PQmblen' differ in signedness mbprint.c:197: warning: pointer targets in passing argument 1 of 'PQdsplen' differ in signedness mbprint.c: In function 'pg_wcsformat': mbprint.c:260: warning: pointer targets in initialization differ in signedness mbprint.c:264: warning: pointer targets in passing argument 1 of 'PQmblen' differ in signedness mbprint.c:267: warning: pointer targets in passing argument 1 of 'PQdsplen' differ in signedness mbprint.c:281: warning: pointer targets in assignment differ in signedness ---(end of broadcast)
Re: [PATCHES] [COMMITTERS] pgsql: Allow psql multi-line column values to align
OK, I have applied your patch to psql and Teodor has adjusted the tsearch2 expected results. I can't seem to run pgcrypto without getting PRNG errors, so I expect my SSL is too old. Would you send me your pgcrypto/regression.diff? Thanks. --- Kris Jurka wrote: > > > On Thu, 9 Feb 2006, Bruce Momjian wrote: > > > Log Message: > > --- > > Allow psql multi-line column values to align in the proper columns > > > > There is a problem with this on AIX. > > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=asp&dt=2006-02-10%2006:23:00 > > For tables that have no columns AIX thinks it has an out of memory error. > src/bin/psql/print.c:pg_local_calloc bails out if calloc returns NULL. I > believe AIX is returning NULL for calloc with a count of zero. Efforts > are made not to call pg_local_calloc with a count of zero, but one place > is missed, the attached patch fixes that. > > Additionally there are a whole lot of of signedness warnings introduced > which I've attached. > > Kris Jurka Content-Description: [ Attachment, skipping... ] Content-Description: [ 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| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] ignore_killed_tuples is always true
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes: > I found IndexScanDesc->ignore_killed_tuples is always true. > Is this still needed? What is the point of removing it? You cannot argue that saving one if-test per tuple is a worthwhile speedup. regards, tom lane ---(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] TODO-Item: B-tree fillfactor control
On Fri, 2006-02-10 at 19:12 +0900, ITAGAKI Takahiro wrote: > This is a revised patch for index fillfactor control: > - Split MAX_PCTFREE into three for each index method. > - B-tree indexes use their own settings when rightmost page is split. > - Fix a bug that GUC is modified when index building is canceled. > - Add some documentations. > Simon Riggs <[EMAIL PROTECTED]> wrote: > > > Do you have any performance numbers for the extreme settings? It may be > > worth having different max limits for each of the index types, since > > they differ so widely in algorithms. > > Different max limits are done. > I worry about whether index works properly on high PCTFREE settings. I found > hash has its own sanity checking, but I don't know other indexes have. Thanks. > > I'm surprised that you do not use the parameter to control the RIGHTMOST > > index block split factor for B-trees, which remains at a constant 67%. > > The PCTFREE only seems to apply at CREATE INDEX time. > > Thanks for pointing out. I did not inadvertently use fillfactor on > the rightmost page. With the revised patch, PCTFREE will be considered > in such cases. > > # CREATE TABLE test (i int); > # INSERT INTO test SELECT generate_series(1, 10); > # CREATE INDEX btree ON test USING btree (i) PCTFREE 0; > # SELECT relpages from pg_class where relname ='btree'; > relpages | 249 > # INSERT INTO test SELECT generate_series(11, 20); > # SELECT relpages from pg_class where relname ='btree'; > relpages | 497<-- +99.6% > This is great. > But default settings will change. Is this ok? > > | | patched | > | now | free=10 | free=0 | > -+-+-++- > leaf (REINDEX) | 10 | 10 | 0 | > leaf (RIGHTMOST) | 30 | 10 | 0 | = leaf > node (REINDEX) | 30 | 30 | 0 | = 3*leaf I think thats appropriate; lets see what others think. > > If we support PCTFREE for compatibility reasons should we not also > > support the alternative FILLFACTOR syntax also? I see no reason to > > favour Oracle/DB2 compatability at the expense of SQLServer > > compatibility. > > There are few synonyms in PostgreSQL, so I think it is better for us to > adopt only either one. I like FILLFACTOR personally, but compatibility > with Oracle is more important to users around me. OK, no probs. Reading through rest of patch now. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] ignore_killed_tuples is always true
I found IndexScanDesc->ignore_killed_tuples is always true. Is this still needed? Also, I cannot understand why gistgetmulti calls gistnext with ignore_killed_tuples = false. We can always ignore LP_DELETEed tuples, right? --- ITAGAKI Takahiro NTT Cyber Space Laboratories remove-ignore_killed_tuples.patch Description: Binary data ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
