Re: adding a new column in IDENTIFY_SYSTEM
От | Magnus Hagander |
---|---|
Тема | Re: adding a new column in IDENTIFY_SYSTEM |
Дата | |
Msg-id | BANLkTinALEu1VG_opwBngEubK=YYvcA94w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: adding a new column in IDENTIFY_SYSTEM (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: adding a new column in IDENTIFY_SYSTEM
|
Список | pgsql-hackers |
On Wed, May 4, 2011 at 22:42, Simon Riggs <simon@2ndquadrant.com> wrote: > On Wed, May 4, 2011 at 3:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Jaime Casanova <jaime@2ndquadrant.com> writes: >>> I want to propose the addition of a new field in IDENTIFY_SYSTEM: >>> xlogversion, which will carry XLOG_PAGE_MAGIC from primary. >>> The idea of sending that info is to allow us to know if the xlog page >>> version of two different major versions are compatible or not. >>> Currently pg_upgrade requires the primary to be taken down, >> >> That's *intentional*. >> >> The notion of WAL-shipping-replication compatibility between two >> different major versions is insane on its face. They will not have >> compatible system catalog contents. You might get perfect replication >> of the master's catalogs, but the slave wouldn't be able to interpret >> them. > > That's exactly how hard in place upgrade was to begin with. > > Considering how valuable this would be, it seems worth it to pursue this. > >> The reason we have XLOG_PAGE_MAGIC is really more the opposite: to >> prevent people from trying to recover across a minor version update in >> which we had to break XLOG compatibility. I don't recall right now >> if that's ever actually happened, but it definitely could. > > If that is true, then allowing this patch will allow us to detect that > incompatibility when the standby connects to the master, and explain > the issue in a useful error message. Otherwise we will just barf on > the magic value. > > Having access to these details might make it possible to upgrade. They > could be inferred, but it would be better to have the full data so we > can take an informed decision about whether or not it is possible. > > So even if people don't believe in the rationale behind the patch, > would allowing it harm anything at this point? Adding it for the sake of upgrades seems very far fetched. Adding it for the sake of giving a better error message seems like a very good idea. But in that case, the client side code to actually give a better error message should be included from the start, IMHO. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: