Обсуждение: BUG #10013: PostgreSQL 9.4 initdb FATAL: could not write to file "pg_xlog/xlogtemp.3590": No space left on devi
The following bug has been logged on the website: Bug reference: 10013 Logged by: digoal.zhou Email address: digoal@126.com PostgreSQL version: Unsupported/Unknown Operating system: CentOS 6.4 x64 Description: I use recent postgresql snapshot from http://git.postgresql.org/gitweb/?p=postgresql.git;a=snapshot;h=e0c91a7ff015fab0ccbb0f75b6819f29ae00295e;sf=tgz but when initdb, error reported. pg94@db-172-16-3-150-> df -h Filesystem Size Used Avail Use% Mounted on /dev/sdc1 29G 9.0G 19G 33% / tmpfs 48G 0 48G 0% /dev/shm /dev/sdc3 98G 29G 64G 31% /opt /dev/sdd1 183G 32G 143G 19% /ssd1 /dev/sda1 221G 7.5G 202G 4% /ssd3 /dev/sdb1 221G 36G 174G 18% /ssd4 pg94@db-172-16-3-150-> df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdc1 1921360 199173 1722187 11% / tmpfs 12381887 1 12381886 1% /dev/shm /dev/sdc3 6479872 442050 6037822 7% /opt /dev/sdd1 12173312 1479 12171833 1% /ssd1 /dev/sda1 14655488 2313 14653175 1% /ssd3 /dev/sdb1 14655488 2095 14653393 1% /ssd4 pg94@db-172-16-3-150-> initdb -D /home/pg94/pg_root --debug Running in debug mode. The files belonging to this database system will be owned by user "pg94". This user must also own the server process. VERSION=9.4devel PGDATA=/home/pg94/pg_root share_path=/home/pg94/pgsql9.4devel/share PGPATH=/home/pg94/pgsql9.4devel/bin POSTGRES_SUPERUSERNAME=pg94 POSTGRES_BKI=/home/pg94/pgsql9.4devel/share/postgres.bki POSTGRES_DESCR=/home/pg94/pgsql9.4devel/share/postgres.description POSTGRES_SHDESCR=/home/pg94/pgsql9.4devel/share/postgres.shdescription POSTGRESQL_CONF_SAMPLE=/home/pg94/pgsql9.4devel/share/postgresql.conf.sample PG_HBA_SAMPLE=/home/pg94/pgsql9.4devel/share/pg_hba.conf.sample PG_IDENT_SAMPLE=/home/pg94/pgsql9.4devel/share/pg_ident.conf.sample The database cluster will be initialized with locale "en_US.utf8". The default database encoding has accordingly been set to "UTF8". The default text search configuration will be set to "english". Data page checksums are disabled. creating directory /home/pg94/pg_root ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 128MB selecting dynamic shared memory implementation ... posix creating configuration files ... ok creating template1 database in /home/pg94/pg_root/base/1 ... DEBUG: invoking IpcMemoryCreate(size=152027136) DEBUG: SlruScanDirectory invoking callback on pg_notify/0000 DEBUG: removing file "pg_notify/0000" DEBUG: dynamic shared memory system will support 288 segments DEBUG: created dynamic shared memory control segment 1804289383 (2316 bytes) DEBUG: transaction ID wrap limit is 2147483650, limited by database with OID 1 DEBUG: MultiXactId wrap limit is 2147483648, limited by database with OID 1 DEBUG: creating and filling new WAL file FATAL: could not write to file "pg_xlog/xlogtemp.3590": No space left on device DEBUG: shmem_exit(1): 0 before_shmem_exit callbacks to make DEBUG: shmem_exit(1): 4 on_shmem_exit callbacks to make DEBUG: cleaning up dynamic shared memory control segment with ID 1804289383 DEBUG: proc_exit(1): 3 callbacks to make DEBUG: exit(1) DEBUG: shmem_exit(-1): 0 before_shmem_exit callbacks to make DEBUG: shmem_exit(-1): 0 on_shmem_exit callbacks to make DEBUG: proc_exit(-1): 0 callbacks to make child process exited with exit code 1 initdb: removing data directory "/home/pg94/pg_root"
On 04/14/2014 04:44 AM, digoal@126.com wrote: > The following bug has been logged on the website: > > Bug reference: 10013 > Logged by: digoal.zhou > Email address: digoal@126.com > PostgreSQL version: Unsupported/Unknown > Operating system: CentOS 6.4 x64 > Description: > > I use recent postgresql snapshot from > http://git.postgresql.org/gitweb/?p=postgresql.git;a=snapshot;h=e0c91a7ff015fab0ccbb0f75b6819f29ae00295e;sf=tgz > but when initdb, error reported. > > [df output that shows plenty of disk space] > > pg94@db-172-16-3-150-> initdb -D /home/pg94/pg_root --debug > ... > DEBUG: creating and filling new WAL file > FATAL: could not write to file "pg_xlog/xlogtemp.3590": No space left on > device Can you reproduce this, or was it a one-off failure? The function reports "No space left on device" if the write() syscall reports ENOSPC, but also on a short write, i.e. if write() reports success but didn't write the whole buffer but only part of it. On a local disk, a short write usually indicates running out of disk space, but I'm not sure if there might be some other conditions when that happens, especially with more exotic filesystems. Was there anything special about the filesystem you're using? If you can reproduce this, we could add some more debugging to see if it was a short write or a ENOSPC. - Heikki
On 04/16/2014 11:20 AM, digoal@126.com wrote: > HI, > I can reproduce this. Ok. Can you try with the attached patch applied, please? - Heikki
Вложения
On 2014-04-16 13:50:35 +0300, Heikki Linnakangas wrote: > On 04/16/2014 11:20 AM, digoal@126.com wrote: > >HI, > > I can reproduce this. > > Ok. Can you try with the attached patch applied, please? Perhaps this should also support partial writes, akin to 79ce29c734c6a652b2f7193bda537cff0c8eb8c1? I don't find it all that unreasonble for the OS to refuse 16MB - or even bigger - writes in some scenarios. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 04/16/2014 01:59 PM, Andres Freund wrote: > On 2014-04-16 13:50:35 +0300, Heikki Linnakangas wrote: >> On 04/16/2014 11:20 AM, digoal@126.com wrote: >>> HI, >>> I can reproduce this. >> >> Ok. Can you try with the attached patch applied, please? > > Perhaps this should also support partial writes, akin to > 79ce29c734c6a652b2f7193bda537cff0c8eb8c1? I don't find it all that > unreasonble for the OS to refuse 16MB - or even bigger - writes in some > scenarios. The write in XLogFileInit is always 8kB (XLOG_BLCKSZ). But yeah, it might make sense to retry. Although I wonder why XLogFileInit would be particularly vulnerable to short writes. I'm afraid if we fix that, next we'll start seeing failures from other writes, to data files. But wait for Digoal to run with the extra let's see if this was in fact a short write. Could also be a quota or similar. - Heikki
On 2014-04-16 14:11:22 +0300, Heikki Linnakangas wrote: > On 04/16/2014 01:59 PM, Andres Freund wrote: > >On 2014-04-16 13:50:35 +0300, Heikki Linnakangas wrote: > >>On 04/16/2014 11:20 AM, digoal@126.com wrote: > >>>HI, > >>> I can reproduce this. > >> > >>Ok. Can you try with the attached patch applied, please? > > > >Perhaps this should also support partial writes, akin to > >79ce29c734c6a652b2f7193bda537cff0c8eb8c1? I don't find it all that > >unreasonble for the OS to refuse 16MB - or even bigger - writes in some > >scenarios. > > The write in XLogFileInit is always 8kB (XLOG_BLCKSZ). Oh, then disregard that. I just remembered you fixing it for normal wal writes... A strace (or the platform's equivalent) might be interesting. Digoal? > But yeah, it might > make sense to retry. Although I wonder why XLogFileInit would be > particularly vulnerable to short writes. I'm afraid if we fix that, next > we'll start seeing failures from other writes, to data files. I personally think we indeed should fix that generally, but that's not a small change. We'd probably need some wrappers to make that happen sensibly. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 2014-04-16 19:19:18 +0800, =E5=BE=B7=E5=93=A5 wrote: > pg94@db-172-16-3-150-> strace -c initdb > The files belonging to this database system will be owned by user "pg94= ". > This user must also own the server process. strace -c isn't particularly helpful here, we'd need normal strace, not the summary. > creating template1 database in /home/pg94/pg_root/base/1 ... LOG: writ= e() in XLogFileInit returned 40960: Success > FATAL: could not write to file "pg_xlog/xlogtemp.832": No space left > on device You compiled postgres with nonstandard options? Specifically you seem to have used a nonstandard wal blocksize? Greetings, Andres Freund --=20 Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 04/16/2014 02:17 PM, µÂ¸ç wrote: > LOG: write() in XLogFileInit returned 40960: Success Oh, that's interesting. Have you tweaked BLCKSZ or XLOG_BLCKSZ? If you have, try with a fresh checkout - I just fixed a bug in that code where I had used BLCKSZ instead of XLOG_BLCKSZ in the allocation of the buffer. They're the same by default, but if you've changed them, that might be it. - Heikki
On 2014-04-16 19:31:33 +0800, =E5=BE=B7=E5=93=A5 wrote: > CONFIGURE =3D '... '--with-wal-blocksize=3D64' '--with-blocksize=3D32' = ...' Independent of problems around this that probably should be fixed, I think it's a pretty bad idea to use such a large wal blocksize. That'll cause a fair amount of write amplification at commits and such. It might work out well if you only doing bulk loading, but still.. Greetings, Andres Freund --=20 Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
HI,
[root@db-172-16-3-150 postgresql-46a60ab]# patch -p1 < ./morelogging-in-xlogfileinit.patch
(Stripping trailing CRs from patch.)
patching file src/backend/access/transam/xlog.c
Hunk #1 succeeded at 3142 with fuzz 1.
[root@db-172-16-3-150 postgresql-46a60ab]# gmake
[root@db-172-16-3-150 postgresql-46a60ab]# gmake install
[root@db-172-16-3-150 postgresql-46a60ab]# ll /home/pg94/pgsql9.4devel/bin/initdb
-rwxr-xr-x 1 root root 266843 Apr 16 19:12 /home/pg94/pgsql9.4devel/bin/initdb
su - pg94
pg94@db-172-16-3-150-> initdb --debug
Running in debug mode.
The files belonging to this database system will be owned by user "pg94".
This user must also own the server process.
VERSION=9.4devel
PGDATA=/home/pg94/pg_root
share_path=/home/pg94/pgsql9.4devel/share
PGPATH=/home/pg94/pgsql9.4devel/bin
POSTGRES_SUPERUSERNAME=pg94
POSTGRES_BKI=/home/pg94/pgsql9.4devel/share/postgres.bki
POSTGRES_DESCR=/home/pg94/pgsql9.4devel/share/postgres.description
POSTGRES_SHDESCR=/home/pg94/pgsql9.4devel/share/postgres.shdescription
POSTGRESQL_CONF_SAMPLE=/home/pg94/pgsql9.4devel/share/postgresql.conf.sample
PG_HBA_SAMPLE=/home/pg94/pgsql9.4devel/share/pg_hba.conf.sample
PG_IDENT_SAMPLE=/home/pg94/pgsql9.4devel/share/pg_ident.conf.sample
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
creating directory /home/pg94/pg_root ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
creating template1 database in /home/pg94/pg_root/base/1 ... DEBUG: invoking IpcMemoryCreate(size=152027136)
DEBUG: SlruScanDirectory invoking callback on pg_notify/0000
DEBUG: removing file "pg_notify/0000"
DEBUG: dynamic shared memory system will support 288 segments
DEBUG: created dynamic shared memory control segment 1804289383 (2316 bytes)
DEBUG: transaction ID wrap limit is 2147483650, limited by database with OID 1
DEBUG: MultiXactId wrap limit is 2147483648, limited by database with OID 1
DEBUG: creating and filling new WAL file
LOG: write() in XLogFileInit returned 40960: Success
FATAL: could not write to file "pg_xlog/xlogtemp.685": No space left on device
DEBUG: shmem_exit(1): 0 before_shmem_exit callbacks to make
DEBUG: shmem_exit(1): 4 on_shmem_exit callbacks to make
DEBUG: cleaning up dynamic shared memory control segment with ID 1804289383
DEBUG: proc_exit(1): 3 callbacks to make
DEBUG: exit(1)
DEBUG: shmem_exit(-1): 0 before_shmem_exit callbacks to make
DEBUG: shmem_exit(-1): 0 on_shmem_exit callbacks to make
DEBUG: proc_exit(-1): 0 callbacks to make
child process exited with exit code 1
initdb: removing data directory "/home/pg94/pg_root"
--
公益是一辈子的事,I'm Digoal,Just Do It.
公益是一辈子的事,I'm Digoal,Just Do It.
At 2014-04-16 19:11:22,"Heikki Linnakangas" <hlinnakangas@vmware.com> wrote: >On 04/16/2014 01:59 PM, Andres Freund wrote: >> On 2014-04-16 13:50:35 +0300, Heikki Linnakangas wrote: >>> On 04/16/2014 11:20 AM, digoal@126.com wrote: >>>> HI, >>>> I can reproduce this. >>> >>> Ok. Can you try with the attached patch applied, please? >> >> Perhaps this should also support partial writes, akin to >> 79ce29c734c6a652b2f7193bda537cff0c8eb8c1? I don't find it all that >> unreasonble for the OS to refuse 16MB - or even bigger - writes in some >> scenarios. > >The write in XLogFileInit is always 8kB (XLOG_BLCKSZ). But yeah, it >might make sense to retry. Although I wonder why XLogFileInit would be >particularly vulnerable to short writes. I'm afraid if we fix that, next >we'll start seeing failures from other writes, to data files. > >But wait for Digoal to run with the extra let's see if this was in fact >a short write. Could also be a quota or similar. > >- Heikki
after patched.
pg94@db-172-16-3-150-> strace -c initdb
The files belonging to this database system will be owned by user "pg94".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
creating directory /home/pg94/pg_root ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
creating template1 database in /home/pg94/pg_root/base/1 ... LOG: write() in XLogFileInit returned 40960: Success
FATAL: could not write to file "pg_xlog/xlogtemp.832": No space left on device
child process exited with exit code 1
initdb: removing data directory "/home/pg94/pg_root"
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
90.23 0.016045 4011 4 wait4
6.48 0.001153 0 23171 33 stat
2.02 0.000360 0 5866 5339 write
0.62 0.000110 0 1229 21 open
0.21 0.000038 0 1459 read
0.17 0.000030 0 1215 close
0.17 0.000030 1 23 mkdir
0.09 0.000016 0 88 getdents
0.00 0.000000 0 21 fstat
0.00 0.000000 0 30 lstat
0.00 0.000000 0 5 lseek
0.00 0.000000 0 31 mmap
0.00 0.000000 0 9 mprotect
0.00 0.000000 0 14 munmap
0.00 0.000000 0 11 brk
0.00 0.000000 0 16 rt_sigaction
0.00 0.000000 0 5 rt_sigprocmask
0.00 0.000000 0 7 1 access
0.00 0.000000 0 3 socket
0.00 0.000000 0 2 2 connect
0.00 0.000000 0 1 sendto
0.00 0.000000 0 3 recvmsg
0.00 0.000000 0 1 bind
0.00 0.000000 0 1 getsockname
0.00 0.000000 0 4 clone
0.00 0.000000 0 1 execve
0.00 0.000000 0 5 fcntl
0.00 0.000000 0 6 getcwd
0.00 0.000000 0 4 chdir
0.00 0.000000 0 23 rmdir
0.00 0.000000 0 7 unlink
0.00 0.000000 0 4 chmod
0.00 0.000000 0 89 umask
0.00 0.000000 0 1 getrlimit
0.00 0.000000 0 2 geteuid
0.00 0.000000 0 1 statfs
0.00 0.000000 0 1 arch_prctl
0.00 0.000000 0 3 1 futex
0.00 0.000000 0 1 set_tid_address
0.00 0.000000 0 1 set_robust_list
0.00 0.000000 0 2 pipe2
------ ----------- ----------- --------- --------- ----------------
100.00 0.017782 33370 5397 total
--
公益是一辈子的事,I'm Digoal,Just Do It.
公益是一辈子的事,I'm Digoal,Just Do It.
At 2014-04-16 19:16:45,"Andres Freund" <andres@2ndquadrant.com> wrote: >On 2014-04-16 14:11:22 +0300, Heikki Linnakangas wrote: >> On 04/16/2014 01:59 PM, Andres Freund wrote: >> >On 2014-04-16 13:50:35 +0300, Heikki Linnakangas wrote: >> >>On 04/16/2014 11:20 AM, digoal@126.com wrote: >> >>>HI, >> >>> I can reproduce this. >> >> >> >>Ok. Can you try with the attached patch applied, please? >> > >> >Perhaps this should also support partial writes, akin to >> >79ce29c734c6a652b2f7193bda537cff0c8eb8c1? I don't find it all that >> >unreasonble for the OS to refuse 16MB - or even bigger - writes in some >> >scenarios. >> >> The write in XLogFileInit is always 8kB (XLOG_BLCKSZ). > >Oh, then disregard that. I just remembered you fixing it for normal wal >writes... > >A strace (or the platform's equivalent) might be interesting. Digoal? > >> But yeah, it might >> make sense to retry. Although I wonder why XLogFileInit would be >> particularly vulnerable to short writes. I'm afraid if we fix that, next >> we'll start seeing failures from other writes, to data files. > >I personally think we indeed should fix that generally, but that's not a >small change. We'd probably need some wrappers to make that happen >sensibly. > >Greetings, > >Andres Freund > >-- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services
this is my config.
pg94@db-172-16-3-150-> pg_config
BINDIR = /home/pg94/pgsql9.4devel/bin
DOCDIR = /home/pg94/pgsql9.4devel/share/doc
HTMLDIR = /home/pg94/pgsql9.4devel/share/doc
INCLUDEDIR = /home/pg94/pgsql9.4devel/include
PKGINCLUDEDIR = /home/pg94/pgsql9.4devel/include
INCLUDEDIR-SERVER = /home/pg94/pgsql9.4devel/include/server
LIBDIR = /home/pg94/pgsql9.4devel/lib
PKGLIBDIR = /home/pg94/pgsql9.4devel/lib
LOCALEDIR = /home/pg94/pgsql9.4devel/share/locale
MANDIR = /home/pg94/pgsql9.4devel/share/man
SHAREDIR = /home/pg94/pgsql9.4devel/share
SYSCONFDIR = /home/pg94/pgsql9.4devel/etc
PGXS = /home/pg94/pgsql9.4devel/lib/pgxs/src/makefiles/pgxs.mk
CONFIGURE = '--prefix=/home/pg94/pgsql9.4devel' '--with-pgport=1933' '--with-perl' '--with-tcl' '--with-python' '--with-openssl' '--with-pam' '--without-ldap' '--with-libxml' '--with-libxslt' '--enable-thread-safety' '--with-wal-blocksize=64' '--with-blocksize=32' '--enable-dtrace' '--enable-debug'
CC = gcc
CPPFLAGS = -D_GNU_SOURCE -I/usr/include/libxml2
CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g
CFLAGS_SL = -fpic
LDFLAGS = -L../../../src/common -Wl,--as-needed -Wl,-rpath,'/home/pg94/pgsql9.4devel/lib',--enable-new-dtags
LDFLAGS_EX =
LDFLAGS_SL =
LIBS = -lpgcommon -lpgport -lxslt -lxml2 -lpam -lssl -lcrypto -lz -lreadline -lrt -lcrypt -ldl -lm
VERSION = PostgreSQL 9.4devel
--
公益是一辈子的事,I'm Digoal,Just Do It.
公益是一辈子的事,I'm Digoal,Just Do It.
在 2014-04-16 19:27:32，"Andres Freund" <andres@2ndquadrant.com> 写道： >On 2014-04-16 19:19:18 +0800, 德哥 wrote: >> pg94@db-172-16-3-150-> strace -c initdb >> The files belonging to this database system will be owned by user "pg94". >> This user must also own the server process. > >strace -c isn't particularly helpful here, we'd need normal strace, not >the summary. > >> creating template1 database in /home/pg94/pg_root/base/1 ... LOG: write() in XLogFileInit returned 40960: Success >> FATAL: could not write to file "pg_xlog/xlogtemp.832": No space left >> on device > >You compiled postgres with nonstandard options? Specifically you seem to >have used a nonstandard wal blocksize? > >Greetings, > >Andres Freund > >-- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services
HI,
thanks
I use async commit in this test environment. --
公益是一辈子的事,I'm Digoal,Just Do It.
公益是一辈子的事,I'm Digoal,Just Do It.
在 2014-04-16 19:34:38，"Andres Freund" <andres@2ndquadrant.com> 写道： >On 2014-04-16 19:31:33 +0800, 德哥 wrote: >> CONFIGURE = '... '--with-wal-blocksize=64' '--with-blocksize=32' ...' > >Independent of problems around this that probably should be fixed, I >think it's a pretty bad idea to use such a large wal blocksize. That'll >cause a fair amount of write amplification at commits and such. >It might work out well if you only doing bulk loading, but still.. > >Greetings, > >Andres Freund > >-- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services
HI,
Use this snapshot the problem fixed, thanks Heikki and Andres's help.
| author | Heikki Linnakangas <heikki.linnakangas@iki.fi> | |
| Wed, 16 Apr 2014 07:21:09 +0000 (10:21 +0300) | ||
| committer | Heikki Linnakangas <heikki.linnakangas@iki.fi> | |
| Wed, 16 Apr 2014 07:26:36 +0000 (10:26 +0300) | ||
| commit | 848b9f05ab283724dd063d936a92568c1fdf422b | |
| tree | e6f0804cb145b3c09841bc91a9dd6e07e5778551 | tree | snapshot |
| parent | ab76d8e9d672c661fe8ce4d9405dc8956b8ece9d | commit | diff |
Use correctly-sized buffer when zero-filling a WAL file.
I mixed up BLCKSZ and XLOG_BLCKSZ when I changed the way the buffer is
allocated a couple of weeks ago. With the default settings, they are both
8k, but they can be changed at compile-time.
I mixed up BLCKSZ and XLOG_BLCKSZ when I changed the way the buffer is
allocated a couple of weeks ago. With the default settings, they are both
8k, but they can be changed at compile-time.
| src/backend/access/transam/xlog.c | diff | blob | blame | history |
--
公益是一辈子的事,I'm Digoal,Just Do It.
公益是一辈子的事,I'm Digoal,Just Do It.
在 2014-04-16 07:28:52，"Heikki Linnakangas" <hlinnakangas@vmware.com> 写道： >On 04/16/2014 02:17 PM, 德哥 wrote: >> LOG: write() in XLogFileInit returned 40960: Success > >Oh, that's interesting. Have you tweaked BLCKSZ or XLOG_BLCKSZ? If you >have, try with a fresh checkout - I just fixed a bug in that code where >I had used BLCKSZ instead of XLOG_BLCKSZ in the allocation of the >buffer. They're the same by default, but if you've changed them, that >might be it. > >- Heikki