On 2016-04-15 17:37:03 -0300, Alvaro Herrera wrote: > 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).
Yea, I remember ;). We made that decision because we couldn't find another way, and because the consequences were pretty grave. > 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. There could, if they're using wal_keep_segments, and the standby cannot be caught up anymore. I think it's still worth to go for the new record type, but it's a pretty close call. We could also just decide to document the issues :/ - but I'm not sure we're eing all of them yet. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
