Re: [PATCHES] temporal version of generate_series()

2008-05-01 Thread H . Harada 
2008/5/1 Pavel Stehule [EMAIL PROTECTED]:
 Hello

  why you don't use polymorphic types?
Ah, good idea. I didn't think we could fix the third argument to
interval but anyelement.
For a temporal version, it's reasonable.

Also, the name generate_time_series is better than before?

Hitoshi Harada


2008/5/1 Pavel Stehule [EMAIL PROTECTED]:
 Hello

  why you don't use polymorphic types?

  like:

  create or replace function generate_time_series(anyelement,
  anyelement, interval, OUT result anyelement)
  returns setof anyelement as $$
  begin
   result := $1;
   while (result = $2) loop
 return next;
 result := result + $3;
   end loop;
   return;
  end;
  $$ language plpgsql;

  Regards
  Pavel Stehule



  2008/5/1 H. Harada [EMAIL PROTECTED]:


  Here's the sync and updated patch.
   It contains strict in catalog as well.
  
   Hitoshi Harada
  
   2008/4/24 H. Harada [EMAIL PROTECTED]:
   2008/4/23 Alvaro Herrera [EMAIL PROTECTED]:
  
H.Harada escribió:


   # This is my first time to send a patch. If I did something wrong, I
   appreciate your pointing me out.

  Brace positioning is off w.r.t. our conventions -- please fix that and
  resubmit.
  
Here's updated version. Thanks for your advice.
  
Hitoshi Harada
  
2008/4/23 Alvaro Herrera [EMAIL PROTECTED]:
  
  
H.Harada escribió:


   # This is my first time to send a patch. If I did something wrong, I
   appreciate your pointing me out.

  Brace positioning is off w.r.t. our conventions -- please fix that and
  resubmit.

  I have added this patch to the May commitfest.

  --
  Alvaro Herrera
 http://www.CommandPrompt.com/
  The PostgreSQL Company - Command Prompt, Inc.

  
  
  
   --
   Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
   To make changes to your subscription:
   http://www.postgresql.org/mailpref/pgsql-patches
  
  


-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] plpgsql CASE statement - last version

2008-05-01 Thread Pavel Stehule 
Hello

2008/5/1 Jaime Casanova [EMAIL PROTECTED]:
 On Sat, Apr 5, 2008 at 6:57 AM, Pavel Stehule [EMAIL PROTECTED] wrote:
 Hello

 I found some bugs when I used base_lexer, so I returned back own
 lexer. It's only little bit longer, but simpler.


 you really compile this one? i get a complain because
 read_sql_construct is called with 8 arguments and it should have only
 7..

yes, I did it. 8 arguments are from EXECUTE USING patch
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/gram.y.diff?r1=1.108;r2=1.109;f=h

Pavel
.

 +   expr = read_sql_construct(',', K_THEN, 0, THEN,
 +   SELECT , true, true, tok);


 gram.y: In function 'plpgsql_yyparse':
 gram.y:1697: warning: passing argument 5 of 'read_sql_construct' makes
 integer from pointer without a cast
 gram.y:1697: warning: passing argument 7 of 'read_sql_construct' makes
 pointer from integer without a cast
 gram.y:1697: error: too many arguments to function 'read_sql_construct'

 --
 regards,
 Jaime Casanova
 Soporte de PostgreSQL
 Guayaquil - Ecuador
 Cel. (593) 087171157


-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] plpgsql CASE statement - last version

2008-05-01 Thread Jaime Casanova 
On Thu, May 1, 2008 at 7:59 AM, Pavel Stehule [EMAIL PROTECTED] wrote:
 Hello

 2008/5/1 Jaime Casanova [EMAIL PROTECTED]:
  On Sat, Apr 5, 2008 at 6:57 AM, Pavel Stehule [EMAIL PROTECTED] wrote:
  Hello
 
  I found some bugs when I used base_lexer, so I returned back own
  lexer. It's only little bit longer, but simpler.
 
 
  you really compile this one? i get a complain because
  read_sql_construct is called with 8 arguments and it should have only
  7..

 yes, I did it. 8 arguments are from EXECUTE USING patch
 http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/gram.y.diff?r1=1.108;r2=1.109;f=h


