Andres Freund wrote: > On 2016-04-15 15:26:17 -0400, Tom Lane wrote: > > I think the bottom line is that we misdesigned the WAL representation > > by assuming that this sort of info could always be piggybacked on a > > transaction commit record. It's time to fix that. > > I think we got to piggyback it onto a commit record, as long as there's > one. Otherwise it's going to be more complex (queuing messages when > reading an inval record) and slower (more wal records). I can easily > develop a patch for that, the question is what we do on the back > branches...
We have introduced new wal records in back branches previously -- nothing new (c.f. 8e9a16ab8f7f0e5813644975cc3f336e5b064b6e). The user just needs to make sure to upgrade the standbys first. If they don't, they would die upon replay of the first such record, which they can take as an indication that they need to be upgraded; the standby is down for some time, but there is no data loss or corruption. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
