Обсуждение: BUG #14181: pg_upgrade: operator family "btree_hstore_ops" does not exist
BUG #14181: pg_upgrade: operator family "btree_hstore_ops" does not exist
От
worden.eric@gmail.com
Дата:
VGhlIGZvbGxvd2luZyBidWcgaGFzIGJlZW4gbG9nZ2VkIG9uIHRoZSB3ZWJz aXRlOgoKQnVnIHJlZmVyZW5jZTogICAgICAxNDE4MQpMb2dnZWQgYnk6ICAg ICAgICAgIEVyaWMgV29yZGVuCkVtYWlsIGFkZHJlc3M6ICAgICAgd29yZGVu LmVyaWNAZ21haWwuY29tClBvc3RncmVTUUwgdmVyc2lvbjogOS41LjMKT3Bl cmF0aW5nIHN5c3RlbTogICBSZWQgSGF0IEVudGVycHJpc2UgTGludXggU2Vy dmVyIHJlbGVhc2UgNy4yIChNYWlwbwpEZXNjcmlwdGlvbjogICAgICAgIAoK SSdtIGF0dGVtcHRpbmcgdG8gdXBncmFkZSBmcm9tIDkuNC44LiBoc3RvcmUg aW5zdGFsbGVkIHZlcnNpb24gb24gdGhlIDkuNApjbHVzdGVyIGlzIDEuMy4g SXQgYWxzbyBmYWlsZWQgd2l0aCB2ZXJzaW9uIDEuMi4NCg0KcGdfdXBncmFk ZSBpcyBleGl0aW5nIHdpdGggZmFpbHVyZSBkdXJpbmcgdGhlIHN0ZXAgIlJl c3RvcmluZyBkYXRhYmFzZQpzY2hlbWFzIGluIHRoZSBuZXcgY2x1c3RlciIu IFNldmVyYWwgZGF0YWJhc2Ugc2NoZW1hcyBhcmUgcmVzdG9yZWQKc3VjY2Vz c2Z1bGx5LCB0aGVuIG9uZSBmYWlscy4gVGhlIHBnX3Jlc3RvcmUgbG9nIGlu ZGljYXRlZCBieSB0aGUgcGdfdXBncmFkZQpvdXRwdXQgZW5kcyB3aXRoOg0K DQpwZ19yZXN0b3JlOiBbYXJjaGl2ZXIgKGRiKV0gY291bGQgbm90IGV4ZWN1 dGUgcXVlcnk6IEVSUk9SOiAgb3BlcmF0b3IgZmFtaWx5CiJidHJlZV9oc3Rv cmVfb3BzIiBkb2VzIG5vdCBleGlzdCBmb3IgYWNjZXNzIG1ldGhvZCAiYnRy ZWUiDQogICAgQ29tbWFuZCB3YXM6IENSRUFURSBPUEVSQVRPUiBDTEFTUyAi YnRyZWVfaHN0b3JlX29wcyINCiAgICBERUZBVUxUIEZPUiBUWVBFICJoc3Rv cmUiIFVTSU5HICJidHJlZSIgRkFNSUxZICJidHJlZV9oc3RvcmVfb3BzIiBB Uw0KICAgIE9QRVJBVC4uLg0KDQpUaGUgZG9jdW1lbnRhdGlvbiBmb3IgQ1JF QVRFIE9QRVJBVE9SIENMQVNTIHNheXMgdGhhdCB0aGUgb3BlcmF0b3IgZmFt aWx5CndpbGwgYmUgY3JlYXRlZCBpZiBpdCBkb2VzIG5vdCBhbHJlYWR5IGV4 aXN0LCBjb250cmFyeSB0byB3aGF0IHRoZSBlcnJvcgptZXNzYWdlIHNheXMg aGVyZS4NCg0KSGVyZSBpcyBhbiBleGNlcnB0IG9mIHRoZSBwZ19yZXN0b3Jl IGxvZyBjcmVhdGVkIGJ5IHBnX3VwZ3JhZGU6DQoNCjw9PT09PT09IGV4Y2Vy cHQgPT09PT09PT09Pg0KY29tbWFuZDogIi91c3IvcGdzcWwtOS41L2Jpbi9w Z19kdW1wIiAtLWhvc3QgIi92YXIvbGliL3Bnc3FsLzc3Njk0IiAtLXBvcnQK NTQzMiAtLXVzZXJuYW1lICJwb3N0Z3JlcyIgLS1zY2hlbWEtb25seSAtLXF1 b3RlLWFsbC1pZGVudGlmaWVycwotLWJpbmFyeS11cGdyYWRlIC0tZm9ybWF0 PWN1c3RvbSAgLS1maWxlPSJwZ191cGdyYWRlX2R1bXBfMTY0MjAuY3VzdG9t IgoiZm9vIiA+PiAicGdfdXBncmFkZV9kdW1wXzE2NDIwLmxvZyIgMj4mMQ0K DQoNCmNvbW1hbmQ6ICIvdXNyL3Bnc3FsLTkuNS9iaW4vcGdfcmVzdG9yZSIg LS1ob3N0ICIvdmFyL2xpYi9wZ3NxbC83NzY5NCIKLS1wb3J0IDU0MzIgLS11 c2VybmFtZSAicG9zdGdyZXMiIC0tZXhpdC1vbi1lcnJvciAtLXZlcmJvc2Ug LS1kYm5hbWUgImZvbyIKInBnX3VwZ3JhZGVfZHVtcF8xNjQyMC5jdXN0b20i ID4+ICJwZ191cGdyYWRlX2R1bXBfMTY0MjAubG9nIiAyPiYxDQpwZ19yZXN0 b3JlOiBjb25uZWN0aW5nIHRvIGRhdGFiYXNlIGZvciByZXN0b3JlDQpwZ19y ZXN0b3JlOiBjcmVhdGluZyBwZ19sYXJnZW9iamVjdCAicGdfbGFyZ2VvYmpl Y3QiDQpwZ19yZXN0b3JlOiBjcmVhdGluZyBwZ19sYXJnZW9iamVjdF9tZXRh ZGF0YSAicGdfbGFyZ2VvYmplY3RfbWV0YWRhdGEiDQpwZ19yZXN0b3JlOiBj cmVhdGluZyBTQ0hFTUEgImFpcyINCi4uLg0KcGdfcmVzdG9yZTogY3JlYXRp bmcgRVhURU5TSU9OICJmdXp6eXN0cm1hdGNoIg0KcGdfcmVzdG9yZTogY3Jl YXRpbmcgQ09NTUVOVCAiRVhURU5TSU9OICJmdXp6eXN0cm1hdGNoIiINCnBn X3Jlc3RvcmU6IGNyZWF0aW5nIEVYVEVOU0lPTiAiaHN0b3JlIg0KcGdfcmVz dG9yZTogY3JlYXRpbmcgQ09NTUVOVCAiRVhURU5TSU9OICJoc3RvcmUiIg0K cGdfcmVzdG9yZTogY3JlYXRpbmcgRVhURU5TSU9OICJ0YWJsZWZ1bmMiDQpw Z19yZXN0b3JlOiBjcmVhdGluZyBDT01NRU5UICJFWFRFTlNJT04gInRhYmxl ZnVuYyIiDQpwZ19yZXN0b3JlOiBjcmVhdGluZyBTSEVMTCBUWVBFICJwZ19j YXRhbG9nLmdoc3RvcmUiDQpwZ19yZXN0b3JlOiBjcmVhdGluZyBGVU5DVElP TiAicGdfY2F0YWxvZy5naHN0b3JlX2luKCJjc3RyaW5nIikiDQpwZ19yZXN0 b3JlOiBjcmVhdGluZyBGVU5DVElPTiAicGdfY2F0YWxvZy5naHN0b3JlX291 dCgiZ2hzdG9yZSIpIg0KcGdfcmVzdG9yZTogY3JlYXRpbmcgVFlQRSAicGdf Y2F0YWxvZy5naHN0b3JlIg0KcGdfcmVzdG9yZTogY3JlYXRpbmcgU0hFTEwg VFlQRSAicGdfY2F0YWxvZy5oc3RvcmUiDQpwZ19yZXN0b3JlOiBjcmVhdGlu ZyBGVU5DVElPTiAicGdfY2F0YWxvZy5oc3RvcmVfaW4oImNzdHJpbmciKSIN CnBnX3Jlc3RvcmU6IGNyZWF0aW5nIEZVTkNUSU9OICJwZ19jYXRhbG9nLmhz dG9yZV9vdXQoImhzdG9yZSIpIg0KcGdfcmVzdG9yZTogY3JlYXRpbmcgRlVO Q1RJT04gInBnX2NhdGFsb2cuaHN0b3JlX3JlY3YoImludGVybmFsIikiDQpw Z19yZXN0b3JlOiBjcmVhdGluZyBGVU5DVElPTiAicGdfY2F0YWxvZy5oc3Rv cmVfc2VuZCgiaHN0b3JlIikiDQpwZ19yZXN0b3JlOiBjcmVhdGluZyBUWVBF ICJwZ19jYXRhbG9nLmhzdG9yZSINCnBnX3Jlc3RvcmU6IGNyZWF0aW5nIFRZ UEUgInB1YmxpYy5hc3NldF90eXBlIg0KLi4uDQpwZ19yZXN0b3JlOiBjcmVh dGluZyBGVU5DVElPTiAicGdfY2F0YWxvZy5lYWNoKCJoc3RvcmUiKSINCnBn X3Jlc3RvcmU6IGNyZWF0aW5nIEZVTkNUSU9OICJwZ19jYXRhbG9nLmV4aXN0 KCJoc3RvcmUiLCAidGV4dCIpIg0KcGdfcmVzdG9yZTogY3JlYXRpbmcgRlVO Q1RJT04gInBnX2NhdGFsb2cuZXhpc3RzX2FsbCgiaHN0b3JlIiwgInRleHQi W10pIg0KcGdfcmVzdG9yZTogY3JlYXRpbmcgRlVOQ1RJT04gInBnX2NhdGFs b2cuZXhpc3RzX2FueSgiaHN0b3JlIiwgInRleHQiW10pIg0KcGdfcmVzdG9y ZTogY3JlYXRpbmcgRlVOQ1RJT04gInBnX2NhdGFsb2cuZmV0Y2h2YWwoImhz dG9yZSIsICJ0ZXh0IikiDQouLi4NCnBnX3Jlc3RvcmU6IGNyZWF0aW5nIE9Q RVJBVE9SICJwZ19jYXRhbG9nLn4iDQpwZ19yZXN0b3JlOiBjcmVhdGluZyBP UEVSQVRPUiBDTEFTUyAicGdfY2F0YWxvZy5idHJlZV9oc3RvcmVfb3BzIg0K cGdfcmVzdG9yZTogW2FyY2hpdmVyIChkYildIEVycm9yIHdoaWxlIFBST0NF U1NJTkcgVE9DOg0KcGdfcmVzdG9yZTogW2FyY2hpdmVyIChkYildIEVycm9y IGZyb20gVE9DIGVudHJ5IDU2ODA7IDI2MTYgMTg3NzIgT1BFUkFUT1IKQ0xB U1MgYnRyZWVfaHN0b3JlX29wcyBkYmFkbWluDQpwZ19yZXN0b3JlOiBbYXJj aGl2ZXIgKGRiKV0gY291bGQgbm90IGV4ZWN1dGUgcXVlcnk6IEVSUk9SOiAg b3BlcmF0b3IgZmFtaWx5CiJidHJlZV9oc3RvcmVfb3BzIiBkb2VzIG5vdCBl eGlzdCBmb3IgYWNjZXNzIG1ldGhvZCAiYnRyZWUiDQogICAgQ29tbWFuZCB3 YXM6IENSRUFURSBPUEVSQVRPUiBDTEFTUyAiYnRyZWVfaHN0b3JlX29wcyIN CiAgICBERUZBVUxUIEZPUiBUWVBFICJoc3RvcmUiIFVTSU5HICJidHJlZSIg RkFNSUxZICJidHJlZV9oc3RvcmVfb3BzIiBBUw0KICAgIE9QRVJBVC4uLg0K PC89PT09PT09IGV4Y2VycHQgPT09PT09PT09Pg0KDQpIZXJlIGlzIGFuIGV4 Y2VycHQgb2YgdGhlIHBnX2R1bXAgZmlsZSB1c2VkIGJ5IHRoZSBmYWlsaW5n IHBnX3Jlc3RvcmU6DQoNCjw9PT09PT09IGV4Y2VycHQgPT09PT09PT09Pg0K LS0NCi0tIFBvc3RncmVTUUwgZGF0YWJhc2UgZHVtcA0KLS0NCg0KLS0gRHVt cGVkIGZyb20gZGF0YWJhc2UgdmVyc2lvbiA5LjQuOA0KLS0gRHVtcGVkIGJ5 IHBnX2R1bXAgdmVyc2lvbiA5LjUuMw0KDQpTRVQgc3RhdGVtZW50X3RpbWVv dXQgPSAwOw0KU0VUIGxvY2tfdGltZW91dCA9IDA7DQpTRVQgY2xpZW50X2Vu Y29kaW5nID0gJ1VURjgnOw0KU0VUIHN0YW5kYXJkX2NvbmZvcm1pbmdfc3Ry aW5ncyA9IG9uOw0KU0VUIGNoZWNrX2Z1bmN0aW9uX2JvZGllcyA9IGZhbHNl Ow0KU0VUIGNsaWVudF9taW5fbWVzc2FnZXMgPSB3YXJuaW5nOw0KU0VUIHJv d19zZWN1cml0eSA9IG9mZjsNCg0KWy4uLl0NCg0KLS0NCi0tIE5hbWU6IGhz dG9yZTsgVHlwZTogRVhURU5TSU9OOyBTY2hlbWE6IC07IE93bmVyOiANCi0t DQoNCi0tIEZvciBiaW5hcnkgdXBncmFkZSwgY3JlYXRlIGFuIGVtcHR5IGV4 dGVuc2lvbiBhbmQgaW5zZXJ0IG9iamVjdHMgaW50bwppdA0KRFJPUCBFWFRF TlNJT04gSUYgRVhJU1RTICJoc3RvcmUiOw0KU0VMRUNUIHBnX2NhdGFsb2cu YmluYXJ5X3VwZ3JhZGVfY3JlYXRlX2VtcHR5X2V4dGVuc2lvbignaHN0b3Jl JywKJ3BnX2NhdGFsb2cnLCB0cnVlLCAnMS4zJywgTlVMTCwgTlVMTCwgQVJS QVlbXTo6cGdfY2F0YWxvZy50ZXh0W10pOw0KDQoNCi0tDQotLSBOYW1lOiBF WFRFTlNJT04gImhzdG9yZSI7IFR5cGU6IENPTU1FTlQ7IFNjaGVtYTogLTsg T3duZXI6IA0KLS0NCi0tDQotLSBOYW1lOiBnaHN0b3JlOyBUeXBlOiBTSEVM TCBUWVBFOyBTY2hlbWE6IHBnX2NhdGFsb2c7IE93bmVyOiBkYmFkbWluDQot LQ0KDQoNCi0tIEZvciBiaW5hcnkgdXBncmFkZSwgbXVzdCBwcmVzZXJ2ZSBw Z190eXBlIG9pZA0KU0VMRUNUCnBnX2NhdGFsb2cuYmluYXJ5X3VwZ3JhZGVf c2V0X25leHRfcGdfdHlwZV9vaWQoJzE4NDcxJzo6cGdfY2F0YWxvZy5vaWQp Ow0KDQoNCi0tIEZvciBiaW5hcnkgdXBncmFkZSwgbXVzdCBwcmVzZXJ2ZSBw Z190eXBlIGFycmF5IG9pZA0KU0VMRUNUCnBnX2NhdGFsb2cuYmluYXJ5X3Vw Z3JhZGVfc2V0X25leHRfYXJyYXlfcGdfdHlwZV9vaWQoJzY4MzUyNCc6OnBn X2NhdGFsb2cub2lkKTsNCg0KQ1JFQVRFIFRZUEUgImdoc3RvcmUiOw0KDQot LQ0KLS0gTmFtZTogZ2hzdG9yZV9pbigiY3N0cmluZyIpOyBUeXBlOiBGVU5D VElPTjsgU2NoZW1hOiBwZ19jYXRhbG9nOyBPd25lcjoKZGJhZG1pbg0KLS0N Cg0KQ1JFQVRFIEZVTkNUSU9OICJnaHN0b3JlX2luIigiY3N0cmluZyIpIFJF VFVSTlMgImdoc3RvcmUiDQogICAgTEFOR1VBR0UgImMiIElNTVVUQUJMRSBT VFJJQ1QNCiAgICBBUyAnJGxpYmRpci9oc3RvcmUnLCAnZ2hzdG9yZV9pbic7 DQoNCi0tIEZvciBiaW5hcnkgdXBncmFkZSwgaGFuZGxlIGV4dGVuc2lvbiBt ZW1iZXJzaGlwIHRoZSBoYXJkIHdheQ0KQUxURVIgRVhURU5TSU9OICJoc3Rv cmUiIEFERCBGVU5DVElPTiAiZ2hzdG9yZV9pbiIoImNzdHJpbmciKTsNCg0K DQpBTFRFUiBGVU5DVElPTiAicGdfY2F0YWxvZyIuImdoc3RvcmVfaW4iKCJj c3RyaW5nIikgT1dORVIgVE8gZGJhZG1pbjsNCg0KLS0NCi0tIE5hbWU6IGdo c3RvcmVfb3V0KCJnaHN0b3JlIik7IFR5cGU6IEZVTkNUSU9OOyBTY2hlbWE6 IHBnX2NhdGFsb2c7IE93bmVyOgpkYmFkbWluDQotLQ0KDQpDUkVBVEUgRlVO Q1RJT04gImdoc3RvcmVfb3V0IigiZ2hzdG9yZSIpIFJFVFVSTlMgImNzdHJp bmciDQogICAgTEFOR1VBR0UgImMiIElNTVVUQUJMRSBTVFJJQ1QNCiAgICBB UyAnJGxpYmRpci9oc3RvcmUnLCAnZ2hzdG9yZV9vdXQnOw0KDQotLSBGb3Ig YmluYXJ5IHVwZ3JhZGUsIGhhbmRsZSBleHRlbnNpb24gbWVtYmVyc2hpcCB0 aGUgaGFyZCB3YXkNCkFMVEVSIEVYVEVOU0lPTiAiaHN0b3JlIiBBREQgRlVO Q1RJT04gImdoc3RvcmVfb3V0IigiZ2hzdG9yZSIpOw0KDQoNCkFMVEVSIEZV TkNUSU9OICJwZ19jYXRhbG9nIi4iZ2hzdG9yZV9vdXQiKCJnaHN0b3JlIikg T1dORVIgVE8gZGJhZG1pbjsNCg0KLS0NCi0tIE5hbWU6IGdoc3RvcmU7IFR5 cGU6IFRZUEU7IFNjaGVtYTogcGdfY2F0YWxvZzsgT3duZXI6IGRiYWRtaW4N Ci0tDQoNCg0KLS0gRm9yIGJpbmFyeSB1cGdyYWRlLCBtdXN0IHByZXNlcnZl IHBnX3R5cGUgb2lkDQpTRUxFQ1QKcGdfY2F0YWxvZy5iaW5hcnlfdXBncmFk ZV9zZXRfbmV4dF9wZ190eXBlX29pZCgnMTg0NzEnOjpwZ19jYXRhbG9nLm9p ZCk7DQoNCg0KLS0gRm9yIGJpbmFyeSB1cGdyYWRlLCBtdXN0IHByZXNlcnZl IHBnX3R5cGUgYXJyYXkgb2lkDQpTRUxFQ1QKcGdfY2F0YWxvZy5iaW5hcnlf dXBncmFkZV9zZXRfbmV4dF9hcnJheV9wZ190eXBlX29pZCgnNjgzNTI0Jzo6 cGdfY2F0YWxvZy5vaWQpOw0KDQpDUkVBVEUgVFlQRSAiZ2hzdG9yZSIgKA0K ICAgIElOVEVSTkFMTEVOR1RIID0gdmFyaWFibGUsDQogICAgSU5QVVQgPSAi Z2hzdG9yZV9pbiIsDQogICAgT1VUUFVUID0gImdoc3RvcmVfb3V0IiwNCiAg ICBBTElHTk1FTlQgPSBpbnQ0LA0KICAgIFNUT1JBR0UgPSBwbGFpbg0KKTsN Cg0KLS0gRm9yIGJpbmFyeSB1cGdyYWRlLCBoYW5kbGUgZXh0ZW5zaW9uIG1l bWJlcnNoaXAgdGhlIGhhcmQgd2F5DQpBTFRFUiBFWFRFTlNJT04gImhzdG9y ZSIgQUREIFRZUEUgImdoc3RvcmUiOw0KDQoNCkFMVEVSIFRZUEUgZ2hzdG9y ZSBPV05FUiBUTyBkYmFkbWluOw0KDQotLQ0KLS0gTmFtZTogaHN0b3JlOyBU eXBlOiBTSEVMTCBUWVBFOyBTY2hlbWE6IHBnX2NhdGFsb2c7IE93bmVyOiBk YmFkbWluDQotLQ0KDQoNCi0tIEZvciBiaW5hcnkgdXBncmFkZSwgbXVzdCBw cmVzZXJ2ZSBwZ190eXBlIG9pZA0KU0VMRUNUCnBnX2NhdGFsb2cuYmluYXJ5 X3VwZ3JhZGVfc2V0X25leHRfcGdfdHlwZV9vaWQoJzY4MzUyMSc6OnBnX2Nh dGFsb2cub2lkKTsNCg0KDQotLSBGb3IgYmluYXJ5IHVwZ3JhZGUsIG11c3Qg cHJlc2VydmUgcGdfdHlwZSBhcnJheSBvaWQNClNFTEVDVApwZ19jYXRhbG9n LmJpbmFyeV91cGdyYWRlX3NldF9uZXh0X2FycmF5X3BnX3R5cGVfb2lkKCc2 ODM0NDUnOjpwZ19jYXRhbG9nLm9pZCk7DQoNCkNSRUFURSBUWVBFICJoc3Rv cmUiOw0KDQoNCi0tDQotLSBOYW1lOiBoc3RvcmVfaW4oImNzdHJpbmciKTsg VHlwZTogRlVOQ1RJT047IFNjaGVtYTogcGdfY2F0YWxvZzsgT3duZXI6CmRi YWRtaW4NCi0tDQoNCkNSRUFURSBGVU5DVElPTiAiaHN0b3JlX2luIigiY3N0 cmluZyIpIFJFVFVSTlMgImhzdG9yZSINCiAgICBMQU5HVUFHRSAiYyIgSU1N VVRBQkxFIFNUUklDVA0KICAgIEFTICckbGliZGlyL2hzdG9yZScsICdoc3Rv cmVfaW4nOw0KDQotLSBGb3IgYmluYXJ5IHVwZ3JhZGUsIGhhbmRsZSBleHRl bnNpb24gbWVtYmVyc2hpcCB0aGUgaGFyZCB3YXkNCkFMVEVSIEVYVEVOU0lP TiAiaHN0b3JlIiBBREQgRlVOQ1RJT04gImhzdG9yZV9pbiIoImNzdHJpbmci KTsNCg0KWy4uLl0NCg0KQ1JFQVRFIFRZUEUgImhzdG9yZSIgKA0KICAgIElO VEVSTkFMTEVOR1RIID0gdmFyaWFibGUsDQogICAgSU5QVVQgPSAiaHN0b3Jl X2luIiwNCiAgICBPVVRQVVQgPSAiaHN0b3JlX291dCIsDQogICAgUkVDRUlW RSA9ICJoc3RvcmVfcmVjdiIsDQogICAgU0VORCA9ICJoc3RvcmVfc2VuZCIs DQogICAgQUxJR05NRU5UID0gaW50NCwNCiAgICBTVE9SQUdFID0gZXh0ZW5k ZWQNCik7DQoNCi0tIEZvciBiaW5hcnkgdXBncmFkZSwgaGFuZGxlIGV4dGVu c2lvbiBtZW1iZXJzaGlwIHRoZSBoYXJkIHdheQ0KQUxURVIgRVhURU5TSU9O ICJoc3RvcmUiIEFERCBUWVBFICJoc3RvcmUiOw0KDQoNCkFMVEVSIFRZUEUg aHN0b3JlIE9XTkVSIFRPIGRiYWRtaW47DQoNClsuLi5dDQoNCkFMVEVSIE9Q RVJBVE9SICJwZ19jYXRhbG9nIi5+ICgiaHN0b3JlIiwgImhzdG9yZSIpIE9X TkVSIFRPIGRiYWRtaW47DQoNCi0tDQotLSBOYW1lOiBidHJlZV9oc3RvcmVf b3BzOyBUeXBlOiBPUEVSQVRPUiBDTEFTUzsgU2NoZW1hOiBwZ19jYXRhbG9n OyBPd25lcjoKZGJhZG1pbg0KLS0NCg0KQ1JFQVRFIE9QRVJBVE9SIENMQVNT ICJidHJlZV9oc3RvcmVfb3BzIg0KICAgIERFRkFVTFQgRk9SIFRZUEUgImhz dG9yZSIgVVNJTkcgImJ0cmVlIiBGQU1JTFkgImJ0cmVlX2hzdG9yZV9vcHMi IEFTDQogICAgT1BFUkFUT1IgMSAjPCMoImhzdG9yZSIsImhzdG9yZSIpICwN CiAgICBPUEVSQVRPUiAyICM8PSMoImhzdG9yZSIsImhzdG9yZSIpICwNCiAg ICBPUEVSQVRPUiAzID0oImhzdG9yZSIsImhzdG9yZSIpICwNCiAgICBPUEVS QVRPUiA0ICM+PSMoImhzdG9yZSIsImhzdG9yZSIpICwNCiAgICBPUEVSQVRP UiA1ICM+IygiaHN0b3JlIiwiaHN0b3JlIikgLA0KICAgIEZVTkNUSU9OIDEg KCJoc3RvcmUiLCAiaHN0b3JlIikgImhzdG9yZV9jbXAiKCJoc3RvcmUiLCJo c3RvcmUiKTsNCg0KLS0gRm9yIGJpbmFyeSB1cGdyYWRlLCBoYW5kbGUgZXh0 ZW5zaW9uIG1lbWJlcnNoaXAgdGhlIGhhcmQgd2F5DQpBTFRFUiBFWFRFTlNJ T04gImhzdG9yZSIgQUREIE9QRVJBVE9SIENMQVNTICJidHJlZV9oc3RvcmVf b3BzIiBVU0lORwoiYnRyZWUiOw0KDQoNCkFMVEVSIE9QRVJBVE9SIENMQVNT ICJwZ19jYXRhbG9nIi4iYnRyZWVfaHN0b3JlX29wcyIgVVNJTkcgImJ0cmVl IiBPV05FUiBUTwpkYmFkbWluOw0KDQpbLi4uXQ0KDQo8Lz09PT09PT0gZXhj ZXJwdCA9PT09PT09PT0+DQoKCg==
worden.eric@gmail.com writes:
> I'm attempting to upgrade from 9.4.8. hstore installed version on the 9.4
> cluster is 1.3. It also failed with version 1.2.
> pg_upgrade is exiting with failure during the step "Restoring database
> schemas in the new cluster". Several database schemas are restored
> successfully, then one fails. The pg_restore log indicated by the pg_upgrade
> output ends with:
> pg_restore: [archiver (db)] could not execute query: ERROR: operator family
> "btree_hstore_ops" does not exist for access method "btree"
> Command was: CREATE OPERATOR CLASS "btree_hstore_ops"
> DEFAULT FOR TYPE "hstore" USING "btree" FAMILY "btree_hstore_ops" AS
> OPERAT...
Hmm. Is there, by any chance, a CREATE OPERATOR FAMILY "btree_hstore_ops"
command somewhere later in the dump? Also, if you do
\dx+ hstore
in the problematic 9.4 database, do you see lines like
operator family btree_hstore_ops for access method btree
operator family gin_hstore_ops for access method gin
operator family gist_hstore_ops for access method gist
operator family hash_hstore_ops for access method hash
? I'm suspicious that there may only be operator classes, not operator
families, linked to the extension.
If you don't see them, then I'm betting that you previously pg_upgraded
this same database from 9.3 or before, and fell victim to a bug we
recently fixed that caused pg_upgrade to drop such operator families
from their extensions. You could fix that with manual ALTER EXTENSION
ADD OPERATOR FAMILY commands in affected database(s). After that,
pg_upgrade'ing should work.
> The documentation for CREATE OPERATOR CLASS says that the operator family
> will be created if it does not already exist, contrary to what the error
> message says here.
Not if there's an explicit FAMILY clause; that's supposed to refer to
a pre-existing family.
regards, tom lane
On Tue, Jun 7, 2016 at 3:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: Thank you, your diagnosis was correct! The upgrade completed successfully. I've added replies to your questions below, with a new question about a possible bug. worden.eric@gmail.com writes: > > I'm attempting to upgrade from 9.4.8. hstore installed version on the 9.4 > > cluster is 1.3. It also failed with version 1.2. > > > pg_upgrade is exiting with failure during the step "Restoring database > > schemas in the new cluster". Several database schemas are restored > > successfully, then one fails. The pg_restore log indicated by the > pg_upgrade > > output ends with: > > > pg_restore: [archiver (db)] could not execute query: ERROR: operator > family > > "btree_hstore_ops" does not exist for access method "btree" > > Command was: CREATE OPERATOR CLASS "btree_hstore_ops" > > DEFAULT FOR TYPE "hstore" USING "btree" FAMILY "btree_hstore_ops" AS > > OPERAT... > > Hmm. Is there, by any chance, a CREATE OPERATOR FAMILY "btree_hstore_ops" > command somewhere later in the dump? No there wasn't. However I believe your diagnosis below was correct (I don't know the history of this system). I did CREATE OPERATOR FAMILY, followed by ALTER EXTENSION ADD OPERATOR FAMILY. > Also, if you do > \dx+ hstore > in the problematic 9.4 database, do you see lines like > operator family btree_hstore_ops for access method btree > operator family gin_hstore_ops for access method gin > operator family gist_hstore_ops for access method gist > operator family hash_hstore_ops for access method hash > No I did not. Now in the upgraded system I do see those. However, before upgrade in the 9.4 cluster I created an empty test database and did CREATE EXTENSION hstore. In the test database \dx+ hstore does not list the lines above in the 9.4 or 9.5 system. Is this a problem? > ? I'm suspicious that there may only be operator classes, not operator > families, linked to the extension. > > If you don't see them, then I'm betting that you previously pg_upgraded > this same database from 9.3 or before, and fell victim to a bug we > recently fixed that caused pg_upgrade to drop such operator families > from their extensions. You could fix that with manual ALTER EXTENSION > ADD OPERATOR FAMILY commands in affected database(s). After that, > pg_upgrade'ing should work. > > It did work, thank you. Eric
Eric Worden <worden.eric@gmail.com> writes:
> On Tue, Jun 7, 2016 at 3:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmm. Is there, by any chance, a CREATE OPERATOR FAMILY "btree_hstore_ops"
>> command somewhere later in the dump?
> No there wasn't. However I believe your diagnosis below was correct (I
> don't know the history of this system). I did CREATE OPERATOR FAMILY,
> followed by ALTER EXTENSION
> ADD OPERATOR FAMILY.
[ squint ... ] This seems quite wrong. It is not possible to have an
operator class that's not part of an operator family, or at least I hope
not, so there should definitely have been an opfamily present even if
it was not marked as belonging to the extension. I wonder if you don't
now have *two* operator families, presumably within different schemas.
>> Also, if you do
>> \dx+ hstore
>> in the problematic 9.4 database, do you see lines like
>> operator family btree_hstore_ops for access method btree
>> operator family gin_hstore_ops for access method gin
>> operator family gist_hstore_ops for access method gist
>> operator family hash_hstore_ops for access method hash
> No I did not. Now in the upgraded system I do see those. However, before
> upgrade in the 9.4 cluster I created an empty test database and did CREATE
> EXTENSION hstore. In the test database \dx+ hstore does not list the lines
> above in the 9.4 or 9.5 system. Is this a problem?
That makes no sense at all. I definitely do see this in 9.4 after
creating hstore 1.3:
regression=# \dx+ hstore
...
operator class btree_hstore_ops for access method btree
operator class gin_hstore_ops for access method gin
operator class gist_hstore_ops for access method gist
operator class hash_hstore_ops for access method hash
operator family btree_hstore_ops for access method btree
operator family gin_hstore_ops for access method gin
operator family gist_hstore_ops for access method gist
operator family hash_hstore_ops for access method hash
...
And, again, it does not look like it's possible to have an opclass
without a containing opfamily --- if CREATE OPERATOR CLASS does not
find a family to link to, it will make one. So there should be
an entry by that name, even if it somehow doesn't get attached to the
extension. It might be interesting to do
select oid,* from pg_opfamily where opfname like '%hstore%';
select oid,* from pg_opclass where opcname like '%hstore%';
and see what you get.
regards, tom lane
Re: Fwd: BUG #14181: pg_upgrade: operator family "btree_hstore_ops" does not exist
От
Eric Worden
Дата:
Thank you again. Some further feedback and a final (?) solution below. On Wed, Jun 8, 2016 at 3:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Eric Worden <worden.eric@gmail.com> writes: > > On Tue, Jun 7, 2016 at 3:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Hmm. Is there, by any chance, a CREATE OPERATOR FAMILY > "btree_hstore_ops" > >> command somewhere later in the dump? > > > No there wasn't. However I believe your diagnosis below was correct (I > > don't know the history of this system). I did CREATE OPERATOR FAMILY, > > followed by ALTER EXTENSION > > ADD OPERATOR FAMILY. > > [ squint ... ] This seems quite wrong. It is not possible to have an > operator class that's not part of an operator family, or at least I hope > not, so there should definitely have been an opfamily present even if > it was not marked as belonging to the extension. I wonder if you don't > now have *two* operator families, presumably within different schemas. > > Indeed I did have two operator families. I think I made an error in my first scanning of the dump file sql. > >> Also, if you do > >> \dx+ hstore > >> in the problematic 9.4 database, do you see lines like > >> operator family btree_hstore_ops for access method btree > >> operator family gin_hstore_ops for access method gin > >> operator family gist_hstore_ops for access method gist > >> operator family hash_hstore_ops for access method hash > > > No I did not. Now in the upgraded system I do see those. However, > before > > upgrade in the 9.4 cluster I created an empty test database and did > CREATE > > EXTENSION hstore. In the test database \dx+ hstore does not list the > lines > > above in the 9.4 or 9.5 system. Is this a problem? > > That makes no sense at all. I definitely do see this in 9.4 after > creating hstore 1.3: > > This was due to template1 having the same buggy condition. > > It might be interesting to do > select oid,* from pg_opfamily where opfname like '%hstore%'; > select oid,* from pg_opclass where opcname like '%hstore%'; > and see what you get. > > The sql above revealed that I had two sets of operator families after my attempted fix. I started over, this time only issuing ALTER EXTENSION ADD OPERATOR FAMILY in each affected database. The result was that everything matched a virgin cluster and database having the hstore extension. I think this is resolved now. Thank you for your help. Eric