machines about casts between pointers and integers of different sizes.
While they're harmless, we shouldn't expect users to have to go through
and figure that out for themselves.
trying BIO functions.
Helps problem with older versions of OpenSSL that lacks error
stack functions and would show an incorrect error message for
file-not-found-or-not-openable. The problem may still exist for
other errors, but file open error is by far the most common one.
OpenSSL libraries --- just don't call them if they're not there. This
might possibly lead to misleading error messages, but we'll just have
to live with that.
This fixes potential crashes on old versions of OpenSSL and the requirement on
"Applink" in new versions when building with MSVC and using different
runtimes.
Dave Page with fixes from me.
compiler --- at least on ARM, it does. I suspect that the varvarlena patch
has been creating larger-than-intended toast pointers all along on ARM,
but it wasn't exposed until the latest tweak added some Asserts that
calculated the expected size in a different way. We could probably have
fixed this by adding __attribute__((packed)) as is done for ItemPointerData,
but struct varattrib_pointer isn't really all that useful anyway, so it
seems cleanest to just get rid of it and have only struct varattrib_1b_e.
Per results from buildfarm member quagga.
explicitly. This means a TOAST pointer takes 18 bytes instead of 17 --- still
smaller than in 8.2 --- which seems a good tradeoff to ensure we won't have
painted ourselves into a corner if we want to support multiple types of TOAST
pointer later on. Per discussion with Greg Stark.
while the restore_command does its thing, then 'recovering XXX' while
processing the segment file. These operations are heavyweight enough
that an extra PS display set shouldn't bother anyone.
testing). Combine the formerly independent opclasses for the various
ISN types into opfamilies. The latter causes some extra bleating from
opr_sanity, since the module doesn't provide complete sets of cross-type
operators, but it's still a good idea because it will give the planner
more information to work with. The missing cross-type operators no longer
pose a risk of unexpected planner errors in 8.3, so there's no need to
insist on filling them in (and I gather it wouldn't be very sound
semantically to add them all).
