Thread: postgresql-13devel initDB Running in debug mode.

postgresql-13devel initDB Running in debug mode.

From
legrand legrand
Date:
Hello,
after building devel snapshot from 2020-01-17 with msys,
initDB generates a lot of additional informations when launched:

VERSION=13devel
PGDATA=../data
share_path=C:/msys64/usr/local/pgsql/share
PGPATH=C:/msys64/usr/local/pgsql/bin
POSTGRES_SUPERUSERNAME=lemoyp
POSTGRES_BKI=C:/msys64/usr/local/pgsql/share/postgres.bki
POSTGRES_DESCR=C:/msys64/usr/local/pgsql/share/postgres.description
POSTGRES_SHDESCR=C:/msys64/usr/local/pgsql/share/postgres.shdescription
POSTGRESQL_CONF_SAMPLE=C:/msys64/usr/local/pgsql/share/postgresql.conf.sample
PG_HBA_SAMPLE=C:/msys64/usr/local/pgsql/share/pg_hba.conf.sample
PG_IDENT_SAMPLE=C:/msys64/usr/local/pgsql/share/pg_ident.conf.sample
2020-01-18 00:19:37.407 CET [10152] DEBUG:  invoking
IpcMemoryCreate(size=149061632)
2020-01-18 00:19:37.408 CET [10152] DEBUG:  could not enable Lock Pages in
Memory user right
2020-01-18 00:19:37.408 CET [10152] HINT:  Assign Lock Pages in Memory user
right to the Windows user account which runs PostgreSQL.
2020-01-18 00:19:37.408 CET [10152] DEBUG:  disabling huge pages
2020-01-18 00:19:37.414 CET [10152] DEBUG:  SlruScanDirectory invoking
callback on pg_notify/0000
2020-01-18 00:19:37.414 CET [10152] DEBUG:  removing file "pg_notify/0000"
2020-01-18 00:19:37.416 CET [10152] DEBUG:  dynamic shared memory system
will support 308 segments
2020-01-18 00:19:37.416 CET [10152] DEBUG:  created dynamic shared memory
control segment 718036776 (7408 bytes)
2020-01-18 00:19:37.416 CET [10152] DEBUG:  transaction ID wrap limit is
2147483650, limited by database with OID 1
2020-01-18 00:19:37.416 CET [10152] DEBUG:  MultiXactId wrap limit is
2147483648, limited by database with OID 1
2020-01-18 00:19:37.416 CET [10152] DEBUG:  creating and filling new WAL
file
2020-01-18 00:19:37.446 CET [10152] DEBUG:  could not remove file
"pg_wal/000000010000000000000001": No such file or directory
2020-01-18 00:19:37.454 CET [10152] DEBUG:  mapped win32 error code 5 to 13
2020-01-18 00:19:37.455 CET [10152] DEBUG:  done creating and filling new
WAL file
2020-01-18 00:19:37.467 CET [10152] DEBUG:  InitPostgres
2020-01-18 00:19:37.467 CET [10152] DEBUG:  my backend ID is 1
2020-01-18 00:19:37.467 CET [10152] NOTICE:  database system was shut down
at 2020-01-18 00:19:37 CET
2020-01-18 00:19:37.467 CET [10152] DEBUG:  mapped win32 error code 2 to 2
2020-01-18 00:19:37.471 CET [10152] DEBUG:  checkpoint record is at
0/1000028
2020-01-18 00:19:37.471 CET [10152] DEBUG:  redo record is at 0/1000028;
shutdown true
...

Is that the expected behavior, or just a temporary test ?
Regards
PAscal



--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html



Re: postgresql-13devel initDB Running in debug mode.

From
Tom Lane
Date:
legrand legrand <legrand_legrand@hotmail.com> writes:
> after building devel snapshot from 2020-01-17 with msys,
> initDB generates a lot of additional informations when launched:
> [ debug output snipped ]
> Is that the expected behavior, or just a temporary test ?

It'd be the expected behavior if you'd given a -d switch to initdb.

            regards, tom lane



Re: postgresql-13devel initDB Running in debug mode.

From
legrand legrand
Date:
Tom Lane-2 wrote
> legrand legrand <

> legrand_legrand@

> > writes:
>> after building devel snapshot from 2020-01-17 with msys,
>> initDB generates a lot of additional informations when launched:
>> [ debug output snipped ]
>> Is that the expected behavior, or just a temporary test ?
> 
> It'd be the expected behavior if you'd given a -d switch to initdb.
> 
>             regards, tom lane

so yes, its me :
-d directory 
inspite of 
-D directory

and the doc is perfect:
-d
--debug

    Print debugging output from the bootstrap backend and a few other
messages of lesser interest for the general public. The bootstrap backend is
the program initdb uses to create the catalog tables. This option generates
a tremendous amount of extremely boring output.

Regards
PAscal



--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html