Обсуждение: BUG #14406: Statement fails after upgrade to 9.6.1

Поиск
Список
Период
Сортировка

BUG #14406: Statement fails after upgrade to 9.6.1

От
boskowski+coreybernal@gmail.com
Дата:
VGhlIGZvbGxvd2luZyBidWcgaGFzIGJlZW4gbG9nZ2VkIG9uIHRoZSB3ZWJz
aXRlOgoKQnVnIHJlZmVyZW5jZTogICAgICAxNDQwNgpMb2dnZWQgYnk6ICAg
ICAgICAgIENvcmV5IEJlcm5hbApFbWFpbCBhZGRyZXNzOiAgICAgIGJvc2tv
d3NraStjb3JleWJlcm5hbEBnbWFpbC5jb20KUG9zdGdyZVNRTCB2ZXJzaW9u
OiA5LjYuMQpPcGVyYXRpbmcgc3lzdGVtOiAgIFVidW50dSAxNi4wNApEZXNj
cmlwdGlvbjogICAgICAgIAoKQWZ0ZXIgdXBncmFkaW5nIGZyb20gOS41LjQg
dG8gOS42LjEgdXNpbmcgcGdfdXBncmFkZSB3aXRoIGxpbmtzIGFuIFVQREFU
RQoocHJlcGFyZWQpIHN0YXRlbWVudCB0aGF0IHByZXZpb3VzbHkgd29ya2Vk
IHN0YXJ0ZWQgcmFpc2luZw0KDQpFUlJPUjogIHRhYmxlIHJvdyB0eXBlIGFu
ZCBxdWVyeS1zcGVjaWZpZWQgcm93IHR5cGUgZG8gbm90IG1hdGNoDQpERVRB
SUw6ICBRdWVyeSBwcm92aWRlcyBhIHZhbHVlIGZvciBhIGRyb3BwZWQgY29s
dW1uIGF0IG9yZGluYWwgcG9zaXRpb24KMTkuDQoNCkkgbWFuYWdlZCB0byBz
b2x2ZSB0aGlzIGJ5IGNyZWF0aW5nIGFuIGlkZW50aWNhbCB0YWJsZSwgcG9w
dWxhdGluZyB3aXRoCklOU0VSVC9TRUxFQ1QgYW5kIHN3YXBwaW5nIHRoZSB0
YWJsZXMgYnkgcmVuYW1pbmcgdGhlbSwgYWxsIGluIG9uZQp0cmFuc2FjdGlv
bi4NCg0KUGxlYXNlIGxldCBtZSBrbm93IHdoYXQgZGV0YWlsIGluZm9ybWF0
aW9uIGNhbiBiZSBoZWxwZnVsIHRvIHlvdS4NCgoK

Re: BUG #14406: Statement fails after upgrade to 9.6.1

От
Tom Lane
Дата:
boskowski+coreybernal@gmail.com writes:
> After upgrading from 9.5.4 to 9.6.1 using pg_upgrade with links an UPDATE
> (prepared) statement that previously worked started raising

> ERROR:  table row type and query-specified row type do not match
> DETAIL:  Query provides a value for a dropped column at ordinal position
> 19.

> I managed to solve this by creating an identical table, populating with
> INSERT/SELECT and swapping the tables by renaming them, all in one
> transaction.

> Please let me know what detail information can be helpful to you.

Without a self-contained test case, we're not going to be able to do much
with this report.  Presumably a test case would look something like
"create a table like this under 9.5; drop some columns in it like this;
pg_upgrade to 9.6; execute this query".  But nobody's going to try to
fill in all those details by guessing.

            regards, tom lane

Re: BUG #14406: Statement fails after upgrade to 9.6.1

От
Robert Lebel
Дата:
I can't really provide useful additional information, but I just had the same
issue. An UPDATE with RETURNING statement was consistently failing after
being called 5 or 6 times. After restarting my app server (which use
postgres jdbc driver), the update query would work again 5-6 times, then
fail.

Recreating the table also made the issue disappear (thanks Corey).  I tried
vacuum etc, without success.




--
View this message in context:
http://postgresql.nabble.com/BUG-14406-Statement-fails-after-upgrade-to-9-6-1-tp5928404p5932143.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.

Re: BUG #14406: Statement fails after upgrade to 9.6.1

От
Bruce Momjian
Дата:
On Sun, Nov 27, 2016 at 12:54:22PM -0700, Robert Lebel wrote:
> I can't really provide useful additional information, but I just had the same
> issue. An UPDATE with RETURNING statement was consistently failing after
> being called 5 or 6 times. After restarting my app server (which use
> postgres jdbc driver), the update query would work again 5-6 times, then
> fail.
>
> Recreating the table also made the issue disappear (thanks Corey).  I tried
> vacuum etc, without success.

It sound like the 5-6 times is related to prepared queries:

    http://momjian.us/main/blogs/pgblog/2016.html#June_15_2016

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +