9e98583898
Set-returning functions that use the Materialize mode, creating a tuplestore to include all the tuples returned in a set rather than doing so in multiple calls, use roughly the same set of steps to prepare ReturnSetInfo for this job: - Check if ReturnSetInfo supports returning a tuplestore and if the materialize mode is enabled. - Create a tuplestore for all the tuples part of the returned set in the per-query memory context, stored in ReturnSetInfo->setResult. - Build a tuple descriptor mostly from get_call_result_type(), then stored in ReturnSetInfo->setDesc. Note that there are some cases where the SRF's tuple descriptor has to be the one specified by the function caller. This refactoring is done so as there are (well, should be) no behavior changes in any of the in-core functions refactored, and the centralized function that checks and sets up the function's ReturnSetInfo can be controlled with a set of bits32 options. Two of them prove to be necessary now: - SRF_SINGLE_USE_EXPECTED to use expectedDesc as tuple descriptor, as expected by the function's caller. - SRF_SINGLE_BLESS to validate the tuple descriptor for the SRF. The same initialization pattern is simplified in 28 places per my count as of src/backend/, shaving up to ~900 lines of code. These mostly come from the removal of the per-query initializations and the sanity checks now grouped in a single location. There are more locations that could be simplified in contrib/, that are left for a follow-up cleanup. |
||
|---|---|---|
| .. | ||
| Makefile | ||
| README.SSL | ||
| auth-sasl.c | ||
| auth-scram.c | ||
| auth.c | ||
| be-fsstubs.c | ||
| be-gssapi-common.c | ||
| be-secure-common.c | ||
| be-secure-gssapi.c | ||
| be-secure-openssl.c | ||
| be-secure.c | ||
| crypt.c | ||
| hba.c | ||
| ifaddr.c | ||
| pg_hba.conf.sample | ||
| pg_ident.conf.sample | ||
| pqcomm.c | ||
| pqformat.c | ||
| pqmq.c | ||
| pqsignal.c | ||
README.SSL
src/backend/libpq/README.SSL
SSL
===
>From the servers perspective:
Receives StartupPacket
|
|
(Is SSL_NEGOTIATE_CODE?) ----------- Normal startup
| No
|
| Yes
|
|
(Server compiled with USE_SSL?) ------- Send 'N'
| No |
| |
| Yes Normal startup
|
|
Send 'S'
|
|
Establish SSL
|
|
Normal startup
>From the clients perspective (v6.6 client _with_ SSL):
Connect
|
|
Send packet with SSL_NEGOTIATE_CODE
|
|
Receive single char ------- 'S' -------- Establish SSL
| |
| '<else>' |
| Normal startup
|
|
Is it 'E' for error ------------------- Retry connection
| Yes without SSL
| No
|
Is it 'N' for normal ------------------- Normal startup
| Yes
|
Fail with unknown
---------------------------------------------------------------------------
Ephemeral DH
============
Since the server static private key ($DataDir/server.key) will
normally be stored unencrypted so that the database backend can
restart automatically, it is important that we select an algorithm
that continues to provide confidentiality even if the attacker has the
server's private key. Ephemeral DH (EDH) keys provide this and more
(Perfect Forward Secrecy aka PFS).
N.B., the static private key should still be protected to the largest
extent possible, to minimize the risk of impersonations.
Another benefit of EDH is that it allows the backend and clients to
use DSA keys. DSA keys can only provide digital signatures, not
encryption, and are often acceptable in jurisdictions where RSA keys
are unacceptable.
The downside to EDH is that it makes it impossible to use ssldump(1)
if there's a problem establishing an SSL session. In this case you'll
need to temporarily disable EDH (see initialize_dh()).