Re: BUG #16045: vacuum_db crash and illegal memory alloc afterpg_upgrade from PG11 to PG12
От | Tomas Vondra |
---|---|
Тема | Re: BUG #16045: vacuum_db crash and illegal memory alloc afterpg_upgrade from PG11 to PG12 |
Дата | |
Msg-id | 20191015070725.csmdmdvrlb6klwkg@development обсуждение исходный текст |
Ответ на | Re: BUG #16045: vacuum_db crash and illegal memory alloc afterpg_upgrade from PG11 to PG12 (Justin Pryzby <pryzby@telsasoft.com>) |
Список | pgsql-bugs |
On Mon, Oct 14, 2019 at 11:41:18PM -0500, Justin Pryzby wrote: >On Tue, Oct 15, 2019 at 02:18:17AM +0200, Tomas Vondra wrote: >> On Mon, Oct 14, 2019 at 06:35:38PM +0200, Tomas Vondra wrote: >> >... >> > >> >Aha! I forgot we copy the necessary stuff into pg_attribute. Thanks for >> >clarifying, I'll polish and push the fix shortly. > >Perhaps it'd be worth creating a test for on-disk format ? > >Like a table with a column for each core type, which is either SELECTed from >after pg_upgrade, or pg_dump output compared before and after. > IMO that would be useful - we now have a couple of these checks for different data types (line, unknown, sql_identifier), with a couple of combinations each. And I've been looking if we do similar pg_upgrade tests, but I haven't found anything. I mean, we do pg_upgrade the cluster used for regression tests, but here we need to test a number of cases that are meant to abort the pg_upgrade. So we'd need a number of pg_upgrade runs, to test that. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-bugs по дате отправления: