Re: parallel worker (PID ) exited with exit code 1

From: Andreas Seltenreich <seltenreich(at)gmx(dot)de>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: parallel worker (PID ) exited with exit code 1
Date: 2017-10-07 10:00:00
Message-ID: 87shev2s7z.fsf@ansel.ydns.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier writes:

> On Fri, Oct 6, 2017 at 9:19 PM, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com> wrote:
>> ERROR: recovery is not in progress
>
> Perhaps there is a way to blacklist some functions depending on the
> server context. This question may be better asked directly where the
> project is maintained then: https://github.com/anse1/sqlsmith. I am
> adding as well Andreas in CC, he works on sqlsmith.

Blacklisting when testing with sqlsmith typically happens on the error
logging side: Logging into a database via --log-to with the schema
shipped with sqlsmith filters out boring error messages with triggers.
The ERROR reported is actually in the filter tables that ship with
sqlsmith.

I don't think adding such product-specific filtering on the generating
side is necessarily the right thing, as it would reduces code coverage
while testing. We might miss a core dump when something becomes buggy
in that path.

I did make an exception for syntax errors: sqlsmith notices when grammar
productions consistently lead to errors. This feature was added to allow
testing other products or older postgres, so sqlsmith doesn't waste time
generating upsert statements on 9.1. It's more apparent when testing
sqlite3: The error rate is 90% on startup, but shrinks to 2% or so after
a couple thousand statements have been generated.

regards,
Andreas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2017-10-07 11:26:59 Predicate Locks for writes?
Previous Message Alvaro Herrera 2017-10-07 08:35:03 Re: On markers of changed data