0

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
Kushal Chokhani
  • 33
  • 7

1 Answers1

0

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.

Craig Ringer
  • 307,061
  • 76
  • 688
  • 778
  • Thanks for replying Craig. – Kushal Chokhani Jul 16 '15 at 14:02
  • On a different note, is there a way for me to induce such corruption resulting in auto-recovery like the one shown in logs above. For some reason, I believe it might have cause a problem in our workflow. – Kushal Chokhani Jul 16 '15 at 14:04
  • @KushalChokhani I don't see any sign of "corruption" above, from your logs. Just an unclean restart. – Craig Ringer Jul 16 '15 at 14:44
  • So when it says "database system was not properly shut down; automatic recovery in progress; redo starts at 0/9A3F58", you mean it is not doing any kind of recovery. If not, what could it be trying to do? – Kushal Chokhani Jul 16 '15 at 14:59
  • @KushalChokhani It's doing crash recovery after unclean shutdown, such as a crash of the database server or the host machine. This is normal, and just indicates that the database is doing the work required to prevent any data corruption, ensuring that all committed transactions are visible and all uncommitted ones are rolled back. There is no problem here. – Craig Ringer Jul 16 '15 at 15:15