On 18 April 2016 at 13:15, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 18 April 2016 at 12:43, Michael Paquier <michael.paqu...@gmail.com> > wrote: > >> On Sat, Apr 16, 2016 at 5:37 AM, Alvaro Herrera >> <alvhe...@2ndquadrant.com> 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). 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. >> >> Yeah, introducing a new WAL record to address this issue in >> back-branches would not be an issue, and that's what we should do. For >> HEAD, let's add that in the commit record. >> > > (non-reply just because of travel) > > OK, I'll write up a patch today to fix, with a view to backpatching. > Patch from Tuesday. On various planes. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
inval_only.v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