so, i need to see that patch first? patch that doesn't apply because
of changes in files (specially definitions moved to other files, but i
haven't checked all the .rej yet)

-- 
regards,
Jaime Casanova
Soporte de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] plpgsql CASE statement - last version

2008-05-01 Thread Jaime Casanova 
On Thu, May 1, 2008 at 8:11 AM, Jaime Casanova [EMAIL PROTECTED] wrote:
 On Thu, May 1, 2008 at 7:59 AM, Pavel Stehule [EMAIL PROTECTED] wrote:
  Hello
 
  2008/5/1 Jaime Casanova [EMAIL PROTECTED]:
   On Sat, Apr 5, 2008 at 6:57 AM, Pavel Stehule [EMAIL PROTECTED] wrote:
   Hello
  
   I found some bugs when I used base_lexer, so I returned back own
   lexer. It's only little bit longer, but simpler.
  
  
   you really compile this one? i get a complain because
   read_sql_construct is called with 8 arguments and it should have only
   7..
 
  yes, I did it. 8 arguments are from EXECUTE USING patch
  http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/gram.y.diff?r1=1.108;r2=1.109;f=h
 

 so, i need to see that patch first? patch that doesn't apply because
 of changes in files (specially definitions moved to other files, but i
 haven't checked all the .rej yet)


sorry, you mean already applied RETURN QUERY, right? i was thinking in
pending patch RETURN QUERY EXECUTE... i will check again my files but
i'm sure i have updated tu CVS TIP before try your patch

-- 
Atentamente,
Jaime Casanova
Soporte de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] plpgsql CASE statement - last version

2008-05-01 Thread Jaime Casanova 
On Thu, May 1, 2008 at 8:14 AM, Jaime Casanova [EMAIL PROTECTED] wrote:

 On Thu, May 1, 2008 at 8:11 AM, Jaime Casanova [EMAIL PROTECTED] wrote:
  On Thu, May 1, 2008 at 7:59 AM, Pavel Stehule [EMAIL PROTECTED] wrote:
   Hello
  
   2008/5/1 Jaime Casanova [EMAIL PROTECTED]:
On Sat, Apr 5, 2008 at 6:57 AM, Pavel Stehule [EMAIL PROTECTED] wrote:
Hello
   
I found some bugs when I used base_lexer, so I returned back own
lexer. It's only little bit longer, but simpler.
   
   
you really compile this one? i get a complain because
read_sql_construct is called with 8 arguments and it should have only
7..
  
   yes, I did it. 8 arguments are from EXECUTE USING patch
   http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/gram.y.diff?r1=1.108;r2=1.109;f=h
  
 
  so, i need to see that patch first? patch that doesn't apply because
  of changes in files (specially definitions moved to other files, but i
  haven't checked all the .rej yet)
 

 sorry, you mean already applied RETURN QUERY, right? i was thinking in
 pending patch RETURN QUERY EXECUTE... i will check again my files but
 i'm sure i have updated tu CVS TIP before try your patch


ok, you're right... sorry for the noise...
i will try it again

-- 
regards,
Jaime Casanova
Soporte de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] temporal version of generate_series()

2008-05-01 Thread H . Harada 
2008/5/1 H. Harada [EMAIL PROTECTED]:
 2008/5/1 Pavel Stehule [EMAIL PROTECTED]:

  Hello
  
why you don't use polymorphic types?
  Ah, good idea. I didn't think we could fix the third argument to
  interval but anyelement.
  For a temporal version, it's reasonable.

I was thinking about it again. There are 3 points:

a. It will get complicated in the function to resolve operator for
polymorphic types, including search for namespace and error (not
found) handling.
b. Other temporal data types than timestamp is easy to be casted from
timestamp results.
c. In the integer version of generate_series also it is possible to
cast the results to other numerical types though harder to cast them
to temporal data types.

