Lets say that due to some corruption, automatic recovery is triggered by postgres. This results in "redo start at 0/9A3F58" as I can in the database logs. As part of the recovery, I suppose it would try to insert the records for a table. Does it cause database insert triggers for that table to be executed as well. We are using postgres 8.4.
Snippet from postgres logs:
2015-06-17 10:43:34 PDT LOG: unexpected EOF on client connection
2015-06-17 10:43:34 PDT LOG: unexpected EOF on client connection
2015-06-17 10:43:34 PDT LOG: unexpected EOF on client connection
2015-06-17 10:43:34 PDT LOG: unexpected EOF on client connection
2015-06-19 08:55:30 CDT LOG: database system was interrupted; last known up at 2015-06-17 20:05:02 CDT
2015-06-19 08:55:30 CDT LOG: database system was not properly shut down; automatic recovery in progress
2015-06-19 08:55:30 CDT LOG: redo starts at 0/9A3F58
2015-06-19 08:55:30 CDT LOG: incomplete startup packet
2015-06-19 08:55:30 CDT FATAL: the database system is starting up
2015-06-19 08:55:30 CDT LOG: record with zero length at 0/E90334
2015-06-19 08:55:30 CDT LOG: redo done at 0/E90308
2015-06-19 08:55:30 CDT LOG: last completed transaction was at log time 2015-06-17 12:43:32.471831-05
2015-06-19 08:55:31 CDT LOG: database system is ready to accept connections
2015-06-19 08:55:31 CDT LOG: autovacuum launcher started
2015-06-19 08:59:29 CDT LOG: unexpected EOF on client connection
2015-06-19 08:59:29 CDT LOG: unexpected EOF on client connection
2015-06-19 08:59:29 CDT LOG: unexpected EOF on client connection
No, replay from the write-ahead logs absolutely do not cause triggers to fire. In fact, they can't because the write-ahead logs store block level changes, not row-level changes, and have no idea which SQL statement changed which row.