Kenneth Marshall <ktm@xxxxxxxx> writes: > Looking at the XLogInsert() from 8.3 and 8.4, the 8.4 > version includes a call to RecoveryInProgress() at > the top as well as a call to TRACE_POSTGRESQL_XLOG_INSERT(). > Could either of those have caused a context switch or > cache flush resulting in worse performance. Hmm. TRACE_POSTGRESQL_XLOG_INSERT() should be a no-op (or at least, none of the complainants have admitted to building with --enable-dtrace). RecoveryInProgress() should be just a quick test of a local boolean, so it's hard to believe that it costs anything noticeable; but if anyone who is able to reproduce the problem wants to test this theory, try taking out these lines /* cross-check on whether we should be here or not */ if (RecoveryInProgress()) elog(FATAL, "cannot make new WAL entries during recovery"); which are only a sanity check anyway. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