So it would be better to keep current patch, isn't it?


postgres=# select generate_series('2008/05/01 20:00'::timestamp,
'2008/05/02 08:00'::timestamp
, '1 hour'::interval);
   generate_series
-
 2008-05-01 20:00:00
 2008-05-01 21:00:00
 2008-05-01 22:00:00
 2008-05-01 23:00:00
 2008-05-02 00:00:00
 2008-05-02 01:00:00
 2008-05-02 02:00:00
 2008-05-02 03:00:00
 2008-05-02 04:00:00
 2008-05-02 05:00:00
 2008-05-02 06:00:00
 2008-05-02 07:00:00
 2008-05-02 08:00:00
(13 rows)

postgres=# select generate_series('2008/05/01 20:00'::timestamp,
'2008/05/02 08:00'::timestamp
, '1 hour'::interval)::time;
 generate_series
-
 20:00:00
 21:00:00
 22:00:00
 23:00:00
 00:00:00
 01:00:00
 02:00:00
 03:00:00
 04:00:00
 05:00:00
 06:00:00
 07:00:00
 08:00:00
(13 rows)

postgres=# select generate_series('2008/05/01 20:00'::timestamp,
'2008/05/02 08:00'::timestamp
, '1 hour'::interval)::timestamptz;
generate_series

 2008-05-01 20:00:00+09
 2008-05-01 21:00:00+09
 2008-05-01 22:00:00+09
 2008-05-01 23:00:00+09
 2008-05-02 00:00:00+09
 2008-05-02 01:00:00+09
 2008-05-02 02:00:00+09
 2008-05-02 03:00:00+09
 2008-05-02 04:00:00+09
 2008-05-02 05:00:00+09
 2008-05-02 06:00:00+09
 2008-05-02 07:00:00+09
 2008-05-02 08:00:00+09
(13 rows)

postgres=# select generate_series('2008/05/01 20:00'::timestamp,
'2008/05/02 08:00'::timestamp
, '1 hour'::interval)::date;
 generate_series
-
 2008-05-01
 2008-05-01
 2008-05-01
 2008-05-01
 2008-05-02
 2008-05-02
 2008-05-02
 2008-05-02
 2008-05-02
 2008-05-02
 2008-05-02
 2008-05-02
 2008-05-02
(13 rows)


Hitoshi Harada

2008/5/1 H. Harada [EMAIL PROTECTED]:
 2008/5/1 Pavel Stehule [EMAIL PROTECTED]:

  Hello
  
why you don't use polymorphic types?
  Ah, good idea. I didn't think we could fix the third argument to
  interval but anyelement.
  For a temporal version, it's reasonable.

  Also, the name generate_time_series is better than before?

  Hitoshi Harada


  2008/5/1 Pavel Stehule [EMAIL PROTECTED]:


  Hello
  
why you don't use polymorphic types?
  
like:
  
create or replace function generate_time_series(anyelement,
anyelement, interval, OUT result anyelement)
returns setof anyelement as $$
begin
 result := $1;
 while (result = $2) loop
   return next;
   result := result + $3;
 end loop;
 return;
end;
$$ language plpgsql;
  
Regards
Pavel Stehule
  
  
  
2008/5/1 H. Harada [EMAIL PROTECTED]:
  
  
Here's the sync and updated patch.
 It contains strict in catalog as well.

 Hitoshi Harada

 2008/4/24 H. Harada [EMAIL PROTECTED]:
 2008/4/23 Alvaro Herrera [EMAIL PROTECTED]:

  H.Harada escribió:
  
  
 # This is my first time to send a patch. If I did something 
 wrong, I
 appreciate your pointing me out.
  
Brace positioning is off w.r.t. our conventions -- please fix that 
 and
