Re: Libxml2 load error on Windows

Hi,

PostgreSQL 9.2 Windows build is having trouble with the XML support:
http://postgresql.1045698.n5.nabble.com/9-2-beta1-libxml2-can-t-be-loaded-on-Windows-td5710672.html

postgres=# SELECT xml '<foo>bar</foo>';
ERROR: could not set up XML error handler
HINT: This probably indicates that the version of libxml2 being used is not
compatible with the libxml2 header files that PostgreSQL was built with.

HAVE_XMLSTRUCTUREDERRORCONTEXT should be defined if libxml2 has
xmlStructuredErrorContext
(introduced after 2.7.3). It is being set for Linux in pg_config.h:

/* Define to 1 if your libxml has xmlStructuredErrorContext. */
#define HAVE_XMLSTRUCTUREDERRORCONTEXT 1

For Windows build, we need to set it in "src/tools/msvc/Solution.pm".

I guess there are two approaches to get the libxml2 version:

1) Parse "LIBXML_INST/include/libxml/xmlversion.h" to get the libxml2 version
number, this header file is included in libxml2.

2) We may also get the version by running a command line utility i.e
"LIBXML_INST/bin/xmllint
--version". The xmllint program parses one or more XML files and it is also
included in libxml2.

I believe it is safe to assume that libxml2 include folder would contain
xmlversion.h file containing the required version number. It might be a
touch slower to parse the file line by line, but similar functionality has
been used elsewhere as well. We obviously rely on xml include files (with
xml enabled), so there is definitely a tighter dependency on include files
than xmllint executable as it is not mandatory for build process.

Therefore, I used first approach to get libxml2 version number and include
the "#define HAVE_XMLSTRUCTUREDERRORCONTEXT" in pg_config.h if libxml2 version
is greater than 20703 (which effectively is 2.7.3). Please find attached
patch "libxml2_win_v1.patch".

Regards,
Talha Bin Rizwan

On Mon, Jun 18, 2012 at 5:08 AM, Talha Bin Rizwan
<talha(dot)rizwan(at)gmail(dot)com> wrote:
> PostgreSQL 9.2 Windows build is having trouble with the XML support:
> http://postgresql.1045698.n5.nabble.com/9-2-beta1-libxml2-can-t-be-loaded-on-Windows-td5710672.html
>
> postgres=# SELECT xml '<foo>bar</foo>';
> ERROR:  could not set up XML error handler
> HINT: This probably indicates that the version of libxml2 being used is not
> compatible with the libxml2 header files that PostgreSQL was built with.
>
> HAVE_XMLSTRUCTUREDERRORCONTEXT should be defined if libxml2
> has xmlStructuredErrorContext (introduced after 2.7.3). It is being set for
> Linux in pg_config.h:
>
> /* Define to 1 if your libxml has xmlStructuredErrorContext. */
> #define HAVE_XMLSTRUCTUREDERRORCONTEXT 1
>
> For Windows build, we need to set it in "src/tools/msvc/Solution.pm".
>
> I guess there are two approaches to get the libxml2 version:
>
> 1) Parse "LIBXML_INST/include/libxml/xmlversion.h" to get the
> libxml2 version number, this header file is included in libxml2.
>
> 2) We may also get the version by running a command line utility
> i.e "LIBXML_INST/bin/xmllint --version". The xmllint program parses one
> or more XML files and it is also included in libxml2.
>
> I believe it is safe to assume that libxml2 include folder would contain
> xmlversion.h file containing the required version number. It might be a
> touch slower to parse the file line by line, but similar functionality has
> been used elsewhere as well. We obviously rely on xml include files (with
> xml enabled), so there is definitely a tighter dependency on include files
> than xmllint executable as it is not mandatory for build process.
>
> Therefore, I used first approach to get libxml2 version number and include
> the "#define HAVE_XMLSTRUCTUREDERRORCONTEXT" in pg_config.h if
> libxml2 version is greater than 20703 (which effectively is 2.7.3). Please
> find attached patch "libxml2_win_v1.patch".

Please add this patch here so that it doesn't get lost in the shuffle:

https://commitfest.postgresql.org/action/commitfest_view/open

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, Jun 19, 2012 at 4:43 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>
> Please add this patch here so that it doesn't get lost in the shuffle:
>
> https://commitfest.postgresql.org/action/commitfest_view/open

Hmm, that raises an interesting question (though maybe I've just
missed this happening in the past). This is a bug fix, that we'll want
in the next back branch updates, not just 9.3. Sticking it in the open
commit fest means it may well not get looked at for 2-3 months or so.
How do we prevent that happening?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Dave Page <dpage(at)pgadmin(dot)org> writes:

