aboutsummaryrefslogtreecommitdiff
path: root/src/interfaces
Commit message (Collapse)AuthorAge
* Teach libpq to handle arbitrary-length lines in .pgpass files.Tom Lane2020-09-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically there's been a hard-wired assumption here that no line of a .pgpass file could be as long as NAMEDATALEN*5 bytes. That's a bit shaky to start off with, because (a) there's no reason to suppose that host names fit in NAMEDATALEN, and (b) this figure fails to allow for backslash escape characters. However, it fails completely if someone wants to use a very long password, and we're now hearing reports of people wanting to use "security tokens" that can run up to several hundred bytes. Another angle is that the file is specified to allow comment lines, but there's no reason to assume that long comment lines aren't possible. Rather than guessing at what might be a more suitable limit, let's replace the fixed-size buffer with an expansible PQExpBuffer. That adds one malloc/free cycle to the typical use-case, but that's surely pretty cheap relative to the I/O this code has to do. Also, add TAP test cases to exercise this code, because there was no test coverage before. This reverts most of commit 2eb3bc588, as there's no longer a need for a warning message about overlength .pgpass lines. (I kept the explicit check for comment lines, though.) In HEAD and v13, this also fixes an oversight in 74a308cf5: there's not much point in explicit_bzero'ing the line buffer if we only do so in two of the three exit paths. Back-patch to all supported branches, except that the test case only goes back to v10 where src/test/authentication/ was added. Discussion: https://postgr.es/m/4187382.1598909041@sss.pgh.pa.us
* Stamp 12.4.REL_12_4Tom Lane2020-08-10
|
* Translation updatesPeter Eisentraut2020-08-10
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 444a6779aafc552ac452715caa65cfca0e723073
* Increase hard-wired timeout values in ecpg regression tests.Tom Lane2020-08-04
| | | | | | | | | | | | | | A couple of test cases had connect_timeout=14, a value that seems to have been plucked from a hat. While it's more than sufficient for normal cases, slow/overloaded buildfarm machines can get a timeout failure here, as per recent report from "sungazer". Increase to 180 seconds, which is in line with our typical timeouts elsewhere in the regression tests. Back-patch to 9.6; the code looks different in 9.5, and this doesn't seem to be quite worth the effort to adapt to that. Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer&dt=2020-08-04%2007%3A12%3A22
* Fix handling of structure for bytea data type in ECPGMichael Paquier2020-07-27
| | | | | | | | | | | | | | Some code paths dedicated to bytea used the structure for varchar. This did not lead to any actual bugs, as bytea and varchar have the same definition, but it could become a trap if one of these definitions changes for a new feature or a bug fix. Issue introduced by 050710b. Author: Shenhao Wang Reviewed-by: Vignesh C, Michael Paquier Discussion: https://postgr.es/m/07ac7dee1efc44f99d7f53a074420177@G08CNEXMBPEKD06.g08.fujitsu.local Backpatch-through: 12
* Fix bugs in libpq's management of GSS encryption state.Tom Lane2020-07-13
| | | | | | | | | | | | | | | | | | | | | GSS-related resources should be cleaned up in pqDropConnection, not freePGconn, else the wrong things happen when resetting a connection or trying to switch to a different server. It's also critical to reset conn->gssenc there. During connection setup, initialize conn->try_gss at the correct place, else switching to a different server won't work right. Remove now-redundant cleanup of GSS resources around one (and, for some reason, only one) pqDropConnection call in connectDBStart. Per report from Kyotaro Horiguchi that psql would freeze up, rather than successfully resetting a GSS-encrypted connection after a server restart. This is YA oversight in commit b0b39f72b, so back-patch to v12. Discussion: https://postgr.es/m/20200710.173803.435804731896516388.horikyota.ntt@gmail.com
* Fix ecpg crash with bytea and cursor variables.Michael Meskes2020-06-30
| | | | Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
* Try to read data from the socket in pqSendSome's write_failed paths.Tom Lane2020-06-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even when we've concluded that we have a hard write failure on the socket, we should continue to try to read data. This gives us an opportunity to collect any final error message that the backend might have sent before closing the connection; moreover it is the job of pqReadData not pqSendSome to close the socket once EOF is detected. Due to an oversight in 1f39a1c06, pqSendSome failed to try to collect data in the case where we'd already set write_failed. The problem was masked for ordinary query operations (which really only make one write attempt anyway), but COPY to the server would continue to send data indefinitely after a mid-COPY connection loss. Hence, add pqReadData calls into the paths where pqSendSome drops data because of write_failed. If we've lost the connection, this will eventually result in closing the socket and setting CONNECTION_BAD, which will cause PQputline and siblings to report failure, allowing the application to terminate the COPY sooner. (Basically this restores what happened before 1f39a1c06.) There are related issues that this does not solve; for example, if the backend sends an error but doesn't drop the connection, we did and still will keep pumping COPY data as long as the application sends it. Fixing that will require application-visible behavior changes though, and anyway it's an ancient behavior that we've had few complaints about. For now I'm just trying to fix the regression from 1f39a1c06. Per a complaint from Andres Freund. Back-patch into v12 where 1f39a1c06 came in. Discussion: https://postgr.es/m/20200603201242.ofvm4jztpqytwfye@alap3.anarazel.de
* Stamp 12.3.REL_12_3Tom Lane2020-05-11
|
* Translation updatesPeter Eisentraut2020-05-11
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 60bf9b5caac08d0483f6f92ebf9ef2e0eef5b6bb
* Fix severe memory leaks in GSSAPI encryption support.Tom Lane2020-05-05
| | | | | | | | | | | | | | | | | Both the backend and libpq leaked buffers containing encrypted data to be transmitted, so that the process size would grow roughly as the total amount of data sent. There were also far-less-critical leaks of the same sort in GSSAPI session establishment. Oversight in commit b0b39f72b, which I failed to notice while reviewing the code in 2c0cdc818. Per complaint from pmc@citylink. Back-patch to v12 where this code was introduced. Discussion: https://postgr.es/m/20200504115649.GA77072@gate.oper.dinoex.org
* Fix memory leak in libpq when using sslmode=verify-fullMichael Paquier2020-04-22
| | | | | | | | | | | | | Checking if Subject Alternative Names (SANs) from a certificate match with the hostname connected to leaked memory after each lookup done. This is broken since acd08d7 that added support for SANs in SSL certificates, so backpatch down to 9.5. Author: Roman Peshkurov Reviewed-by: Hamid Akhtar, Michael Paquier, David Steele Discussion: https://postgr.es/m/CALLDf-pZ-E3mjxd5=bnHsDu9zHEOnpgPgdnO84E2RuwMCjjyPw@mail.gmail.com Backpatch-through: 9.5
* Allow ecpg to be built stand-alone, allow parallel libpq makeBruce Momjian2020-03-31
| | | | | | | | | | | | | This change defines SHLIB_PREREQS for the libpgport dependency, rather than using a makefile rule. This was broken in PG 12. Reported-by: Filip Janus Discussion: https://postgr.es/m/E5Dc85EGUY4wyG8cjAU0qoEdCJxGK_qhW1s9qSuYq9A@mail.gmail.com Author: Dagfinn Ilmari Mannsåker (for libpq) Backpatch-through: 12
* Stamp 12.2.REL_12_2Tom Lane2020-02-10
|
* Translation updatesPeter Eisentraut2020-02-10
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: bcdfb83b81a7aa3c3948c0a5221f9c68d7010ac5
* Fix dispsize for libpq connection parameters channel_binding and gssencmodeMichael Paquier2020-01-29
| | | | | | | | | | | | | channel_binding's longest allowed value is not "7", it is actually "8". gssencmode also got that wrong. A similar mistake has been fixed as of f4051e3. Backpatch down to v12, where gssencmode has been introduced. Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/20200128053633.GD1552@paquier.xyz Backpatch-through: 12
* Fix out-of-memory handling in ecpglib.Tom Lane2020-01-19
| | | | | | | | | | ecpg_build_params() would crash on a null pointer dereference if realloc() failed, due to updating the persistent "stmt" struct too aggressively. (Even without the crash, this would've leaked the old storage that we were trying to realloc.) Per Coverity. This seems to have been broken in commit 0cc050794, so back-patch into v12.
* Extensive code review for GSSAPI encryption mechanism.Tom Lane2020-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.GA74698@gate.oper.dinoex.org
* libpq should expose GSS-related parameters even when not implemented.Tom Lane2019-12-20
| | | | | | | | | | | | | | | | | | | | | | We realized years ago that it's better for libpq to accept all connection parameters syntactically, even if some are ignored or restricted due to lack of the feature in a particular build. However, that lesson from the SSL support was for some reason never applied to the GSSAPI support. This is causing various buildfarm members to have problems with a test case added by commit 6136e94dc, and it's just a bad idea from a user-experience standpoint anyway, so fix it. While at it, fix some places where parameter-related infrastructure was added with the aid of a dartboard, or perhaps with the aid of the anti-pattern "add new stuff at the end". It should be safe to rearrange the contents of struct pg_conn even in released branches, since that's private to libpq (and we'd have to move some fields in some builds to fix this, anyway). Back-patch to all supported branches. Discussion: https://postgr.es/m/11297.1576868677@sss.pgh.pa.us
* Fix off-by-one error in PGTYPEStimestamp_fmt_ascTomas Vondra2019-11-30
| | | | | | | | | | | | | | | When using %b or %B patterns to format a date, the code was simply using tm_mon as an index into array of month names. But that is wrong, because tm_mon is 1-based, while array indexes are 0-based. The result is we either use name of the next month, or a segfault (for December). Fix by subtracting 1 from tm_mon for both patterns, and add a regression test triggering the issue. Backpatch to all supported versions (the bug is there far longer, since at least 2003). Reported-by: Paul Spencer Backpatch-through: 9.4 Discussion: https://postgr.es/m/16143-0d861eb8688d3fef%40postgresql.org
* Stamp 12.1.REL_12_1Tom Lane2019-11-11
|
* Translation updatesPeter Eisentraut2019-11-11
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 99bbc57cce0a1024898ac8d38b35fc6df7294e9e
* Move declaration of ecpg_gettext() to a saner place.Tom Lane2019-11-07
| | | | | | | | | | | | | | | | | | | | | Declaring this in the client-visible header ecpglib.h was a pretty poor decision. It's not meant to be application-callable (and if it was, putting it outside the extern "C" { ... } wrapper means that C++ clients would fail to call it). And the declaration would not even compile for a client, anyway, since it would not have the macro pg_attribute_format_arg(). Fortunately, it seems that no clients have tried to include this header with ENABLE_NLS defined, or we'd have gotten complaints about that. But we have no business putting such a restriction on client code. Move the declaration to ecpglib_extern.h, since in fact nothing outside src/interfaces/ecpg/ecpglib/ needs to call it. The practical effect of this is just that clients can now safely #include ecpglib.h while having ENABLE_NLS defined, but that seems like enough of a reason to back-patch it. Discussion: https://postgr.es/m/20590.1573069709@sss.pgh.pa.us
* Get rid of useless/dangerous redefinition of bool in ECPG.Tom Lane2019-10-25
| | | | | | | | | | | | | | | | | | | | | | | | | pgtypeslib_extern.h contained fallback definitions of "bool", "FALSE", and "TRUE". The latter two are just plain unused, and have been for awhile. The former came into play only if there wasn't a macro definition of "bool", which is true only if we aren't using <stdbool.h>. However, it then defined bool as "char"; since commit d26a810eb that conflicts with c.h's desire to use "unsigned char". We'd missed seeing any bad effects of that due to accidental header inclusion order choices, but dddf4cdc3 exposed that it was problematic. To fix, let's just get rid of these definitions. They should not be needed because everyplace in Postgres should be relying on c.h to provide a definition for type bool. (Note that despite its name, pgtypeslib_extern.h isn't exposed to any outside code; we don't install it.) This doesn't fully resolve the issue, because ecpglib.h is doing similar things, but that seems to require more thought to fix. Back-patch to v12 where d26a810eb came in, to forestall any unpleasant surprises from future back-patched bug fixes. Discussion: https://postgr.es/m/CAA4eK1LmaKO7Du9M9Lo=kxGU8sB6aL8fa3sF6z6d5yYYVe3BuQ@mail.gmail.com
* Fix thinkos from 4f4061b for libpq integer parsingMichael Paquier2019-10-23
| | | | | | | | | | | A check was redundant. While on it, add an assertion to make sure that the parsing routine is never called with a NULL input. All the code paths currently calling the parsing routine are careful with NULL inputs already, but future callers may forget that. Reported-by: Peter Eisentraut, Lars Kanis Discussion: https://postgr.es/m/ec64956b-4597-56b6-c3db-457d15250fe4@2ndquadrant.com Backpatch-through: 12
* Fix error reporting of connect_timeout in libpq for value parsingMichael Paquier2019-10-21
| | | | | | | | | | | The logic was correctly detecting a parsing failure, but the parsing error did not get reported back to the client properly. Reported-by: Ed Morley Author: Lars Kanis Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/a9b4cbd7-4ecb-06b2-ebd7-1739bbff3217@greiz-reinsdorf.de Backpatch-through: 12
* Fix parsing of integer values for connection parameters in libpqMichael Paquier2019-10-21
| | | | | | | | | | | | | | | | Commit e7a2217 has introduced stricter checks for integer values in connection parameters for libpq. However this failed to correctly check after trailing whitespaces, while leading whitespaces were discarded per the use of strtol(3). This fixes and refactors the parsing logic to handle both cases consistently. Note that trying to restrict the use of trailing whitespaces can easily break connection strings like in ECPG regression tests (these have allowed me to catch the parsing bug with connect_timeout). Author: Michael Paquier Reviewed-by: Lars Kanis Discussion: https://postgr.es/m/a9b4cbd7-4ecb-06b2-ebd7-1739bbff3217@greiz-reinsdorf.de Backpatch-through: 12
* Put back pqsignal() as an exported libpq symbol.Tom Lane2019-10-10
| | | | | | | | | | | | | | | | | | This reverts commit f7ab80285. Per discussion, we can't remove an exported symbol without a SONAME bump, which we don't want to do. In particular that breaks usage of current libpq.so with pre-9.3 versions of psql etc, which need libpq to export pqsignal(). As noted in that commit message, exporting the symbol from libpgport.a won't work reliably; but actually we don't want to export src/port's implementation anyway. Any pre-9.3 client is going to be expecting the definition that pqsignal() had before 9.3, which was that it didn't set SA_RESTART for SIGALRM. Hence, put back pqsignal() in a separate source file in src/interfaces/libpq, and give it the old semantics. Back-patch to v12. Discussion: https://postgr.es/m/E1g5vmT-0003K1-6S@gemulon.postgresql.org
* Translation updatesPeter Eisentraut2019-09-29
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 1d66650d203c89e3c69a18be3b4361f5a5393fcf
* Translation updatesPeter Eisentraut2019-09-23
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 8a42b829ebeb8b22db0e3258ec02137f8840b960
* Remove removed file from nls.mkPeter Eisentraut2019-09-21
| | | | part of revert "Add DECLARE STATEMENT support to ECPG."
* Revert "Add DECLARE STATEMENT support to ECPG."Tom Lane2019-09-20
| | | | | | | | | | | | This reverts commit bd7c95f0c1a38becffceb3ea7234d57167f6d4bf, along with assorted follow-on fixes. There are some questions about the definition and implementation of that statement, and we don't have time to resolve them before v13 release. Rather than ship the feature and then have backwards-compatibility concerns constraining any redesign, let's remove it for now and try again later. Discussion: https://postgr.es/m/TY2PR01MB2443EC8286995378AEB7D9F8F5B10@TY2PR01MB2443.jpnprd01.prod.outlook.com
* GSSAPI error message improvementsPeter Eisentraut2019-09-19
| | | | | | | | | | Make the error messages around GSSAPI encryption a bit clearer. Tweak some messages to avoid plural problems. Also make a code change for clarity. Using "conf" for "confidential" is quite confusing. Using "conf_state" is perhaps not much better but that's what the GSSAPI documentation uses, so there is at least some hope of understanding it.
* Revert change of ecpglib major versionPeter Eisentraut2019-09-19
| | | | | | | | | The major version of ecpglib was changed in bd7c95f0c1a38becffceb3ea7234d57167f6d4bf, apparently without justification. Revert this, since nothing has changed in this library except some added functions. Discussion: https://www.postgresql.org/message-id/flat/48ee4c56-e1df-b39d-2cad-c7d80b120eb5%402ndquadrant.com
* Translation updatesPeter Eisentraut2019-09-09
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 2808de890d4be52a0a82fb3bd84ea7998c6f5101
* Message style fixesPeter Eisentraut2019-09-06
|
* libpq: ccache -> credential cachePeter Eisentraut2019-09-06
| | | | | The term "ccache" is overloaded. Let's be more clear, in case someone other than a Kerberos wizard has to read this code.
* Translation updatesPeter Eisentraut2019-08-05
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: e255bc8b15d0f173f9de9048d3d6ad6e40085a48
* Fix failures to ignore \r when reading Windows-style newlines.Tom Lane2019-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libpq failed to ignore Windows-style newlines in connection service files. This normally wasn't a problem on Windows itself, because fgets() would convert \r\n to just \n. But if libpq were running inside a program that changes the default fopen mode to binary, it would see the \r's and think they were data. In any case, it's project policy to ignore \r in text files unconditionally, because people sometimes try to use files with DOS-style newlines on Unix machines, where the C library won't hide that from us. Hence, adjust parseServiceFile() to ignore \r as well as \n at the end of the line. In HEAD, go a little further and make it ignore all trailing whitespace, to match what it's always done with leading whitespace. In HEAD, also run around and fix up everyplace where we have newline-chomping code to make all those places look consistent and uniformly drop \r. It is not clear whether any of those changes are fixing live bugs. Most of the non-cosmetic changes are in places that are reading popen output, and the jury is still out as to whether popen on Windows can return \r\n. (The Windows-specific code in pipe_read_line seems to think so, but our lack of support for this elsewhere suggests maybe it's not a problem in practice.) Hence, I desisted from applying those changes to back branches, except in run_ssl_passphrase_command() which is new enough and little-tested enough that we'd probably not have heard about any problems there. Tom Lane and Michael Paquier, per bug #15827 from Jorge Gustavo Rocha. Back-patch the parseServiceFile() change to all supported branches, and the run_ssl_passphrase_command() change to v11 where that was added. Discussion: https://postgr.es/m/15827-e6ba53a3a7ed543c@postgresql.org
* Fix small memory leak in ecpglib ecpg_update_declare_statement() is called theMichael Meskes2019-07-08
| | | | | | second time. Author: "Zhang, Jie" <zhangjie2@cn.fujitsu.com>
* Add missing source files to nls.mkPeter Eisentraut2019-07-06
|
* Fix many typos and inconsistenciesMichael Paquier2019-07-01
| | | | | Author: Alexander Lakhin Discussion: https://postgr.es/m/af27d1b3-a128-9d62-46e0-88f424397f44@gmail.com
* Remove explicit error handling for obsolete date/time valuesPeter Eisentraut2019-06-30
| | | | | | | | | | The date/time values 'current', 'invalid', and 'undefined' were removed a long time ago, but the code still contains explicit error handling for the transition. To simplify the code and avoid having to handle these values everywhere, just remove the recognition of these tokens altogether now. Reviewed-by: Michael Paquier <michael@paquier.xyz>
* Translation updatesPeter Eisentraut2019-06-17
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 1a710c413ce4c4cd081843e563cde256bb95f490
* Fix buffer overflow when processing SCRAM final message in libpqMichael Paquier2019-06-17
| | | | | | | | | | | | | | When a client connects to a rogue server sending specifically-crafted messages, this can suffice to execute arbitrary code as the operating system account used by the client. While on it, fix one error handling when decoding an incorrect salt included in the first message received from server. Author: Michael Paquier Reviewed-by: Jonathan Katz, Heikki Linnakangas Security: CVE-2019-10164 Backpatch-through: 10
* Tweak libpq's PQhost, PQhostaddr, and psql's \connectAlvaro Herrera2019-06-14
| | | | | | | | | | | | | | | | | | | | | | | | Fixes some problems introduced by 6e5f8d489acc: * When reusing conninfo data from the previous connection in \connect, the host address should only be reused if it was specified as hostaddr; if it wasn't, then 'host' is resolved afresh. We were reusing the same IP address, which ignores a possible DNS change as well as any other addresses that the name resolves to than the one that was used in the original connection. * PQhost, PQhostaddr: Don't present user-specified hostaddr when we have an inet_net_ntop-produced equivalent address. The latter has been put in canonical format, which is cleaner (so it produces "127.0.0.1" when given "host=2130706433", for example). * Document the hostaddr-reusing aspect of \connect. * Fix some code comments Author: Fabien Coelho Reported-by: Noah Misch Discussion: https://postgr.es/m/20190527203713.GA58392@gust.leadboat.com
* Fix double-word typosAlvaro Herrera2019-06-13
| | | | | Discussion: https://postgr.es/m/20190612184527.GA24266@alvherre.pgsql Reviewed-by: Michaël Paquier
* Stop using spelling "nonexistant".Noah Misch2019-06-08
| | | | | The documentation used "nonexistent" exclusively, and the source tree used it three times as often as "nonexistant".
* Update stale comments, and fix comment typos.Noah Misch2019-06-08
|
* Un-break ecpg tests for Windows.Tom Lane2019-06-02
| | | | | | | | | | Declaring a function "inline" still doesn't work with Windows compilers (C99? what's that?), unless the macro provided by pg_config.h is in-scope, which it is not in our ECPG test programs. So the workaround I tried to use in commit 7640f9312 doesn't work for Windows. Revert the change in printf_hack.h, and instead just blacklist that file in cpluspluscheck --- since it's a not-installed test file, we don't really need to verify its C++ cleanliness anyway.
generated by cgit v1.2.3 (git 2.25.1) at 2025-06-27 01:58:24 +0000