resubmit.

  Here's updated version. Thanks for your advice.

  Hitoshi Harada

  2008/4/23 Alvaro Herrera [EMAIL PROTECTED]:


  H.Harada escribió:
  
  
 # This is my first time to send a patch. If I did something 
 wrong, I
 appreciate your pointing me out.
  
Brace positioning is off w.r.t. our conventions -- please fix that 
 and
resubmit.
  
I have added this patch to the May commitfest.
  
--
Alvaro Herrera
 http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
  



 --
 Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-patches


  


-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] plpgsql CASE statement - last version

2008-05-01 Thread Jaime Casanova 
On Sat, Apr 5, 2008 at 6:57 AM, Pavel Stehule [EMAIL PROTECTED] wrote:
 Hello

 I found some bugs when I used base_lexer, so I returned back own
 lexer. It's only little bit longer, but simpler.


you really compile this one? i get a complain because
read_sql_construct is called with 8 arguments and it should have only
7...

+   expr = read_sql_construct(',', K_THEN, 0, THEN,
+   SELECT , true, true, tok);


gram.y: In function 'plpgsql_yyparse':
gram.y:1697: warning: passing argument 5 of 'read_sql_construct' makes
integer from pointer without a cast
gram.y:1697: warning: passing argument 7 of 'read_sql_construct' makes
pointer from integer without a cast
gram.y:1697: error: too many arguments to function 'read_sql_construct'

-- 
regards,
Jaime Casanova
Soporte de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] temporal version of generate_series()

2008-05-01 Thread Pavel Stehule 
2008/5/1 H. Harada [EMAIL PROTECTED]:
 2008/5/1 H. Harada [EMAIL PROTECTED]:
 2008/5/1 Pavel Stehule [EMAIL PROTECTED]:

  Hello
  
why you don't use polymorphic types?
  Ah, good idea. I didn't think we could fix the third argument to
  interval but anyelement.
  For a temporal version, it's reasonable.

 I was thinking about it again. There are 3 points:

 a. It will get complicated in the function to resolve operator for
 polymorphic types, including search for namespace and error (not
 found) handling.

yes, it's true;

 b. Other temporal data types than timestamp is easy to be casted from
 timestamp results.
 c. In the integer version of generate_series also it is possible to
 cast the results to other numerical types though harder to cast them
 to temporal data types.

 So it would be better to keep current patch, isn't it?


I missing generator for date  - casting from and to timestemp is
little bit ugly - but polymorphic types in C isn't good idea, I see
it.

Regards
Pavel Stehule

 postgres=# select generate_series('2008/05/01 20:00'::timestamp,
 '2008/05/02 08:00'::timestamp
 , '1 hour'::interval);
   generate_series
 -
  2008-05-01 20:00:00
  2008-05-01 21:00:00
  2008-05-01 22:00:00
  2008-05-01 23:00:00
  2008-05-02 00:00:00
  2008-05-02 01:00:00
  2008-05-02 02:00:00
  2008-05-02 03:00:00
  2008-05-02 04:00:00
  2008-05-02 05:00:00
  2008-05-02 06:00:00
  2008-05-02 07:00:00
  2008-05-02 08:00:00
 (13 rows)

 postgres=# select generate_series('2008/05/01 20:00'::timestamp,
 '2008/05/02 08:00'::timestamp
 , '1 hour'::interval)::time;
  generate_series
 -
  20:00:00
  21:00:00
  22:00:00
  23:00:00
  00:00:00
  01:00:00
  02:00:00
  03:00:00
  04:00:00
  05:00:00
  06:00:00
  07:00:00
  08:00:00
 (13 rows)

 postgres=# select generate_series('2008/05/01 20:00'::timestamp,
 '2008/05/02 08:00'::timestamp
 , '1 hour'::interval)::timestamptz;
