s...@la-z-boy.com writes:
> java.sql.BatchUpdateException: Batch entry 1 CREATE AGGREGATE md5_agg
> (BYTEA)
> (
> sfunc = dual_md5,
> stype = bytea,
> initcond = '\x00'
> ) was aborted. Call getNextException to see the cause.
>
> 2017-02-16 14:19:54,571 ERROR [p.p.s.migrate] Unravelled exception
> org.postgresql.util.PSQLException: ERROR: invalid byte sequence for
> encoding "UTF8": 0x00
Hmm, I don't yet have a good idea why you're having this trouble, but as
another bit of data, I just tested that function against postgres 9.4
via psql and it worked fine, then against 8.4, and I saw something very
similar:
$ psql -U rlb puppetdb
psql (8.4.21)
Type "help" for help.
puppetdb=# create aggregate md5_agg_foo (bytea) (sfunc = dual_md5, stype = bytea, initcond = '\x00');
WARNING: nonstandard use of escape in a string literal
LINE 1: ...bytea) (sfunc = dual_md5, stype = bytea, initcond = '\x00');
^
HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
ERROR: invalid byte sequence for encoding "UTF8": 0x00
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
But I believe puppetdb should be checking your database version before
we even get to that point via:
https://github.com/puppetlabs/puppetdb/blob/master/src/puppetlabs/puppetdb/scf/storage.clj#L1371
And indeed, when I try to run puppetdb against 8.4, I see this:
* PostgreSQL DB versions older than 9.4 are no longer supported. Please upgrade Postgres and restart PuppetDB.
*
********************
2017-02-17 16:23:09,000 ERROR [async-dispatch-2] [p.p.s.storage] ********************
*
* PostgreSQL DB versions older than 9.4 are no longer supported. Please upgrade Postgres and restart PuppetDB.
*
********************
2017-02-17 16:23:09,007 INFO [Thread-2] [p.t.internal] Shutting down due to JVM shutdown hook.
2017-02-17 16:23:09,011 INFO [Thread-2] [p.t.internal] Beginning shutdown sequence
So it does seem a bit unlikely that puppetdb is talking to a postgres
that's "too old". Out of curiosity, does everything look reasonable
when you run
ps aux | grep postgres
And if you take the PID for the main postgres process, something like:
rlb 19180 1.3 0.5 2305952 82340 pts/5 S+ 16:38 0:00 postgres -h localhost -D data
Then do you see the dir you expect for:
ls -l /proc/19180/cwd
?
Thanks
--
Rob Browning