]> granicus.if.org Git - postgresql/commitdiff
Fix incorrect timeout handling during initial authentication transaction.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 13 Aug 2011 21:52:24 +0000 (17:52 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 13 Aug 2011 21:52:41 +0000 (17:52 -0400)
The statement start timestamp was not set before initiating the transaction
that is used to look up client authentication information in pg_authid.
In consequence, enable_sig_alarm computed a wrong value (far in the past)
for statement_fin_time.  That didn't have any immediate effect, because the
timeout alarm was set without reference to statement_fin_time; but if we
subsequently blocked on a lock for a short time, CheckStatementTimeout
would consult the bogus value when we cancelled the lock timeout wait,
and then conclude we'd timed out, leading to immediate failure of the
connection attempt.  Thus an innocent "vacuum full pg_authid" would cause
failures of concurrent connection attempts.  Noted while testing other,
more serious consequences of vacuum full on system catalogs.

We should set the statement timestamp before StartTransactionCommand(),
so that the transaction start timestamp is also valid.  I'm not sure if
there are any non-cosmetic effects of it not being valid, but the xact
timestamp is at least sent to the statistics machinery.

Back-patch to 9.0.  Before that, the client authentication timeout was done
outside any transaction and did not depend on this state to be valid.

src/backend/utils/init/postinit.c

index 1476df4db285cd1982105f68230e5332a3e3a29b..94f92dd7343af74c37b7efe9f5f57a44f42c3d9e 100644 (file)
@@ -571,6 +571,8 @@ InitPostgres(const char *in_dbname, Oid dboid, const char *username,
         */
        if (!bootstrap)
        {
+               /* statement_timestamp must be set for timeouts to work correctly */
+               SetCurrentStatementStartTimestamp();
                StartTransactionCommand();
                (void) GetTransactionSnapshot();
        }