generate_series
 
  2008-05-01 20:00:00+09
  2008-05-01 21:00:00+09
  2008-05-01 22:00:00+09
  2008-05-01 23:00:00+09
  2008-05-02 00:00:00+09
  2008-05-02 01:00:00+09
  2008-05-02 02:00:00+09
  2008-05-02 03:00:00+09
  2008-05-02 04:00:00+09
  2008-05-02 05:00:00+09
  2008-05-02 06:00:00+09
  2008-05-02 07:00:00+09
  2008-05-02 08:00:00+09
 (13 rows)

 postgres=# select generate_series('2008/05/01 20:00'::timestamp,
 '2008/05/02 08:00'::timestamp
 , '1 hour'::interval)::date;
  generate_series
 -
  2008-05-01
  2008-05-01
  2008-05-01
  2008-05-01
  2008-05-02
  2008-05-02
  2008-05-02
  2008-05-02
  2008-05-02
  2008-05-02
  2008-05-02
  2008-05-02
  2008-05-02
 (13 rows)


 Hitoshi Harada

 2008/5/1 H. Harada [EMAIL PROTECTED]:
 2008/5/1 Pavel Stehule [EMAIL PROTECTED]:

  Hello
  
why you don't use polymorphic types?
  Ah, good idea. I didn't think we could fix the third argument to
  interval but anyelement.
  For a temporal version, it's reasonable.

  Also, the name generate_time_series is better than before?

  Hitoshi Harada


  2008/5/1 Pavel Stehule [EMAIL PROTECTED]:


  Hello
  
why you don't use polymorphic types?
  
like:
  
create or replace function generate_time_series(anyelement,
anyelement, interval, OUT result anyelement)
returns setof anyelement as $$
begin
 result := $1;
 while (result = $2) loop
   return next;
   result := result + $3;
 end loop;
 return;
end;
$$ language plpgsql;
  
Regards
Pavel Stehule
  
  
  
2008/5/1 H. Harada [EMAIL PROTECTED]:
  
  
Here's the sync and updated patch.
 It contains strict in catalog as well.

 Hitoshi Harada

 2008/4/24 H. Harada [EMAIL PROTECTED]:
 2008/4/23 Alvaro Herrera [EMAIL PROTECTED]:

  H.Harada escribió:
  
  
 # This is my first time to send a patch. If I did something 
 wrong, I
 appreciate your pointing me out.
  
Brace positioning is off w.r.t. our conventions -- please fix 
 that and
resubmit.

  Here's updated version. Thanks for your advice.

  Hitoshi Harada

  2008/4/23 Alvaro Herrera [EMAIL PROTECTED]:


  H.Harada escribió:
  
  
 # This is my first time to send a patch. If I did something 
 wrong, I
 appreciate your pointing me out.
  
Brace positioning is off w.r.t. our conventions -- please fix 
 that and
resubmit.
  
I have added this patch to the May commitfest.
  
--
Alvaro Herrera
 http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
  



 --
 Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-patches


  



-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:

Re: [PATCHES] Removing NONSEG mode

2008-05-01 Thread Tom Lane 
Zdenek Kotala [EMAIL PROTECTED] writes:
 I attach patch which remove nonsegment mode support. It was discussed during
 last commit fest. Nonsegment mode is possible uses only on couple of FS (ZFS,
 XFS) and it is not safe on any OS because each OS support more filesystems.

Applied with revisions --- mostly, you missed updating the
documentation, but also I didn't like the LL constant you used in
RELSEG_SIZE.  It's unportable and there might be unexpected side effects
from having the macro represent an int64 constant instead of an integer.
So I had configure do the arithmetic and emit an integer.

regards, tom lane

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Fix \dT enum in psql

2008-05-01 Thread Andrew Dunstan 



David Fetter wrote:

Folks,

In psql, \dT doesn't show the elements for enums.  Please find patch
vs. CVS TIP attached which fixes this per the following TODO item:

http://archives.postgresql.org/pgsql-hackers/2008-01/msg00826.php

  


I don't have a particular problem with this patch - indeed the query in 
it looks eerily familiar :-)


However, I'm wondering if we should wait until a possible rework of the 
mechanics of enums as recently discussed? Or we could put it in and that 
way it would have to be redone when enums are rejigged.


