Postgres is getting a Connection reset by peer error on AWS lambda shutdown events

[jimkont]

Hi, we use Quarkus 2.16.x on an AWS lambda application with a Postgres datasource and snapstart enabled.

When I look at the Postgres logs, I notice a lot of logs like the following after ~ 5 minutes of inactivity (~> lambda instance shutdown events?)

2023-05-29 13:00:14 UTC:10.224.184.34(55666):user@database:[5703]:LOG:  could not receive data from client: Connection reset by peer
2023-05-29 13:00:14 UTC:10.224.184.34(58233):user@database:[5704]:LOG:  could not receive data from client: Connection reset by peer
2023-05-29 13:00:14 UTC:10.224.184.34(56427):user@database:[5705]:LOG:  could not receive data from client: Connection reset by peer

Is there any connection that I need to close with the AWS shutdown hook? Currently, we only try to handle Snapstart, as described here with

    fun onStart(@Observes event: StartupEvent) {
        Core.getGlobalContext().register(this)
    }

    override fun beforeCheckpoint(context: org.crac.Context<out Resource>?) {
        // noop
    }

    override fun afterRestore(context: org.crac.Context<out Resource>?) {
        logger().debug("flushing connections after restore")
        dataSource.flush(AgroalDataSource.FlushMode.ALL)
    }

Note that around the time a new function version is created and a new snapshot is provisioned with Snapstart I also get

2023-05-29 12:11:44 UTC:10.224.184.34(31867):[unknown]@[unknown]:[32651]:LOG:  could not accept SSL connection: Connection reset by peer
2023-05-29 12:11:44 UTC:10.224.218.53(53697):[unknown]@[unknown]:[32652]:LOG:  could not accept SSL connection: Connection reset by peer
2023-05-29 12:11:44 UTC:10.224.248.187(11133):[unknown]@[unknown]:[32653]:LOG:  could not receive data from client: Connection reset by peer
2023-05-29 12:11:44 UTC:10.224.248.187(28324):[unknown]@[unknown]:[32654]:LOG:  could not receive data from client: Connection reset by peer

(note the unknown user/db and the SSL error)

When I try with Quarkus 3.0.4, the later logs are fixed but the former are still there

[jimkont]

turns out that setting quarkus.datasource.jdbc.min-size: 0 fixes the error in both 2.x and 3.x