Re: Optimize Arm64 crc32c implementation in Postgresql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Optimize Arm64 crc32c implementation in Postgresql
Date
Msg-id 22655.1525363264@sss.pgh.pa.us
Whole thread Raw
In response to Re: Optimize Arm64 crc32c implementation in Postgresql  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> I also noticed that we'd been sloppy about making the file safe to
>  Tom> compile for both frontend and backend, so I cleaned that up.

> In a frontend, wouldn't it be more kosher to restore the previous SIGILL
> handler rather than unconditionally reset it to SIG_DFL?

If we had any other code that was setting the SIGILL trap, I might
worry about that, but we don't.

The whole thing is really a bit questionable to run in arbitrary
environments -- for instance, it'd be pretty unsafe inside a threaded
application.  So if we had code in libpq or ecpg that computed CRCs,
I'd be worrying about this approach quite a bit more.  But it seems all
right for current and foreseen uses.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Optimize Arm64 crc32c implementation in Postgresql
Next
From: Vladimir Sitnikov
Date:
Subject: Re: GSoC 2018: thrift encoding format