Re: pg_dump versus ancient server versions
От | Tom Lane |
---|---|
Тема | Re: pg_dump versus ancient server versions |
Дата | |
Msg-id | 3506994.1638903154@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_dump versus ancient server versions (Mark Dilger <mark.dilger@enterprisedb.com>) |
Ответы |
Re: pg_dump versus ancient server versions
|
Список | pgsql-hackers |
Mark Dilger <mark.dilger@enterprisedb.com> writes: > Wouldn't you be able to see what changed by comparing the last released tag for version X.Y against the RELX_Y_STABLE branch? Something like `git diff REL8_4_22 origin/REL8_4_STABLE > buildability.patch`? > Having such a patch should make reproducing old corruption bugs easier, as you could apply the buildability.patch to thelast branch that contained the bug. If anybody did that work, would we want it committed somewhere? REL8_4_19_BUILDABLEor such? For patches that apply trivially, that might not be worth keeping, but if the merge is difficult,maybe sharing with the community would make sense. I'm not entirely following ... are you suggesting that each released minor version needs to be kept buildable separately? That seems like a huge amount of extra committer effort with not much added value. If someone comes to me and wants to investigate a bug in a branch that's already out-of-support, and they then say they're not running the last minor release, I'm going to tell them to come back after updating. It is (I suspect) true that diffing the last release against branch tip would often yield a patch that could be used to make an older minor release buildable again. But when that patch doesn't work trivially, I for one am not interested in making it work. And especially not interested in doing so "on spec", with no certainty that anyone would ever need it. regards, tom lane
В списке pgsql-hackers по дате отправления: