Re: WIP: WAL prefetch (another approach) - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: WIP: WAL prefetch (another approach)
Date
Msg-id 2cdffbfc-9e9b-c1e4-91e4-92b6baa80fe7@enterprisedb.com
Whole thread Raw
In response to Re: WIP: WAL prefetch (another approach)  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On 12/17/21 23:56, Greg Stark wrote:
> Hm. I seem to have picked a bad checkout. I took the last one before
> the revert (45aa88fe1d4028ea50ba7d26d390223b6ef78acc). Or there's some
> incompatibility with the emulation and the IPC stuff parallel workers
> use.
> 
> 
> 2021-12-17 17:51:51.688 EST [50955] LOG:  background worker "parallel
> worker" (PID 54073) was terminated by signal 10: Bus error
> 2021-12-17 17:51:51.688 EST [50955] DETAIL:  Failed process was
> running: SELECT variance(unique1::int4), sum(unique1::int8),
> regr_count(unique1::float8, unique1::float8)
> FROM (SELECT * FROM tenk1
>        UNION ALL SELECT * FROM tenk1
>        UNION ALL SELECT * FROM tenk1
>        UNION ALL SELECT * FROM tenk1) u;
> 2021-12-17 17:51:51.690 EST [50955] LOG:  terminating any other active
> server processes
> 2021-12-17 17:51:51.748 EST [54078] FATAL:  the database system is in
> recovery mode
> 2021-12-17 17:51:51.761 EST [50955] LOG:  all server processes
> terminated; reinitializing
> 

Interesting. In my experience SIGBUS on PPC tends to be due to incorrect 
alignment, but I'm not sure how that works with the emulation. Can you 
get a backtrace?

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: WIP: WAL prefetch (another approach)
Next
From: Peter Smith
Date:
Subject: Re: row filtering for logical replication