cheers

andrew



--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Fix \dT enum in psql

2008-05-01 Thread David Fetter 
On Thu, May 01, 2008 at 10:53:00PM -0400, Andrew Dunstan wrote:
 David Fetter wrote:
 Folks,

 In psql, \dT doesn't show the elements for enums.  Please find
 patch vs. CVS TIP attached which fixes this per the following TODO
 item:

 http://archives.postgresql.org/pgsql-hackers/2008-01/msg00826.php

 I don't have a particular problem with this patch - indeed the query
 in it looks eerily familiar :-)

I can't imagine why ;)

 However, I'm wondering if we should wait until a possible rework of
 the mechanics of enums as recently discussed? Or we could put it in
 and that way it would have to be redone when enums are rejigged.

I'm thinking getting it in there soon will keep the bitrot to a
minimum.  One thing it doesn't include is regression tests.  Shall I
add a few?

Cheers,
David.
-- 
David Fetter [EMAIL PROTECTED] http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: [EMAIL PROTECTED]

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

[PATCHES] configure option for XLOG_BLCKSZ

2008-05-01 Thread Mark Wong 
Hi all,

I saw a that a patch was committed that exposed a configure switch for
BLCKSZ.  I was hoping that I could do that same for XLOG_BLCKSZ.  I
think I got the configure.in, sgml, pg_config_manual.h, and
pg_config.h.in changes correct.

Regards,
Mark
Index: configure
===
RCS file: /projects/cvsroot/pgsql/configure,v
retrieving revision 1.592
diff -c -r1.592 configure
*** configure	2 May 2008 01:08:22 -	1.592
--- configure	2 May 2008 04:39:34 -
***
*** 1374,1379 
--- 1374,1380 
--with-libs=DIRSalternative spelling of --with-libraries
--with-pgport=PORTNUM   set default port number [5432]
--with-blocksize=BLOCKSIZE  set block size in kB [8]
+   --with-xlog-blocksize=BLOCKSIZE  set xlog block size in kB [8]
--with-segsize=SEGSIZE  set segment size in GB [1]
--with-tcl  build Tcl modules (PL/Tcl)
--with-tclconfig=DIRtclConfig.sh is in DIR
***
*** 2602,2607 
--- 2603,2658 
  _ACEOF
  
  
+ { echo $as_me:$LINENO: checking for xlog block size 5
+ echo $ECHO_N checking for xlog block size... $ECHO_C 6; }
+ 
+ pgac_args=$pgac_args with_xlog_blocksize
+ 
+ 
+ # Check whether --with-xlog-blocksize was given.
+ if test ${with_xlog_blocksize+set} = set; then
+   withval=$with_xlog_blocksize;
+   case $withval in
+ yes)
+   { { echo $as_me:$LINENO: error: argument required for --with-xlog-blocksize option 5
+ echo $as_me: error: argument required for --with-xlog-blocksize option 2;}
+{ (exit 1); exit 1; }; }
+   ;;
+ no)
+   { { echo $as_me:$LINENO: error: argument required for --with-xlog-blocksize option 5
+ echo $as_me: error: argument required for --with-xlog-blocksize option 2;}
+{ (exit 1); exit 1; }; }
+   ;;
+ *)
+   xlog_blocksize=$withval
+   ;;
+   esac
+ 
+ else
+   xlog_blocksize=8
+ fi
+ 
+ 
+ case ${xlog_blocksize} in
+   1) XLOG_BLCKSZ=1024;;
+   2) XLOG_BLCKSZ=2048;;
+   4) XLOG_BLCKSZ=4096;;
+   8) XLOG_BLCKSZ=8192;;
+  16) XLOG_BLCKSZ=16384;;
+  32) XLOG_BLCKSZ=32768;;
+   *) { { echo $as_me:$LINENO: error: Invalid block size. Allowed values are 1,2,4,8,16,32. 5
+ echo $as_me: error: Invalid block size. Allowed values are 1,2,4,8,16,32. 2;}
+{ (exit 1); exit 1; }; }
+ esac
+ { echo $as_me:$LINENO: result: ${xlog_blocksize}kB 5
+ echo ${ECHO_T}${xlog_blocksize}kB 6; }
+ 
+ 
+ cat confdefs.h _ACEOF
+ #define XLOG_BLCKSZ ${XLOG_BLCKSZ}
+ _ACEOF
+ 
+ 
  #
  # File segment size
  #
