pgsql: Make lsn argument of walrcv_create_slot() optional
Make lsn argument of walrcv_create_slot() optional Some callers are not using it, so it's wasteful to have to specify it. Reviewed-by: Masahiko Sawada Discussion: https://www.postgresql.org/message-id/ca+fd4k4bcyryucnftnk-cqx3+jsg+prpehhauso-w4p0lec...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c67a55da4ea0caa18547fd1533110e9126ba8d47 Modified Files -- src/backend/commands/subscriptioncmds.c | 3 +-- src/backend/replication/libpqwalreceiver/libpqwalreceiver.c | 6 -- 2 files changed, 5 insertions(+), 4 deletions(-)
pgsql: Extensive code review for GSSAPI encryption mechanism.
Extensive code review for GSSAPI encryption mechanism. Fix assorted bugs in handling of non-blocking I/O when using GSSAPI encryption. The encryption layer could return the wrong status information to its caller, resulting in effectively dropping some data (or possibly in aborting a not-broken connection), or in a "livelock" situation where data remains to be sent but the upper layers think transmission is done and just go to sleep. There were multiple small thinkos contributing to that, as well as one big one (failure to think through what to do when a send fails after having already transmitted data). Note that these errors could cause failures whether the client application asked for non-blocking I/O or not, since both libpq and the backend always run things in non-block mode at this level. Also get rid of use of static variables for GSSAPI inside libpq; that's entirely not okay given that multiple connections could be open at once inside a single client process. Also adjust a bunch of random small discrepancies between the frontend and backend versions of the send/receive functions -- except for error handling, they should be identical, and now they are. Also extend the Kerberos TAP tests to exercise cases where nontrivial amounts of data need to be pushed through encryption. Before, those tests didn't provide any useful coverage at all for the cases of interest here. (They still might not, depending on timing, but at least there's a chance.) Per complaint from pmc@citylink and subsequent investigation. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/20200109181822.ga74...@gate.oper.dinoex.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2c0cdc8183654c090c9a1e2f1b5e96ba4634e16a Modified Files -- src/backend/libpq/be-secure-gssapi.c| 397 -- src/interfaces/libpq/fe-connect.c | 17 +- src/interfaces/libpq/fe-secure-gssapi.c | 416 src/interfaces/libpq/libpq-int.h| 17 ++ src/test/kerberos/t/001_auth.pl | 52 +++- 5 files changed, 555 insertions(+), 344 deletions(-)
pgsql: Extensive code review for GSSAPI encryption mechanism.
Extensive code review for GSSAPI encryption mechanism. Fix assorted bugs in handling of non-blocking I/O when using GSSAPI encryption. The encryption layer could return the wrong status information to its caller, resulting in effectively dropping some data (or possibly in aborting a not-broken connection), or in a "livelock" situation where data remains to be sent but the upper layers think transmission is done and just go to sleep. There were multiple small thinkos contributing to that, as well as one big one (failure to think through what to do when a send fails after having already transmitted data). Note that these errors could cause failures whether the client application asked for non-blocking I/O or not, since both libpq and the backend always run things in non-block mode at this level. Also get rid of use of static variables for GSSAPI inside libpq; that's entirely not okay given that multiple connections could be open at once inside a single client process. Also adjust a bunch of random small discrepancies between the frontend and backend versions of the send/receive functions -- except for error handling, they should be identical, and now they are. Also extend the Kerberos TAP tests to exercise cases where nontrivial amounts of data need to be pushed through encryption. Before, those tests didn't provide any useful coverage at all for the cases of interest here. (They still might not, depending on timing, but at least there's a chance.) Per complaint from pmc@citylink and subsequent investigation. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/20200109181822.ga74...@gate.oper.dinoex.org Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/fde155424f6779b009f8f01a71af8dd6176a0c81 Modified Files -- src/backend/libpq/be-secure-gssapi.c| 397 -- src/interfaces/libpq/fe-connect.c | 17 +- src/interfaces/libpq/fe-secure-gssapi.c | 416 src/interfaces/libpq/libpq-int.h| 17 ++ src/test/kerberos/t/001_auth.pl | 52 +++- 5 files changed, 555 insertions(+), 344 deletions(-)
