Re: increasing the default WAL segment size

Beena Emerson <memissemerson@gmail.com>

From: Beena Emerson <memissemerson@gmail.com>
To: tushar <tushar.ahuja@enterprisedb.com>
Cc: Ashutosh Sharma <ashu.coek88@gmail.com>, Jim Nasby <Jim.Nasby@bluetreble.com>, Kuntal Ghosh <kuntalghosh.2007@gmail.com>, Andres Freund <andres@anarazel.de>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-03-13T06:06:53Z
Lists: pgsql-hackers
Hello,

Thank you testing. I just wanted to confirm few things since I do not have
linux32 setup yet.

On Fri, Mar 10, 2017 at 1:09 PM, tushar <tushar.ahuja@enterprisedb.com>
wrote:

> On 03/10/2017 11:23 AM, Beena Emerson wrote:
>
>
>> Thank you for your reviews Kuntal, Jim, Ashutosh
>
> Attached in an updated 02 patch which:
>
>    1. Call RetrieveXLogSegSize(conn) in pg_receivewal.c
>    2. Remove the warning in Windows
>    3. Change PATH_MAX in pg_waldump with MAXPGPATH
>
> Regarding the usage of the wal file size as the XLogSegSize, I agree with
> what Robert has said. Generally, the wal size will be of the expected
> wal_segment_size and to have it any other size, esspecially of a valid
> power2 value is extremely rare and I feel it is not a major cause of
> concern.
>
> We (Prabhat and I) have started basic  testing of this feature -
> 2 quick issue -
>
> 1)at the time of initdb, we have set - "--wal-segsize 4"  ,so all the WAL
> file size should be 4 MB each  but in the postgresql.conf file , it is
> mentioned
>
> #wal_keep_segments = 0          # in logfile segments,* 16MB each*; 0
> disables
>
> so the comment  (16MB ) mentioned against parameter 'wal_keep_segments'
> looks wrong , either we should remove this or modify it .
>
> 2)Getting "Aborted (core dumped)"  error at the time of running
> pg_basebackup  ,
> *(this issue is only coming on Linux32 ,not on Linux64) * we have  double
> check to confirm it .
>
> Steps to reproduce on Linux32
> ===================
> fetch the sources
> apply both the patches
>  ./configure --with-zlib   --enable-debug  --enable-cassert
> --enable-depend --prefix=$PWD/edbpsql --with-openssl CFLAGS="-g -O0"; make
> all install
> Performed initdb with switch "--wal-segsize 4"
>

Does the crash occur with only size 4?


> start the server
> run pg_basebackup
>
> [centos@tushar-centos bin]$ ./pg_basebackup -v -D /tmp/myslave
> *** glibc detected *** ./pg_basebackup: free(): invalid pointer:
> 0x08da7f00 ***
>
> [centos@tushar-centos bin]$
>
> same scenario is working fine against HEAD (v10 ) on Linux32 [i.e no patch
> applied]
>
> [centos@tushar-centos bin]$ ./pg_basebackup --verbose -D /tmp/slave11
> pg_basebackup: initiating base backup, waiting for checkpoint to complete
> pg_basebackup: checkpoint completed
> pg_basebackup: transaction log start point: 0/2800024 on timeline 1
> pg_basebackup: starting background WAL receiver
> pg_basebackup: transaction log end point: 0/28000E4
> pg_basebackup: waiting for background process to finish streaming ...
> pg_basebackup: base backup completed
> [centos@tushar-centos bin]$
>

Just to confirm, was this done with configure flag --with-wal-segsize=4 ?


Thank you,

Beena Emerson

EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Make WAL segment size configurable at initdb time.

  2. Perform only one ReadControlFile() during startup.

  3. Introduce BYTES unit for GUCs.

  4. Remove useless duplicate inclusions of system header files.

  5. Refactor other replication commands to use DestRemoteSimple.

  6. Add a SHOW command to the replication command language.

  7. Add a new DestReceiver for printing tuples without catalog access.

  8. Support fls().

  9. Extend yesterday's patch making BLCKSZ and RELSEG_SIZE configurable to also

  10. Commit the reasonably uncontroversial parts of J.R. Nield's PITR patch, to

  11. XLOG (also known as WAL -:)) Bootstrap/Startup/Shutdown.

  12. Transaction log manager core code.