Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts |
Дата | |
Msg-id | 20140620184224.GG29143@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Fri, Jun 20, 2014 at 02:24:55PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > On Fri, Jun 20, 2014 at 01:41:42PM -0400, Tom Lane wrote: > >> Yeah. In my mind, at least, there's been a TODO for some time for > >> pg_resetxlog to make sure that pg_clog and the other SLRU-like files > >> get populated appropriately when you tell it to change those counters. > >> You have to have a segment file at the right place or startup fails. > > > Well, if we are going to do this, we had better do all cases or the > > behavior will be quite surprising, and when doing disaster recovery, > > surprises are not good. I am a little worried that removing files as > > part of pg_resetxlog might cause data to be lost as users try to figure > > things out. > > Huh? The basic charter of pg_resetxlog is to throw away files, ie, all > of your WAL. > > But in this case what we're talking about is a secondary function, namely > the ability to move the XID, MXID, etc counter values. Up to now, if you > did that, it was on your head to manually create appropriate SLRU segment > files. It's certainly less error-prone, not more so, if the code were > to take care of that for you. I am fine with that, but let's do a complete job so the user API is not confusing. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-bugs по дате отправления: