Thread: [HACKERS] parallel worker (PID ) exited with exit code 1
Hi, I got some few queries after running sqlsmith against PG HEAD , where i am getting LOG message like - "parallel worker (PID) exited with exit code 1" set force_parallel_mode =1; select pg_catalog.pg_wal_replay_pause() as c0, ref_0.ev_type as c1 from pg_catalog.pg_rewrite as ref_0 where ref_0.ev_enabled > ref_0.ev_type limit 53; 2017-10-06 13:15:34.785 BST [5680] LOG: background worker "parallel worker" (PID 5964) exited with exit code 1 ERROR: recovery is not in progress HINT: Recovery control functions can only be executed during recovery. CONTEXT: parallel worker -- regards,tushar EnterpriseDB https://www.enterprisedb.com/ The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Oct 6, 2017 at 9:19 PM, tushar <tushar.ahuja@enterprisedb.com> wrote: > 2017-10-06 13:15:34.785 BST [5680] LOG: background worker "parallel worker" > (PID 5964) exited with exit code 1 > ERROR: recovery is not in progress > HINT: Recovery control functions can only be executed during recovery. > CONTEXT: parallel worker pg_wal_replay_pause() is a function marked as PARALLEL SAFE, meaning that it can be pushed down to parallel workers. Still, it can only be executed on standbys, so this would correctly fail with the error you are seeing here on a primary server. 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. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Am Freitag, den 06.10.2017, 17:49 +0530 schrieb tushar: > I got some few queries after running sqlsmith against PG HEAD , where > i > am getting LOG message like - "parallel worker (PID) exited with > exit > code 1" > > set force_parallel_mode =1; > select > pg_catalog.pg_wal_replay_pause() as c0, > ref_0.ev_type as c1 > from > pg_catalog.pg_rewrite as ref_0 > where ref_0.ev_enabled > ref_0.ev_type > limit 53; Looks like pg_wal_replay_pause() is marked as parallel safe: SELECT proparallel FROM pg_proc WHERE proname = 'pg_wal_replay_pause'; -[ RECORD 1 ]-- proparallel | s Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Oct 6, 2017 at 8:19 AM, tushar <tushar.ahuja@enterprisedb.com> wrote: > I got some few queries after running sqlsmith against PG HEAD , where i am > getting LOG message like - "parallel worker (PID) exited with exit code 1" > > set force_parallel_mode =1; > select > pg_catalog.pg_wal_replay_pause() as c0, > ref_0.ev_type as c1 > from > pg_catalog.pg_rewrite as ref_0 > where ref_0.ev_enabled > ref_0.ev_type > limit 53; > > 2017-10-06 13:15:34.785 BST [5680] LOG: background worker "parallel worker" > (PID 5964) exited with exit code 1 > ERROR: recovery is not in progress > HINT: Recovery control functions can only be executed during recovery. > CONTEXT: parallel worker You seem to be assuming this is wrong, but I don't see what the problem is. There's nothing unsafe about an error happening side of a worker, and you got an error because this function isn't safe to execute during normal running. I would say this is a case of everything working as intended. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier writes: > On Fri, Oct 6, 2017 at 9:19 PM, tushar <tushar.ahuja@enterprisedb.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers