Re: Solaris testers wanted for strxfrm() behavior - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Solaris testers wanted for strxfrm() behavior
Date
Msg-id 20150701072233.GA806952@tornado.leadboat.com
Whole thread Raw
In response to Re: Solaris testers wanted for strxfrm() behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Solaris testers wanted for strxfrm() behavior
List pgsql-hackers
On Tue, Jun 30, 2015 at 09:45:08AM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Sun, Jun 28, 2015 at 07:00:14PM -0400, Tom Lane wrote:
> >> Another idea would be to make a test during postmaster start to see
> >> if this bug exists, and fail if so.  I'm generally on board with the
> >> thought that we don't need to work on systems with such a bad bug,
> >> but it would be a good thing if the failure was clean and produced
> >> a helpful error message, rather than looking like a Postgres bug.
> 
> > Failing cleanly on unpatched Solaris is adequate, agreed.  A check at
> > postmaster start isn't enough, because the postmaster might run in the C
> > locale while individual databases or collations use problem locales.  The
> > safest thing is to test after every setlocale(LC_COLLATE) and
> > newlocale(LC_COLLATE).  That's once at backend start and once per backend per
> > collation used, more frequent than I would like.  Hmm.
> 
> I was thinking more along the lines of making a single test by momentarily
> switching into a known-buggy locale.

It seems like every Solaris system I meet has a different set of installed
locales.  Any one I might pick could sometimes be unavailable when other buggy
locales are available.

On this Solaris 10 05/08 (10u5) system, the buggy and non-buggy locales have
no clear pattern.  While fr_FR.UTF-8 is fine, fr_LU.UTF-8 is buggy.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: WAL-related tools and .paritial WAL file
Next
From: Michael Paquier
Date:
Subject: Re: pg_rewind failure by file deletion in source server