> On Tue, Jun 19, 2012 at 4:43 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>>
>> Please add this patch here so that it doesn't get lost in the shuffle:
>>
>> https://commitfest.postgresql.org/action/commitfest_view/open
>
> Hmm, that raises an interesting question (though maybe I've just
> missed this happening in the past). This is a bug fix, that we'll want
> in the next back branch updates, not just 9.3. Sticking it in the open
> commit fest means it may well not get looked at for 2-3 months or so.
> How do we prevent that happening?

In a real bug-tracking system we would create a new bug/ticket and set
it's target version to 'candidate for next minor release' or something
like that. This way, if we don't release unless all targeted bugs are
resolved, this would be taken care of (hopefully.)

On Tue, Jun 19, 2012 at 11:04 AM, Alex Shulgin <ash(at)commandprompt(dot)com> wrote:
>
> Dave Page <dpage(at)pgadmin(dot)org> writes:
>
>> On Tue, Jun 19, 2012 at 4:43 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>
>>>
>>> Please add this patch here so that it doesn't get lost in the shuffle:
>>>
>>> https://commitfest.postgresql.org/action/commitfest_view/open
>>
>> Hmm, that raises an interesting question (though maybe I've just
>> missed this happening in the past). This is a bug fix, that we'll want
>> in the next back branch updates, not just 9.3. Sticking it in the open
>> commit fest means it may well not get looked at for 2-3 months or so.
>> How do we prevent that happening?
>
> In a real bug-tracking system we would create a new bug/ticket and set
> it's target version to 'candidate for next minor release' or something
> like that.  This way, if we don't release unless all targeted bugs are
> resolved, this would be taken care of (hopefully.)

Well yes, but the point is that that is not how the project works. I'm
asking how we do handle this problem at the moment, because I realised
I haven't seen this happen in the past (largely because I haven't been
paying attention).

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Dave Page <dpage(at)pgadmin(dot)org> writes:

> On Tue, Jun 19, 2012 at 11:04 AM, Alex Shulgin <ash(at)commandprompt(dot)com> wrote:
>>
>> In a real bug-tracking system we would create a new bug/ticket and set
>> it's target version to 'candidate for next minor release' or something
>> like that.  This way, if we don't release unless all targeted bugs are
>> resolved, this would be taken care of (hopefully.)
>
> Well yes, but the point is that that is not how the project works. I'm
> asking how we do handle this problem at the moment, because I realised
> I haven't seen this happen in the past (largely because I haven't been
> paying attention).

It only works as long as there is some mechanism to ensure that the bugs
which were not submitted to commitfest are looked at. If there is no,
then it doesn't work actually.

So is there a real and reliable mechanism for that?

--
Alex

On Tue, Jun 19, 2012 at 6:36 AM, Alex Shulgin <ash(at)commandprompt(dot)com> wrote:
> Dave Page <dpage(at)pgadmin(dot)org> writes:
>> On Tue, Jun 19, 2012 at 11:04 AM, Alex Shulgin <ash(at)commandprompt(dot)com> wrote:
>>>
>>> In a real bug-tracking system we would create a new bug/ticket and set
>>> it's target version to 'candidate for next minor release' or something
>>> like that.  This way, if we don't release unless all targeted bugs are
>>> resolved, this would be taken care of (hopefully.)
>>
>> Well yes, but the point is that that is not how the project works. I'm
>> asking how we do handle this problem at the moment, because I realised
>> I haven't seen this happen in the past (largely because I haven't been
>> paying attention).
>
> It only works as long as there is some mechanism to ensure that the bugs
> which were not submitted to commitfest are looked at.  If there is no,
> then it doesn't work actually.
>
> So is there a real and reliable mechanism for that?

No.

There probably should be, but in the meantime adding it to the
CommitFest is better than a poke in the eye with a sharp stick.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jun 18, 2012 at 02:08:29PM +0500, Talha Bin Rizwan wrote:
> PostgreSQL 9.2 Windows build is having trouble with the XML support:
> http://postgresql.1045698.n5.nabble.com/9-2-beta1-libxml2-can-t-be-loaded-on-Windows-td5710672.html

> Therefore, I used first approach to get libxml2 version number and include
> the "#define HAVE_XMLSTRUCTUREDERRORCONTEXT" in pg_config.h if libxml2 version
> is greater than 20703 (which effectively is 2.7.3). Please find attached
> patch "libxml2_win_v1.patch".

Tom fixed this differently; effectively, we now use a check like you describe
on all platforms, not just Windows:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=470d0b9789981bc91a8ef2654911d80ab6a6be57

Since that commit makes your patch obsolete, I'm marking it Rejected. Even
so, thank you for calling attention to the problem and submitting this fix.

nm