Re: [HACKERS] More on the libxml2 update situation
Noah Misch writes: > On Fri, Dec 11, 2015 at 10:55:40AM -0500, Tom Lane wrote: >> I'm starting to think that maybe we'd better knuckle under and provide >> a variant expected file that matches this behavior. We're likely to be >> seeing it in the wild for some time to come. > I would look at handling this by suppressing the exact error message from the > output. I had actually thought a little bit about whether we could put back the missing output, along the lines of "if it's a syntax-type error and no error cursor was supplied, assume we should put a cursor at end of input". It might be worth pursuing if Veillard indicates an unwillingness to change libxml2 going forward, because a syntax error with no location can be pretty unfriendly. But I'll wait to see some response from him before expending a lot of energy here. > A variant expected output would be okay, though. I pushed a set of those an hour ago. I hope it's just a short-term hack, but we'll see. In any case there were now two buildfarm critters failing, reinforcing the idea that this behavior is spreading. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] More on the libxml2 update situation
On Fri, Dec 11, 2015 at 10:55:40AM -0500, Tom Lane wrote: > So I did a routine software update on my RHEL6 workstation, and noticed > a security update for libxml2 go by. And guess what: now an XML-enabled > build of Postgres fails regression tests for me, just as previously > discussed in > http://www.postgresql.org/message-id/flat/cafj8pra4xjqfgnqcqmcygx-umgmr3stt3xfeuw7kbsoiovg...@mail.gmail.com > > A little bit of digging shows that the behavior we're unhappy about was > introduced as part of the official patch for CVE-2015-7499. This means > that, whether or not we can persuade Veillard that it was a bad idea and > he should undo it, the bogus behavior is likely to spread into mainstream > distributions a lot faster than any followup fix will :-(. Bugfix updates > just don't get accepted as quickly as security updates. That settles PostgreSQL's need to accept this variation. > I'm starting to think that maybe we'd better knuckle under and provide > a variant expected file that matches this behavior. We're likely to be > seeing it in the wild for some time to come. I would look at handling this by suppressing the exact error message from the output. Route affected tests through a wrapper function: SELECT expect_errdetail($$INSERT INTO xmltest VALUES (3, 'http://www.postgresql.org/mailpref/pgsql-hackers