On Mon, Dec 18, 2017 at 03:36:18PM +0000, PG Bug reporting form wrote:
> Errors appearing in logs:
> 1) src/bin/pgbench/tmp_check/log/001_pgbench_main.log :
> 2017-12-18 16:07:39.268 CET [12976136] t/001_pgbench.pl LOG: execute
> P0_0: INSERT INTO oid_tbl SELECT FROM generate_series(1,1000);
> 2017-12-18 16:07:39.268 CET [13041676] t/001_pgbench.pl ERROR: duplicate
> key value violates unique constraint "oid_tbl_oid_key"
> 2017-12-18 16:07:39.268 CET [13041676] t/001_pgbench.pl DETAIL: Key
> (oid)=(100291) already exists.
> 2017-12-18 16:07:39.268 CET [13041676] t/001_pgbench.pl STATEMENT:
> INSERT INTO oid_tbl SELECT FROM generate_series(1,1000);
> 2017-12-18 16:07:39.285 CET [12386468] t/001_pgbench.pl LOG: execute
> P0_0: INSERT INTO oid_tbl SELECT FROM generate_series(1,1000);
This comes from 001_pgbench.pl, which aims at testing LWLock and
spinlock concurrency. This visibly points to something going wrong with
what happens on AIX for XLC 13. The buildfarm has a couple of animals
owned by Noah though those are using XLC 12. My gut feeling is that if
you stress enough a Postgres instance in one run you should get a high
reproducibility rate. Could you test manually something close to what
the TAP test does?
1) Create a PG instance and initialize it with this schema:
CREATE UNLOGGED TABLE oid_tbl () WITH OIDS;
ALTER TABLE oid_tbl ADD UNIQUE (oid);
2) Create a pgbench script with this query:
INSERT INTO oid_tbl SELECT FROM generate_series(1,1000);
3) Run pgbench with --protocol=prepared, but with a high number of
clients in priority, a longer time, or a higher number of transactions.
If you are looking for better support on this platform with this
compiler combination, I would highly recommend setting up a buildfarm
animal. This would allow for faster bug fixes and detection of
problems.
--
Michael