Re: pgsql: Check for conflicting queries during replay of gistvacuumpage()

2018-12-21 Thread Alexander Korotkov
On Fri, Dec 21, 2018 at 7:09 PM Tom Lane wrote: > Alvaro Herrera writes: > >> Hmmm, I'm fairly sure you should have bumped XLOG_PAGE_MAGIC for this > >> change. Otherwise, what is going to happen to an unpatched standby (of > >> released versions) that receives the new WAL record from a patched

Re: pgsql: Check for conflicting queries during replay of gistvacuumpage()

2018-12-21 Thread Alvaro Herrera
On 2018-Dec-21, Tom Lane wrote: > Alvaro Herrera writes: > > Hmmm, I'm fairly sure you should have bumped XLOG_PAGE_MAGIC for this > > change. Otherwise, what is going to happen to an unpatched standby (of > > released versions) that receives the new WAL record from a patched > > primary? > > W

Re: pgsql: Check for conflicting queries during replay of gistvacuumpage()

2018-12-21 Thread Tom Lane
Alvaro Herrera writes: >> Hmmm, I'm fairly sure you should have bumped XLOG_PAGE_MAGIC for this >> change. Otherwise, what is going to happen to an unpatched standby (of >> released versions) that receives the new WAL record from a patched >> primary? Oh, and if the answer to your question is no

Re: pgsql: Check for conflicting queries during replay of gistvacuumpage()

2018-12-21 Thread Tom Lane
Alvaro Herrera writes: > Hmmm, I'm fairly sure you should have bumped XLOG_PAGE_MAGIC for this > change. Otherwise, what is going to happen to an unpatched standby (of > released versions) that receives the new WAL record from a patched > primary? We can't change XLOG_PAGE_MAGIC in released bran

Re: pgsql: Check for conflicting queries during replay of gistvacuumpage()

2018-12-21 Thread Alvaro Herrera
Hmmm, I'm fairly sure you should have bumped XLOG_PAGE_MAGIC for this change. Otherwise, what is going to happen to an unpatched standby (of released versions) that receives the new WAL record from a patched primary? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Develo