Kevin Grittner <kgri...@gmail.com> writes: > On Mon, Dec 14, 2015 at 10:06 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> So at this point I'm guessing that Ubuntu has shipped an update that >> includes the patch Pavel Raiskup suggested in >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1286692#c4 >> >> which would fix the lack of error cursors at EOF, but it would not affect >> any larger change such as stopping after the first detected error. >> >> If you can confirm that, then we'll need to decide what to do about it.
> I've been looking at this diff, which seems to represent the ubuntu > libxml2 changes of today, and it seems rather different to what I > see in the Red Hat discussion. In particular, I see no changes to > error.c. I haven't really figured the cause of the discrepancy > yet, but figured I would pass along the diff link. > http://launchpadlibrarian.net/229976362/libxml2_2.9.1%2Bdfsg1-3ubuntu4.5_2.9.1%2Bdfsg1-3ubuntu4.6.diff.gz Hmm. What it looks like is that Ubuntu cherry-picked the libxml2 commit that added xmlHaltParser(), but *not* the follow-on commit that changed the behavior of xmlParserPrintFileContextInternal(). So that would probably explain the behavior you're seeing ... though it also raises the question of whether they've left themselves vulnerable to a null pointer dereference in xmlParserPrintFileContextInternal(). It's not clear to me whether that second commit is properly part of the CVE response or not. But it's Veillard's patch, and he included it in Red Hat's libxml2 security update, so an informed guess would be "yes". Regardless of that, it now seems likely to me that what you're seeing is what the output will look like if the no-error-cursor-at-EOF problem gets fixed, which is what we're hoping will happen. So we had better change the regression tests to accept this behavior too. As I said, my inclination is to remove the SELECT xmlparse(document '') test case altogether. The following test SELECT xmlparse(document ' ') seems like it provides as much useful coverage as we need for that, and its output doesn't depend on whether libxml2 continues parsing after the first error. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers