PostgreSQL provides two developer parameters, pre_auth_delay and post_auth_delay, that introduce a delay during the connection startup process. These parameters are not intended for normal database tuning or improving security. Instead, they are designed to help PostgreSQL developers and database administrators debug authentication-related code by providing enough time to attach a debugger to a backend process.
In this article, we'll explore how both parameters work, where they are defined in the PostgreSQL source code, how to configure them, and how their behavior differs based on their parameter context.
1.pre_auth_delay
Check the current value of this parameter.
show pre_auth_delay ;
Result:
pre_auth_delay
----------------
0
(1 row)
Check the metadata of this parameter from the pg_settings catalogue in postgresql like this.
select * from pg_settings where name = 'pre_auth_delay';
Result:
-[ RECORD 1 ]---+-----------------------------------------------------------------------------
name | pre_auth_delay
setting | 0
unit | s
category | Developer Options
short_desc | Sets the amount of time to wait before authentication on connection startup.
extra_desc | This allows attaching a debugger to the process.
context | sighup
vartype | integer
source | default
min_val | 0
max_val | 60
enumvals |
boot_val | 0
reset_val | 0
sourcefile |
sourceline |
pending_restart | f
Check this parameter definition from the file named guc_parameters.dat in the postgres version 19 source code.
# Not for general use
{ name => 'pre_auth_delay', type => 'int', context => 'PGC_SIGHUP', group => 'DEVELOPER_OPTIONS',
short_desc => 'Sets the amount of time to wait before authentication on connection startup.',
long_desc => 'This allows attaching a debugger to the process.',
flags => 'GUC_NOT_IN_SAMPLE | GUC_UNIT_S',
variable => 'PreAuthDelay',
boot_val => '0',
min => '0',
max => '60',
},
Purpose:
The pre_auth_delay parameter is a developer/debugging parameter in postgres and its main purpose is to pause a newly created backend process before client authentication begins, allowing a developer to attach a debugger and inspect what happens during the authentication phase.
Now, change the value of the parameter like this. Before changing the value of this parameter, check the current value like this.
show pre_auth_delay ;
Result:
pre_auth_delay
----------------
0
(1 row)
Now use the alter system command to change the value of this parameter like this.
alter system set pre_auth_delay = 10;
Now, reload the configuration settings in postgres like this.
select pg_reload_conf();
Result:
pg_reload_conf
----------------
t
(1 row)
Now, ensure that the changed value of this parameter is reflected here.
show pre_auth_delay ;
Result:
pre_auth_delay
----------------
10s
(1 row)
Run the psql terminal with the time command as shown below, then exit the session to view the total time taken to log in.
postgres@cybrosys:/home/cybrosys$ time psql
Exit from the session like this.
psql (19beta2, server 18.6 (Ubuntu 18.6-1.pgdg22.04+2))
Type "help" for help.
postgres=# \q
Result:
real 0m11.605s
user 0m0.019s
sys 0m0.009s
Now, we can see that the authentication time includes the pre_auth_delay. So we can confirm that the pre_auth_delay parameter is working correctly in postgres.
2.Post_auth_delay
Check the current value of this parameter.
show post_auth_delay ;
Result:
post_auth_delay
-----------------
0
(1 row)
Check the metadata of this parameter from the pg_settings catalogue in postgresql like this.
select * from pg_settings where name = 'post_auth_delay';
Result:
-[ RECORD 1 ]---+----------------------------------------------------------------------------
name | post_auth_delay
setting | 0
unit | s
category | Developer Options
short_desc | Sets the amount of time to wait after authentication on connection startup.
extra_desc | This allows attaching a debugger to the process.
context | backend
vartype | integer
source | default
min_val | 0
max_val | 2147
enumvals |
boot_val | 0
reset_val | 0
sourcefile |
sourceline |
pending_restart | f
Check this parameter definition in the file named guc_parameters.dat.
Note: if you are using the source code of postgres version 19, then you can only see this file.
Otherwise, you can see this parameter definition from the file named guc_tables.c
{ name => 'post_auth_delay', type => 'int', context => 'PGC_BACKEND', group => 'DEVELOPER_OPTIONS',
short_desc => 'Sets the amount of time to wait after authentication on connection startup.',
long_desc => 'This allows attaching a debugger to the process.',
flags => 'GUC_NOT_IN_SAMPLE | GUC_UNIT_S',
variable => 'PostAuthDelay',
boot_val => '0',
min => '0',
max => 'INT_MAX / 1000000',
},Purpose:
The post_auth_delay parameter pauses the backend process after authentication has completed successfully but before the session becomes available to the client. It is mainly used for debugging the backend immediately after authentication.
Now, check the current value of this parameter and change the value of this parameter using the ALTER command.
show post_auth_delay ;
Result:
post_auth_delay
-----------------
0
(1 row)
Now, change the value of this parameter like this.
alter system set post_auth_delay = 5;
Now, reload the postgres configuration like this.
select pg_reload_conf();
Result:
pg_reload_conf
----------------
t
(1 row)
Now, ensure that the value of this parameter has changed or not.
show post_auth_delay ;
Result:
post_auth_delay
-----------------
0
(1 row)
Now, we can see that the value has not changed for this parameter because of the parameter context.
In postgresql, each parameter has a parameter context, which indicates where and when the parameter can be changed.
Check the parameter context for this parameter named post_auth_delay like this.
select name, context from pg_settings where name = 'post_auth_delay';
Result:
name | context
-----------------+---------
post_auth_delay | backend
(1 row)
A backend context parameter is only read when a new backend (server process) starts. It cannot be changed for an already running session, even though pg_reload_conf() succeeds.
So just exit the session and open a new session.
Now check the value.
show post_auth_delay ;
Result:
post_auth_delay
-----------------
5s
(1 row)
Now log in to psql with the time command and check the total time taken for psql login like this.
postgres@cybrosys:/home/cybrosys$ time psql
psql (19beta2, server 18.6 (Ubuntu 18.6-1.pgdg22.04+2))
Type "help" for help.
Result:
real 0m18.181s
user 0m0.017s
sys 0m0.012s
Now, the total time includes the values of the pre_auth_delay and post_auth_delay parameters.
The pre_auth_delay and post_auth_delay parameters serve different purposes during the postgres connection startup. The pre_auth_delay parameter pauses the backend before authentication begins and can be applied after reloading the configuration because it uses the signup context.
In contrast, post_auth_delay pauses the backend after authentication has completed successfully and uses the backend context, which means its updated value is applied only to newly created sessions.
Understanding the difference between these contexts helps explain why some configuration changes take effect immediately while others require a new client connection. These parameters are primarily intended for debugging and development rather than everyday database administration.