[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Strange issue with log insertion into wanna-build database using wbpy.



On Wed, Jun 12, 2013 at 10:47:00PM +0100, peter green wrote:
> Roger Leigh wrote:
> >I'm not sure where the citext stuff is coming from, and I haven't
> >come across the issue in the stackexchange link before either.
> >
> >The postgresql-debversion extension will work just fine on
> >PostgreSQL 8.4, 9.0, 9.1 and 9.2 (and 9.3 beta).  So long as
> >you see
> >
> >  # \dT
> >                   List of data types
> >   Schema │    Name    │          Description
> >  ────────┼────────────┼───────────────────────────────
> >   public │ debversion │ Debian package version number
> >  (1 row)
> >
> >then it's available and (hopefully!) working.  The manual installation
> >of the debversion type will work with all versions of PostgreSQL; the
> >CREATE EXTENSION mechanism is preferred for newer versions, but has no
> >meaningful difference other than convenience and tidiness.
> >
> >One thing you might well need to do is set the table columns from the
> >text to debversion type.  You could do this using
> >
> >  ALTER TABLE t ALTER COLUMN c SET DATA TYPE debversion;
> >
> >for each column which needs to be using debversion.  This does
> >require the column to be in a text format in order to do the
> >conversion (or equivalent e.g. varchar).
> Thanks for the hint, changing the column type from debversion to
> varchar and back to debversion appears to have fixed things (at
> least I was able to get a log that failed to inject before to inject
> succesfully, lets hope this fix works in general). I had to delete
> some views before postgres would let me mess with the column type
> (and recreate them after) which was a bit of a pain but not too big
> a deal.

That's good to know, because this was just a guess!  You might also
potentially want to recreate any indexes on those columns as well
to ensure that you're using the debversion index operators (it's
possible this happens automatically--I'm not entirely certain of
the postgres internal behaviour here).

Do you know what triggered this condition?  I've never seen this
type of behaviour before, so it would be good to know what the
cause was for the future.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


Reply to: