[PATCHES] Patch for - Change FETCH/MOVE to use int8
This patch is for the following TODO item.
SQL command:
-/Change LIMIT/OFFSET and FETCH/MOVE to use int8
/Since the limit/offset patch is already applied,
this patch is meant for Fetch/Move query.
I have tested the patch and it works for int64 values.
Please verify this.
Thanks
Dhanaraj
/
/
*** ./src/backend/commands/portalcmds.c.orig Sat Aug 12 23:04:54 2006
--- ./src/backend/commands/portalcmds.c Sat Aug 12 23:04:53 2006
***
*** 176,183
char *completionTag)
{
Portal portal;
! long nprocessed;
/*
* Disallow empty-string cursor name (conflicts with protocol-level
* unnamed portal).
--- 176,183
char *completionTag)
{
Portal portal;
! int64 nprocessed;
/*
* Disallow empty-string cursor name (conflicts with protocol-level
* unnamed portal).
***
*** 209,215
/* Return command status if wanted */
if (completionTag)
! snprintf(completionTag, COMPLETION_TAG_BUFSIZE, %s %ld,
stmt-ismove ? MOVE : FETCH,
nprocessed);
}
--- 209,215
/* Return command status if wanted */
if (completionTag)
! snprintf(completionTag, COMPLETION_TAG_BUFSIZE, %s %lld,
stmt-ismove ? MOVE : FETCH,
nprocessed);
}
*** ./src/backend/parser/gram.y.orig Sat Aug 12 23:04:57 2006
--- ./src/backend/parser/gram.y Sun Aug 13 00:06:28 2006
***
*** 116,122
%union
{
! int ival;
charchr;
char*str;
const char *keyword;
--- 116,122
%union
{
! int64ival;
charchr;
char*str;
const char *keyword;
***
*** 1180,1192
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(INTERVAL(%d) precision must not be negative,
! $3)));
if ($3 MAX_INTERVAL_PRECISION)
{
ereport(WARNING,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(INTERVAL(%d) precision reduced to maximum allowed, %d,
! $3, MAX_INTERVAL_PRECISION)));
$3 = MAX_INTERVAL_PRECISION;
}
--- 1180,1192
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(INTERVAL(%d) precision must not be negative,
! (int)$3)));
if ($3 MAX_INTERVAL_PRECISION)
{
ereport(WARNING,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(INTERVAL(%d) precision reduced to maximum allowed, %d,
! (int)$3, MAX_INTERVAL_PRECISION)));
$3 = MAX_INTERVAL_PRECISION;
}
***
*** 2620,2626
ICONST
{
char buf[64];
! snprintf(buf, sizeof(buf), %d, $1);
$$ = makeString(pstrdup(buf));
}
| FCONST{ $$ = makeString($1); }
--- 2620,2626
ICONST
{
char buf[64];
! snprintf(buf, sizeof(buf), %d, (int)$1);
$$ = makeString(pstrdup(buf));
}
| FCONST{ $$ = makeString($1); }
***
*** 6281,6293
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(INTERVAL(%d) precision must not be negative,
! $3)));
if ($3 MAX_INTERVAL_PRECISION)
{
ereport(WARNING,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(INTERVAL(%d) precision reduced to maximum allowed, %d,
! $3, MAX_INTERVAL_PRECISION)));
$3 = MAX_INTERVAL_PRECISION;
}
$$-typmod = INTERVAL_TYPMOD($3, $5);
--- 6281,6293
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(INTERVAL(%d) precision must not be negative,
! (int)$3)));
if ($3 MAX_INTERVAL_PRECISION)
{
ereport(WARNING,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(INTERVAL(%d) precision reduced to maximum allowed, %d,
! (int)$3, MAX_INTERVAL_PRECISION)));
$3 = MAX_INTERVAL_PRECISION;
}
$$-typmod = INTERVAL_TYPMOD($3, $5);
***
*** 6408,6419
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(NUMERIC precision %d must be between 1 and %d,
! $2, NUMERIC_MAX_PRECISION)));
if ($4 0 || $4 $2)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(NUMERIC scale %d must be between 0 and precision %d,
! $4, $2)));
$$ = (($2 16) | $4) + VARHDRSZ;
}
--- 6408,6419
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(NUMERIC precision %d must be between 1 and %d,
! (int)$2, NUMERIC_MAX_PRECISION)));
if ($4 0 || $4 $2)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(NUMERIC scale %d must be between 0 and precision %d,
! (int)$4, (int)$2)));
$$ = (($2 16) | $4) + VARHDRSZ;
}
***
*** 6423,6429
Re: [PATCHES] better support of out parameters in plperl
I wrote:
Pavel Stehule wrote:
Hello,
I send two small patches. First does conversion from perl to
postgresql array in OUT parameters. Second patch allow hash form
output from procedures with one OUT argument.
I will try to review these in the next 2 weeks unless someone beats me
to it.
I have reviewed this lightly, as committed by Bruce, and have some
concerns. Unfortunately, the deathof my main workstation has cost me
much of the time I intended to use for a more thorough review, so there
may well be more issues than are outlined here.
First, it is completely undocumented.
Second, this comment is at best confusing:
/* if value is ref on array do to pg string array conversion */
Third, it appears to assume that we will have names for all OUT params. But
names are optional, as I understand it. Arguably, we should be treating the
returns positionally, and thus return an arrayref when there are OYT params,
not a hashref, and ignore the names - after all, all perl function args are
nameless, in fact, even if you use a naming convention to refer to them.
Fourth, I don't understand the change: allow hash form output from procedures with
one OUT argument. That seems very non-orthogonal, and I can't see any good reason
for it.
Lastly, if you look at the expected output as committed,it appears to have been
prepared without being actually examined, for example:
CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
return {a='ahoj'};
$$ LANGUAGE plperl;
SELECT '05' AS i,a FROM test05();
i |a
+-
05 | HASH(0x8558f9c)
(1 row)
what???
And now that I look I see every buildfarm box broken on PLCheck. That's no
surprise at all.
The conversation regarding these features appears only to have started on July
28th, which was probably much too late given some of the issues. Unless we can
solve these issues very fast I would be inclined to say this should be tabled
for 8.3. I think this is a fairly good illustration of the danger of springing
a feature, largely undiscussed, on the community just about freeze time.
cheers
andrew
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [PATCHES] better support of out parameters in plperl
Based on this analysis, and problems with differing regression results
on different platforms, this attached patch has been reverted.
---
Andrew Dunstan wrote:
I wrote:
Pavel Stehule wrote:
Hello,
I send two small patches. First does conversion from perl to
postgresql array in OUT parameters. Second patch allow hash form
output from procedures with one OUT argument.
I will try to review these in the next 2 weeks unless someone beats me
to it.
I have reviewed this lightly, as committed by Bruce, and have some
concerns. Unfortunately, the deathof my main workstation has cost me
much of the time I intended to use for a more thorough review, so there
may well be more issues than are outlined here.
First, it is completely undocumented.
Second, this comment is at best confusing:
/* if value is ref on array do to pg string array conversion */
Third, it appears to assume that we will have names for all OUT params. But
names are optional, as I understand it. Arguably, we should be treating the
returns positionally, and thus return an arrayref when there are OYT params,
not a hashref, and ignore the names - after all, all perl function args are
nameless, in fact, even if you use a naming convention to refer to them.
Fourth, I don't understand the change: allow hash form output from
procedures with one OUT argument. That seems very non-orthogonal, and I
can't see any good reason for it.
Lastly, if you look at the expected output as committed,it appears to have
been prepared without being actually examined, for example:
CREATE OR REPLACE FUNCTION test05(OUT a varchar) AS $$
return {a='ahoj'};
$$ LANGUAGE plperl;
SELECT '05' AS i,a FROM test05();
i |a
+-
05 | HASH(0x8558f9c)
(1 row)
what???
And now that I look I see every buildfarm box broken on PLCheck. That's no
surprise at all.
The conversation regarding these features appears only to have started on
July 28th, which was probably much too late given some of the issues. Unless
we can solve these issues very fast I would be inclined to say this should be
tabled for 8.3. I think this is a fairly good illustration of the danger of
springing a feature, largely undiscussed, on the community just about freeze
time.
cheers
andrew
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/pl/plperl/plperl.c
===
RCS file: /cvsroot/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.115
retrieving revision 1.116
diff -c -r1.115 -r1.116
*** src/pl/plperl/plperl.c 12 Aug 2006 04:16:45 - 1.115
--- src/pl/plperl/plperl.c 13 Aug 2006 02:37:11 - 1.116
***
*** 1,7
/**
* plperl.c - perl as a procedural language for PostgreSQL
*
! * $PostgreSQL: pgsql/src/pl/plperl/plperl.c,v 1.115 2006/08/12 04:16:45 momjian Exp $
*
**/
--- 1,7
/**
* plperl.c - perl as a procedural language for PostgreSQL
*
! * $PostgreSQL: pgsql/src/pl/plperl/plperl.c,v 1.116 2006/08/13 02:37:11 momjian Exp $
*
**/
***
*** 52,57
--- 52,58
FmgrInfo result_in_func; /* I/O function and arg for result type */
Oid result_typioparam;
int nargs;
+ int num_out_args; /* number of out arguments */
FmgrInfo arg_out_func[FUNC_MAX_ARGS];
bool arg_is_rowtype[FUNC_MAX_ARGS];
SV *reference;
***
*** 115,120
--- 116,124
static void plperl_init_shared_libs(pTHX);
static HV *plperl_spi_execute_fetch_result(SPITupleTable *, int, int);
+ static SV *plperl_convert_to_pg_array(SV *src);
+ static SV *plperl_transform_result(plperl_proc_desc *prodesc, SV *result);
+
/*
* This routine is a crock, and so is everyplace that calls it. The problem
* is that the cached form of plperl functions/queries is allocated permanently
***
*** 404,410
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg(Perl hash contains nonexistent column \%s\,
key)));
! if (SvOK(val) SvTYPE(val) != SVt_NULL)
values[attn - 1] = SvPV(val, PL_na);
}
hv_iterinit(perlhash);
--- 408,419
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg(Perl hash contains nonexistent column \%s\,
key)));
!
! /* if value is ref on array do to pg string array conversion */
! if (SvTYPE(val) == SVt_RV
! SvTYPE(SvRV(val)) == SVt_PVAV)
! values[attn - 1] =
Re: [PATCHES] [HACKERS] Custom variable class segmentation fault
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
The latest HEAD is segfaulting on startup if I have the following
lines in postgresql.conf:
custom_variable_classes = 'plperl'
plperl.use_strict = on
Bruce, please re-revert that GUC patch and don't put it back in until
someone like Peter or me has actually reviewed it. My faith in it has
gone to zero, and I don't think you are able to fix it either.
Peter had already reviewed it and given comments.
There were three things wrong with the original patch:
o spacing, e.g. if( x =- 1 )
o an incorrect API for memory freeing by parse_value()
o verify_config_option() didn't consider custom variables
These have all been corrected, so I don't see the value in removing the
patch now that it is working. I have attached the three GUC patches
that were applied to CVS, so if someone wants corrections or removal
based on specific issues, please let me know.
BTW, do I need to mention that the plperl patch is breaking the
buildfarm again?
That has been reverted, because of the regression failures and Andrew's
analysis.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.42
retrieving revision 1.43
diff -c -r1.42 -r1.43
*** src/backend/utils/misc/guc-file.l 12 Aug 2006 04:12:41 - 1.42
--- src/backend/utils/misc/guc-file.l 13 Aug 2006 01:30:17 - 1.43
***
*** 4,10
*
* Copyright (c) 2000-2006, PostgreSQL Global Development Group
*
! * $PostgreSQL: pgsql/src/backend/utils/misc/guc-file.l,v 1.42 2006/08/12 04:12:41 momjian Exp $
*/
%{
--- 4,10
*
* Copyright (c) 2000-2006, PostgreSQL Global Development Group
*
! * $PostgreSQL: pgsql/src/backend/utils/misc/guc-file.l,v 1.43 2006/08/13 01:30:17 momjian Exp $
*/
%{
***
*** 50,56
static bool ParseConfigFile(const char *config_file, const char *calling_file,
int depth, GucContext context, int elevel,
struct name_value_pair **head_p,
! struct name_value_pair **tail_p);
static void free_name_value_list(struct name_value_pair * list);
static char *GUC_scanstr(const char *s);
--- 50,57
static bool ParseConfigFile(const char *config_file, const char *calling_file,
int depth, GucContext context, int elevel,
struct name_value_pair **head_p,
! struct name_value_pair **tail_p,
! int *varcount);
static void free_name_value_list(struct name_value_pair * list);
static char *GUC_scanstr(const char *s);
***
*** 114,121
void
ProcessConfigFile(GucContext context)
{
! int elevel;
struct name_value_pair *item, *head, *tail;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
--- 115,124
void
ProcessConfigFile(GucContext context)
{
! int elevel, i;
struct name_value_pair *item, *head, *tail;
+ bool *apply_list = NULL;
+ int varcount = 0;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
***
*** 134,158
if (!ParseConfigFile(ConfigFileName, NULL,
0, context, elevel,
! head, tail))
goto cleanup_list;
/* Check if all options are valid */
! for (item = head; item; item = item-next)
{
! if (!set_config_option(item-name, item-value, context,
! PGC_S_FILE, false, false))
goto cleanup_list;
}
/* If we got here all the options checked out okay, so apply them. */
! for (item = head; item; item = item-next)
! {
! set_config_option(item-name, item-value, context,
! PGC_S_FILE, false, true);
! }
! cleanup_list:
free_name_value_list(head);
}
--- 137,192
if (!ParseConfigFile(ConfigFileName, NULL,
0, context, elevel,
! head, tail, varcount))
goto cleanup_list;
+ /* Can we allocate memory here, what about leaving here prematurely? */
+ apply_list = (bool *) palloc(sizeof(bool) * varcount);
+
/* Check if all options are valid */
! for (item = head, i = 0; item; item = item-next, i++)
{
! bool isEqual, isContextOk;
!
! if (!verify_config_option(item-name, item-value, context,
! PGC_S_FILE, isEqual, isContextOk))
! {
! ereport(elevel,
! (errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
! errmsg(configuration file is invalid)));
goto cleanup_list;
+ }
+
+ if (isContextOk == false)
+ {
+ apply_list[i] = false;
+ if (context == PGC_SIGHUP)
+ {
+ if (isEqual == false)
+ ereport(elevel,
+ (errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
+ errmsg(parameter \%s\ cannot be changed after server start; configuration file change ignored,
+ item-name)));
+ }
+ else
+ /* if it
Re: [PATCHES] Patch for - Change FETCH/MOVE to use int8
Dhanaraj M wrote:
I had a quick look:
***
*** 209,215
/* Return command status if wanted */
if (completionTag)
! snprintf(completionTag, COMPLETION_TAG_BUFSIZE, %s %ld,
stmt-ismove ? MOVE : FETCH,
nprocessed);
}
--- 209,215
/* Return command status if wanted */
if (completionTag)
! snprintf(completionTag, COMPLETION_TAG_BUFSIZE, %s %lld,
stmt-ismove ? MOVE : FETCH,
nprocessed);
}
You shouldn't be using %lld as it breaks on some platforms.
Use INT64_FORMAT instead.
--- ./src/backend/parser/gram.y Sun Aug 13 00:06:28 2006
***
*** 116,122
%union
{
! int ival;
charchr;
char*str;
const char *keyword;
--- 116,122
%union
{
! int64 ival;
charchr;
char*str;
const char *keyword;
I don't think this is the right approach. Maybe it would be reasonable
to add another arm to the %union instead, not sure. The problem is the
amount of ugly casts you have to use below. The scanner code seems to
think that a constant larger than the biggest int4 should be treated as
float, so I'm not sure why this would work anyway.
***
*** 767,773
/*
* Force the queryDesc destination to the right thing. This supports
* MOVE, for example, which will pass in dest = DestNone. This is okay
to
! * change as long as we do it on every fetch. (The Executor must not
* assume that dest never changes.)
*/
if (queryDesc)
--- 767,773
/*
* Force the queryDesc destination to the right thing. This supports
* MOVE, for example, which will pass in dest = DestNone. This is okay
to
! * change as int64 as we do it on every fetch. (The Executor must not
* assume that dest never changes.)
*/
if (queryDesc)
Too enthusiastic about the search'n replace I think.
I stopped reading at this point.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] Patch for - Change FETCH/MOVE to use int8
Alvaro Herrera [EMAIL PROTECTED] writes: I don't think this is the right approach. Maybe it would be reasonable to add another arm to the %union instead, not sure. The problem is the amount of ugly casts you have to use below. The scanner code seems to think that a constant larger than the biggest int4 should be treated as float, so I'm not sure why this would work anyway. I'm not sure that I see the point of this at all. ISTM the entire reason for using a cursor is that you're going to fetch the results in bite-size pieces. I don't see the current Postgres source code surviving into the era where 2G rows is considered bite-size ;-) I thought the int8-LIMIT patch was equally pointless, btw, but at least it was not very invasive. This one is not passing the minimum usefulness-to-ugliness ratio for me. 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] [HACKERS] SO_SNDBUF size is small on win32?
Hi, From: Bruce Momjian [EMAIL PROTECTED] Subject: Re: [PATCHES] [HACKERS] SO_SNDBUF size is small on win32? Date: Fri, 11 Aug 2006 16:44:23 -0400 (EDT) Based on this patch and comments, I have applied a patch that sets the buffer to 32k, and adds the URL in a comment. Is it backported to 8.1.x and 8.0.x? Regards, -- Yoshiyuki Asaba [EMAIL PROTECTED] ---(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] Patch for - Change FETCH/MOVE to use int8
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: I don't think this is the right approach. Maybe it would be reasonable to add another arm to the %union instead, not sure. The problem is the amount of ugly casts you have to use below. The scanner code seems to think that a constant larger than the biggest int4 should be treated as float, so I'm not sure why this would work anyway. I'm not sure that I see the point of this at all. ISTM the entire reason for using a cursor is that you're going to fetch the results in bite-size pieces. I don't see the current Postgres source code surviving into the era where 2G rows is considered bite-size ;-) Think MOVE to a specific section of the cursor 2gig. I can see that happening. -- 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] Patch for - Change FETCH/MOVE to use int8
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: I'm not sure that I see the point of this at all. ISTM the entire reason for using a cursor is that you're going to fetch the results in bite-size pieces. I don't see the current Postgres source code surviving into the era where 2G rows is considered bite-size ;-) Think MOVE to a specific section of the cursor 2gig. I can see that happening. Yeah, and by the time it happens you'll have gotten bored and found something else to do. With no support in the system for random access to a cursor result, this is just about as useless as the FETCH case. In any case I agree with Alvaro's comment: the way to support int8 in a FETCH/MOVE command is not to try to convert the entire rest of the grammar to int8 instead of int4 as its native datatype. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] pgstattuple extension for indexes
Bruce,
Attached patch has been cleaned up,
and modified to be able to work with CVS HEAD.
Thanks.
Satoshi Nagayasu wrote:
Alvaro,
Alvaro Herrera wrote:
Huh, I bet it works with 8.1.4, but it doesn't work on CVS HEAD:
/pgsql/source/00orig/contrib/pgstattuple/pgstatindex.c: In function
'GetBTPageStatistics':
/pgsql/source/00orig/contrib/pgstattuple/pgstatindex.c:182: error: 'BTItem'
undeclared (first use in this function)
While you're at it, please consider removing C++ style comments and
unused code.
Formatting is way off as well, but I guess that is easily fixed with
pgindent.
Thanks for comments. I'm going to fix my patch from now.
Regarding the pg_relpages function, why do you think it's necessary?
(It returns the true number of blocks of a given relation). It may
belong into core given a reasonable use case, but otherwise it doesn't
seem to belong into pgstatindex (or pgstattuple for that matter).
I wanted to sample some pages from the table/index, and get their statistics
to know table/index conditions. I know pgstattuple() reports table
statistics, however, pgstattuple() generates heavy CPU and I/O load.
When we need to sample some pages from table/index, we need to know
true number of blocks.
I have another function, called pgstatpage(), to get information inside
a single block/page statistics of the table. pg_relpages() will be used
with this.
Sorry for not mentioned in previous post about pgstatpage(),
but I've remembered about it just now.
Many memories in my brain have already `paged-out` (too busy in last few
months),
and some of them got `out-of-memory`. :^)
Thanks.
--
NAGAYASU Satoshi [EMAIL PROTECTED]
Phone: +81-3-3523-8122
diff -ruN pgstattuple.orig/Makefile pgstattuple/Makefile
--- pgstattuple.orig/Makefile 2006-02-27 21:54:40.0 +0900
+++ pgstattuple/Makefile2006-08-14 09:28:58.0 +0900
@@ -6,7 +6,7 @@
#
#-
-SRCS = pgstattuple.c
+SRCS = pgstattuple.c pgstatindex.c
MODULE_big = pgstattuple
OBJS = $(SRCS:.c=.o)
diff -ruN pgstattuple.orig/pgstatindex.c pgstattuple/pgstatindex.c
--- pgstattuple.orig/pgstatindex.c 1970-01-01 09:00:00.0 +0900
+++ pgstattuple/pgstatindex.c 2006-08-14 11:24:23.0 +0900
@@ -0,0 +1,706 @@
+/*
+ * pgstatindex
+ *
+ * Copyright (c) 2006 Satoshi Nagayasu [EMAIL PROTECTED]
+ *
+ * Permission to use, copy, modify, and distribute this software and
+ * its documentation for any purpose, without fee, and without a
+ * written agreement is hereby granted, provided that the above
+ * copyright notice and this paragraph and the following two
+ * paragraphs appear in all copies.
+ *
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE TO ANY PARTY FOR DIRECT,
+ * INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING
+ * LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS
+ * DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * THE AUTHOR SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN AS
+ * IS BASIS, AND THE AUTHOR HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE,
+ * SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
+ */
+
+#include postgres.h
+
+#include fmgr.h
+#include funcapi.h
+#include access/heapam.h
+#include access/itup.h
+#include access/nbtree.h
+#include access/transam.h
+#include catalog/namespace.h
+#include catalog/pg_type.h
+#include utils/builtins.h
+#include utils/inval.h
+
+PG_FUNCTION_INFO_V1(pgstatindex);
+PG_FUNCTION_INFO_V1(bt_metap);
+PG_FUNCTION_INFO_V1(bt_page_items);
+PG_FUNCTION_INFO_V1(bt_page_stats);
+PG_FUNCTION_INFO_V1(pg_relpages);
+
+extern Datum pgstatindex(PG_FUNCTION_ARGS);
+extern Datum bt_metap(PG_FUNCTION_ARGS);
+extern Datum bt_page_items(PG_FUNCTION_ARGS);
+extern Datum bt_page_stats(PG_FUNCTION_ARGS);
+extern Datum pg_relpages(PG_FUNCTION_ARGS);
+
+#define PGSTATINDEX_TYPE public.pgstatindex_type
+#define PGSTATINDEX_NCOLUMNS 10
+
+#define BTMETAP_TYPE public.bt_metap_type
+#define BTMETAP_NCOLUMNS 6
+
+#define BTPAGEITEMS_TYPE public.bt_page_items_type
+#define BTPAGEITEMS_NCOLUMNS 6
+
+#define BTPAGESTATS_TYPE public.bt_page_stats_type
+#define BTPAGESTATS_NCOLUMNS 11
+
+
+#define IS_INDEX(r) ((r)-rd_rel-relkind == 'i')
+#define IS_BTREE(r) ((r)-rd_rel-relam == BTREE_AM_OID)
+
+#define CHECK_PAGE_OFFSET_RANGE(page, offset) { \
+ if ( !(FirstOffsetNumber=(offset) \
+
(offset)=PageGetMaxOffsetNumber(page)) ) \
+elog(ERROR, Page offset number out of range.); }
+
+#define CHECK_RELATION_BLOCK_RANGE(rel, blkno) { \
+ if ( (blkno)0 RelationGetNumberOfBlocks((rel))=(blkno) ) \
+
Re: [PATCHES] [HACKERS] SO_SNDBUF size is small on win32?
Yoshiyuki Asaba wrote: Hi, From: Bruce Momjian [EMAIL PROTECTED] Subject: Re: [PATCHES] [HACKERS] SO_SNDBUF size is small on win32? Date: Fri, 11 Aug 2006 16:44:23 -0400 (EDT) Based on this patch and comments, I have applied a patch that sets the buffer to 32k, and adds the URL in a comment. Is it backported to 8.1.x and 8.0.x? No, it is too untested for backpatching, in my opinion. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Forcing current WAL file to be archived
This issue is closed, right? --- Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: Something Hannu wrote has just reminded me that pg_current_xlog_location() returns the current Insert pointer rather than the current Write pointer. That would not be useful for streaming xlog records would it? Good point. Methinks it should be the Write pointer all of the time, since I can't think of a valid reason for wanting to know where the Insert pointer is *before* we've written to the xlog file. Having it be the Insert pointer could lead to some errors. However the start/stop_backup functions return the Insert pointer. I can see scripts getting confused if pg_current_xlog_location reports something less than what they just got from pg_stop_backup. Is there value in exposing both pointers? (Maybe not, it'll just cause confusion probably.) Another option is to have pg_current_xlog_location force a write (but not fsync) as far as the Insert pointer it's about to return. This would eliminate any issues about inconsistency between results, but perhaps there's too much performance penalty. I'm not necessarily against your suggestion, just trying to be sure we've thought about all the options. regards, tom lane -- 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] Forcing current WAL file to be archived
Bruce Momjian [EMAIL PROTECTED] writes: This issue is closed, right? We've agreed we need two functions, but it's not done yet. Seems pretty trivial though ... 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: [HACKERS] [PATCHES] Forcing current WAL file to be archived
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: This issue is closed, right? We've agreed we need two functions, but it's not done yet. Seems pretty trivial though ... OK, that's what I was unclear about. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] pgstattuple extension for indexes
Satoshi Nagayasu wrote: Bruce, Attached patch has been cleaned up, and modified to be able to work with CVS HEAD. I was thinking, isn't it a lot cleaner to define the functions to use OUT parameters instead of having to define a custom type for each? Also, in 8.2 there is a uninstall SQL script -- ISTM you should put the DROP commands there, not in the install script. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(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
