Open larskanis opened 6 years ago
Original comment by Lars Kanis (Bitbucket: larskanis, GitHub: larskanis).
Thank you @eregon for notifying us and for your analysis!
Storing the encoding in the metadata of a T_DATA object was a handy trick to save some space in the connection and the result. However if it's in the way of some future improvements in MRI, I think we can find an alternative solution for it. I'll check this and will make ruby-pg compatible with ruby-trunk.
Regarding TruffleRuby, please let me know when it is ready to be supported by ruby-pg. We already had some Rubinius compatibility in the past for parts that are too MRI specific. -- Kind Regards, Lars
Original comment by Benoit Daloze (Bitbucket: eregon, GitHub: eregon).
Yes. The fix should be:
Original report by Benoit Daloze (Bitbucket: eregon, GitHub: eregon).
pg sets the encoding with ENCODING_SET_INLINED/rb_enc_set_index on PG::Connection objects. Pg uses a macro PG_ENCODING_SET_NOCHECK() in pg.h.
This seems not supported in latest ruby trunk, as Koichi Sasada explicitly added a check against it in https://github.com/ruby/ruby/commit/d0fb73a0f0b82ebc0d3eb931c28686a2b9c40fef , and as a result the program crashes when rb_enc_set_index() is called on a non-encoding capable object.
To observe this, we need to change PG_ENCODING_SET_NOCHECK() to just call rb_enc_set_index() as ENCODING_SET_INLINED() doesn't contain the check currently, but likely has unsupported semantics and only works by luck that there are < 128 encodings.
Then with ruby-trunk we can see (the program assume a postgres db named "test" exists):
I think one solution is to store the encoding in a separate field, for instance in
t_pg_connection
. If you think Ruby should keep supporting rb_enc_set_index() on non-encoding-capable objects, please file an issue at https://bugs.ruby-lang.org/I'm just reporting this as I noticed the change by Koichi and knew from trying to run pg with TruffleRuby that pg uses rb_enc_set_index() on the PG::Connection object.