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


[PATCHES] Removing NONSEG mode

2008-04-22 Thread Zdenek Kotala

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.

I added RELSEG option to the configure script to allow easily compile with
different segment size (on most filesystem 1T is safe value). As a bonus I added
also BLCKSZ to configure script. It is not important for this patch but it could 
be useful e.g. for buildfarm testing with different BLCKSZ.


Patch requires to run autoconf and autoheader.

Zdenek

PS: --with-segsize=1/1024 allows set segsize to 1MB - good for testing


Index: configure.in
===
RCS file: /zfs_data/cvs_pgsql/cvsroot/pgsql/configure.in,v
retrieving revision 1.555
diff -c -r1.555 configure.in
*** configure.in	30 Mar 2008 04:08:14 -	1.555
--- configure.in	21 Apr 2008 15:19:59 -
***
*** 220,233 
  #
  # Data file segmentation
  #
! PGAC_ARG_BOOL(enable, segmented-files, yes,
!   [  --disable-segmented-files disable data file segmentation (requires largefile support)])
  
  #
  # C compiler
  #
  
  # For historical reasons you can also use --with-CC to specify the C compiler
  # to use, although the standard way to do this is to set the CC environment
  # variable.
  PGAC_ARG_REQ(with, CC, [], [CC=$with_CC])
--- 220,287 
  #
  # Data file segmentation
  #
! AC_MSG_CHECKING([for default relation segment size])
! PGAC_ARG_REQ(with, segsize, [  --with-segsize=RELSEG_SIZE  change default relation segment size in GB [[1]]],
!  [default_segsize=$withval],
!  [default_segsize=1])
! AC_MSG_RESULT([${default_segsize}GB])
! AC_DEFINE_UNQUOTED([RELSEG_SIZE], 1024*1024*1024LL*${default_segsize}/BLCKSZ, [
!  RELSEG_SIZE is the maximum number of blocks allowed in one disk
!  file. Thus, the maximum size of a single file is RELSEG_SIZE * BLCKSZ;
!  relations bigger than that are divided into multiple files.
!  
!  RELSEG_SIZE * BLCKSZ must be less than your OS' limit on file size.
!  This is often 2 GB or 4GB in a 32-bit operating system, unless you
!  have large file support enabled.  By default, we make the limit 1
!  GB to avoid any possible integer-overflow problems within the OS.
!  A limit smaller than necessary only means we divide a large
!  relation into more chunks than necessary, so it seems best to err
!  in the direction of a small limit.  (Besides, a power-of-2 value
!  saves a few cycles in md.c.)
  
+  Changing RELSEG_SIZE requires an initdb.
+ ])
+ AC_SUBST(default_segsize)
+ 
+ #
+ # Block size
  #
+ AC_MSG_CHECKING([for default block size])
+ PGAC_ARG_REQ(with, blocksize, [  --with-blocksize=BLCKSZ change default block size (1,2,4,8,16,32 are allowed values). [[8]]],
+  [default_blocksize=$withval],
+  [default_blocksize=8])
+ case ${default_blocksize} in
+   1) default_blocksize=1024;;
+   2) default_blocksize=2048;;
+   4) default_blocksize=4096;;
+   8) default_blocksize=8192;;
+  16) default_blocksize=16384;;
+  32) default_blocksize=32768;;
+   *) AC_MSG_ERROR([Invalid block size. Allowed values are 1,2,4,8,16,32.])
+ esac
+ 
+ AC_MSG_RESULT([${default_blocksize}B])
+ AC_DEFINE_UNQUOTED([BLCKSZ], ${default_blocksize}, [
+  Size of a disk block --- this also limits the size of a tuple.  You
+  can set it bigger if you need bigger tuples (although TOAST should
+  reduce the need to have large tuples, since fields can be spread
+  across multiple tuples).
+  
+  BLCKSZ must be a power of 2.  The maximum possible value of BLCKSZ
+  is currently 2^15 (32768).  This is determined by the 15-bit widths
+  of the lp_off and lp_len fields in ItemIdData (see
+  include/storage/itemid.h).
+  
+  Changing BLCKSZ requires an initdb.
+ ]) 
+ AC_SUBST(default_blocksize)
+ 
+ 
  # C compiler
  #
  
  # For historical reasons you can also use --with-CC to specify the C compiler
+ 
  # to use, although the standard way to do this is to set the CC environment
  # variable.
  PGAC_ARG_REQ(with, CC, [], [CC=$with_CC])
***
*** 1435,1443 
  
  # Check for largefile support (must be after AC_SYS_LARGEFILE)
  AC_CHECK_SIZEOF([off_t])
! 
! if test $ac_cv_sizeof_off_t -lt 8 -o $enable_segmented_files = yes; then 
!   AC_DEFINE([USE_SEGMENTED_FILES], 1, [Define to split data files into 1GB segments.]) 
  fi
  
  # SunOS doesn't handle negative byte comparisons properly with +/- return
--- 1489,1496 
  
  # Check for largefile support (must be after AC_SYS_LARGEFILE)
  AC_CHECK_SIZEOF([off_t])
! if test $ac_cv_sizeof_off_t -lt 8 -a $default_segsize != 1; then 
!AC_MSG_ERROR([Large file support is not enabled. Segment size cannot be larger then 1GB.]) 
  fi
  
  # SunOS doesn't handle negative byte comparisons properly with +/- return
Index: src/backend/storage/file/buffile.c
===

Re: [PATCHES] Removing NONSEG mode

2008-04-22 Thread Alvaro Herrera
Zdenek Kotala wrote:
 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.

Added to May commitfest, thanks.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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