Index: configure.in
===
RCS file: /projects/cvsroot/pgsql/configure.in,v
retrieving revision 1.558
diff -c -r1.558 configure.in
*** configure.in	2 May 2008 01:08:26 -	1.558
--- configure.in	2 May 2008 04:39:34 -
***
*** 249,254 
--- 249,278 
   Changing BLCKSZ requires an initdb.
  ]) 
  
+ AC_MSG_CHECKING([for xlog block size])
+ PGAC_ARG_REQ(with, xlog-blocksize, [  --with-xlog-blocksize=BLOCKSIZE  set xlog block size in kB [[8]]],
+  [xlog_blocksize=$withval],
+  [xlog_blocksize=8])
+ case ${xlog_blocksize} in
+   1) XLOG_BLCKSZ=1024;;
+   2) XLOG_BLCKSZ=2048;;
+   4) XLOG_BLCKSZ=4096;;
+   8) XLOG_BLCKSZ=8192;;
+  16) XLOG_BLCKSZ=16384;;
+  32) XLOG_BLCKSZ=32768;;
+   *) AC_MSG_ERROR([Invalid block size. Allowed values are 1,2,4,8,16,32.])
+ esac
+ AC_MSG_RESULT([${xlog_blocksize}kB])
+ 
+ AC_DEFINE_UNQUOTED([XLOG_BLCKSZ], ${XLOG_BLCKSZ}, [
+  Size of a WAL file block.  This need have no particular relation to BLCKSZ.
+  XLOG_BLCKSZ must be a power of 2, and if your system supports O_DIRECT I/O,
+  XLOG_BLCKSZ must be a multiple of the alignment requirement for direct-I/O
+  buffers, else direct I/O may fail.
+ 
+  Changing XLOG_BLCKSZ requires an initdb.
+ ]) 
+ 
  #
  # File segment size
  #
Index: doc/src/sgml/installation.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/installation.sgml,v
retrieving revision 1.308
diff -c -r1.308 installation.sgml
*** doc/src/sgml/installation.sgml	2 May 2008 01:08:26 -	1.308
--- doc/src/sgml/installation.sgml	2 May 2008 04:39:36 -
***
*** 1104,1109 
--- 1104,1123 
/varlistentry
  
varlistentry
+termoption--with-xlog-blocksize=replaceableBLOCKSIZE/replaceable/option/term
+listitem
+ para
+  Set the firsttermxlog block size/, in kilobytes.  This is the unit
+  of storage and I/O within the WAL files.  The default, 8 kilobytes,
+  is suitable for most situations; but other values may be useful
+  in special cases.
+  The value must be a power of 2 between 1 and 32 (kilobytes).
+  Note that changing this value requires an initdb.
+ /para
+/listitem
+   /varlistentry
+ 
+   varlistentry
 termoption--disable-spinlocks/option/term
 listitem

Re: [PATCHES] configure option for XLOG_BLCKSZ

2008-05-01 Thread Tom Lane 
Mark Wong [EMAIL PROTECTED] writes:
 I saw a that a patch was committed that exposed a configure switch for
 BLCKSZ.  I was hoping that I could do that same for XLOG_BLCKSZ.

Well, we certainly *could*, but what's the use-case really?  The case
for varying BLCKSZ is marginal already, and I've seen none at all for
varying XLOG_BLCKSZ.  Why do we need to make it easier than edit
pg_config_manual.h?

regards, tom lane

-- 
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches