aboutsummaryrefslogtreecommitdiff
path: root/src/interfaces
Commit message (Collapse)AuthorAge
...
* 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.
* Adjust ecpg expected-results files for commit 7640f9312.Tom Lane2019-05-31
| | | | | Mea culpa for not rechecking check-world at the last step :-( Per buildfarm.
* Fix C++ incompatibilities in ecpg/preproc/ header files.Tom Lane2019-05-31
| | | | | | | There's probably no need to back-patch this, since it seems unlikely that anybody would be inserting C++ code into ecpg's preprocessor. Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru
* Fix assorted header files that failed to compile standalone.Tom Lane2019-05-31
| | | | | | | | | | | | | | | | | | | We have a longstanding project convention that all .h files should be includable with no prerequisites other than postgres.h. This is tested/relied-on by cpluspluscheck. However, cpluspluscheck has not historically been applied to most headers outside the src/include tree, with the predictable consequence that some of them don't work. Fix that, usually by adding missing #include dependencies. The change in printf_hack.h might require some explanation: without it, my C++ compiler whines that the function is unused. There's not so many call sites that "inline" is going to cost much, and besides all the callers are in test code that we really don't care about the size of. There's no actual bugs being fixed here, so I see no need to back-patch. Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru
* Fix more thinkos in new ECPG "PREPARE AS" code.Tom Lane2019-05-26
| | | | | | ecpg_build_params() failed to check for ecpg_alloc failure in one newly-added code path, and leaked a temporary string in another path. Errors in commit a1dc6ab46, spotted by Coverity.
* Fix thinko in new ECPG "PREPARE AS" code.Tom Lane2019-05-26
| | | | | | ecpg_register_prepared_stmt() is pretty obviously checking the wrong variable while trying to detect malloc failure. Error in commit a1dc6ab46, spotted by Coverity.
* Fix typos.Amit Kapila2019-05-26
| | | | | | | Reported-by: Alexander Lakhin Author: Alexander Lakhin Reviewed-by: Amit Kapila and Tom Lane Discussion: https://postgr.es/m/7208de98-add8-8537-91c0-f8b089e2928c@gmail.com
* Update copyright year.Thomas Munro2019-05-24
| | | | | Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CA%2BhUKGJFWXmtYo6Frd77RR8YXCHz7hJ2mRy5aHV%3D7fJOqDnBHA%40mail.gmail.com
* Initial pgperltidy run for v12.Tom Lane2019-05-22
| | | | Make all the perl code look nice, too (for some value of "nice").
* Phase 2 pgindent run for v12.Tom Lane2019-05-22
| | | | | | | | | Switch to 2.1 version of pg_bsd_indent. This formats multiline function declarations "correctly", that is with additional lines of parameter declarations indented to match where the first line's left parenthesis is. Discussion: https://postgr.es/m/CAEepm=0P3FeTXRcU5B2W3jv3PgRVZ-kGUXLGfd42FFhUROO3ug@mail.gmail.com
* Initial pgindent run for v12.Tom Lane2019-05-22
| | | | | | | | This is still using the 2.0 version of pg_bsd_indent. I thought it would be good to commit this separately, so as to document the differences between 2.0 and 2.1 behavior. Discussion: https://postgr.es/m/16296.1558103386@sss.pgh.pa.us
* Add .gitignore entries for new ecpg test case.Tom Lane2019-05-22
| | | | Oversight in commit a1dc6ab465986a62b308dd1bb8da316b5ed9685a.
* Implement PREPARE AS statement for ECPG.Michael Meskes2019-05-22
| | | | | | | | Besides implementing the new statement this change fix some issues with the parsing of PREPARE and EXECUTE statements. The different forms of these statements are now all handled in a ujnified way. Author: Matsumura-san <matsumura.ryo@jp.fujitsu.com>
* Translation updatesPeter Eisentraut2019-05-20
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: a20bf6b8a5b4e32450967055eb5b07cee4704edd
* Move logging.h and logging.c from src/fe_utils/ to src/common/.Tom Lane2019-05-14
| | | | | | | | | | | | | | | | | | | | | | | | The original placement of this module in src/fe_utils/ is ill-considered, because several src/common/ modules have dependencies on it, meaning that libpgcommon and libpgfeutils now have mutual dependencies. That makes it pointless to have distinct libraries at all. The intended design is that libpgcommon is lower-level than libpgfeutils, so only dependencies from the latter to the former are acceptable. We already have the precedent that fe_memutils and a couple of other modules in src/common/ are frontend-only, so it's not stretching anything out of whack to treat logging.c as a frontend-only module in src/common/. To the extent that such modules help provide a common frontend/backend environment for the rest of common/ to use, it's a reasonable design. (logging.c does not yet provide an ereport() emulation, but one can dream.) Hence, move these files over, and revert basically all of the build-system changes made by commit cc8d41511. There are no places that need to grow new dependencies on libpgcommon, further reinforcing the idea that this is the right solution. Discussion: https://postgr.es/m/a912ffff-f6e4-778a-c86a-cf5c47a12933@2ndquadrant.com
* Fix misuse of an integer as a bool.Tom Lane2019-05-13
| | | | | | | | | | | | | | | | | | | pgtls_read_pending is declared to return bool, but what the underlying SSL_pending function returns is a count of available bytes. This is actually somewhat harmless if we're using C99 bools, but in the back branches it's a live bug: if the available-bytes count happened to be a multiple of 256, it would get converted to a zero char value. On machines where char is signed, counts of 128 and up could misbehave as well. The net effect is that when using SSL, libpq might block waiting for data even though some has already been received. Broken by careless refactoring in commit 4e86f1b16, so back-patch to 9.5 where that came in. Per bug #15802 from David Binderman. Discussion: https://postgr.es/m/15802-f0911a97f0346526@postgresql.org
* GSSAPI: Improve documentation and testsStephen Frost2019-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | The GSSAPI encryption patch neglected to update the protocol documentation to describe how to set up a GSSAPI encrypted connection from a client to the server, so fix that by adding the appropriate documentation to protocol.sgml. The tests added for encryption support were overly long and couldn't be run in parallel due to race conditions; this was largely because each test was setting up its own KDC to perform the tests. Instead, merge the authentication tests and the encryption tests into the original test, where we only create one KDC to run the tests with. Also, have the tests check what the server's opinion is of the connection and if it was GSS authenticated or encrypted using the pg_stat_gssapi view. In passing, fix the libpq label for GSSENC-Mode to be consistent with the "PGGSSENCMODE" environment variable. Missing protocol documentation pointed out by Michael Paquier. Issues with the tests pointed out by Tom Lane and Peter Eisentraut. Refactored tests and added documentation by me. Reviewed by Robbie Harwood (protocol documentation) and Michael Paquier (rework of the tests).
* Fix collection of typos and grammar mistakes in docs and commentsMichael Paquier2019-04-19
| | | | | Author: Justin Pryzby Discussion: https://postgr.es/m/20190330224333.GQ5815@telsasoft.com
* Fix assorted minor bogosity in GSSAPI transport error messages.Tom Lane2019-04-17
| | | | | | | | | | | I noted that some buildfarm members were complaining about %ld being used to format values that are (probably) declared size_t. Use %zu instead, and insert a cast just in case some versions of the GSSAPI API declare the length field differently. While at it, clean up gratuitous differences in wording of equivalent messages, show the complained-of length in all relevant messages not just some, include trailing newline where needed, adjust random deviations from project-standard code layout and message style, etc.
* Fix off-by-one check that can lead to a memory overflow in ecpg.Michael Meskes2019-04-11
| | | | Patch by Liu Huailing <liuhuailing@cn.fujitsu.com>
* Add support TCP user timeout in libpq and the backend serverMichael Paquier2019-04-06
| | | | | | | | | | | | | | | | | Similarly to the set of parameters for keepalive, a connection parameter for libpq is added as well as a backend GUC, called tcp_user_timeout. Increasing the TCP user timeout is useful to allow a connection to survive extended periods without end-to-end connection, and decreasing it allows application to fail faster. By default, the parameter is 0, which makes the connection use the system default, and follows a logic close to the keepalive parameters in its handling. When connecting through a Unix-socket domain, the parameters have no effect. Author: Ryohei Nagaura Reviewed-by: Fabien Coelho, Robert Haas, Kyotaro Horiguchi, Kirk Jamison, Mikalai Keida, Takayuki Tsunakawa, Andrei Yahorau Discussion: https://postgr.es/m/EDA4195584F5064680D8130B1CA91C45367328@G01JPEXMBYT04
* Handle errors during GSSAPI startup betterStephen Frost2019-04-04
| | | | | | | | | | | | | | | | | | | | | There was some confusion over the format of the error message returned from the server during GSSAPI startup; specifically, it was expected that a length would be returned when, in reality, at this early stage in the startup sequence, no length is returned from the server as part of an error message. Correct the client-side code for dealing with error messages sent by the server during startup by simply reading what's available into our buffer, after we've discovered it's an error message, and then reporting back what was returned. In passing, also add in documentation of the environment variable PGGSSENCMODE which was missed previously, and adjust the code to look for the PGGSSENCMODE variable (the environment variable change was missed in the prior GSSMODE -> GSSENCMODE commit). Error-handling issue discovered by Peter Eisentraut, the rest were items discovered during testing of the error handling.
* Add a "SQLSTATE-only" error verbosity option to libpq and psql.Tom Lane2019-04-04
| | | | | | | | | | | | | | | | | | This is intended for use mostly in test scripts for external tools, which could do without cross-PG-version variations in error message wording. Of course, the SQLSTATE isn't guaranteed stable either, but it should be more so than the error message text. Note: there's a bit of an ABI change for libpq here, but it seems OK because if somebody compiles against a newer version of libpq-fe.h, and then tries to pass PQERRORS_SQLSTATE to PQsetErrorVerbosity() of an older libpq library, it will be accepted and then act like PQERRORS_DEFAULT, thanks to the way the tests in pqBuildErrorMessage3 have historically been phrased. That seems acceptable. Didier Gautheron, reviewed by Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/CAJRYxuKyj4zA+JGVrtx8OWAuBfE-_wN4sUMK4H49EuPed=mOBw@mail.gmail.com
* GSSAPI encryption supportStephen Frost2019-04-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
* Unified logging system for command-line programsPeter Eisentraut2019-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This unifies the various ad hoc logging (message printing, error printing) systems used throughout the command-line programs. Features: - Program name is automatically prefixed. - Message string does not end with newline. This removes a common source of inconsistencies and omissions. - Additionally, a final newline is automatically stripped, simplifying use of PQerrorMessage() etc., another common source of mistakes. - I converted error message strings to use %m where possible. - As a result of the above several points, more translatable message strings can be shared between different components and between frontends and backend, without gratuitous punctuation or whitespace differences. - There is support for setting a "log level". This is not meant to be user-facing, but can be used internally to implement debug or verbose modes. - Lazy argument evaluation, so no significant overhead if logging at some level is disabled. - Some color in the messages, similar to gcc and clang. Set PG_COLOR=auto to try it out. Some colors are predefined, but can be customized by setting PG_COLORS. - Common files (common/, fe_utils/, etc.) can handle logging much more simply by just using one API without worrying too much about the context of the calling program, requiring callbacks, or having to pass "progname" around everywhere. - Some programs called setvbuf() to make sure that stderr is unbuffered, even on Windows. But not all programs did that. This is now done centrally. Soft goals: - Reduces vertical space use and visual complexity of error reporting in the source code. - Encourages more deliberate classification of messages. For example, in some cases it wasn't clear without analyzing the surrounding code whether a message was meant as an error or just an info. - Concepts and terms are vaguely aligned with popular logging frameworks such as log4j and Python logging. This is all just about printing stuff out. Nothing affects program flow (e.g., fatal exits). The uses are just too varied to do that. Some existing code had wrappers that do some kind of print-and-exit, and I adapted those. I tried to keep the output mostly the same, but there is a lot of historical baggage to unwind and special cases to consider, and I might not always have succeeded. One significant change is that pg_rewind used to write all error messages to stdout. That is now changed to stderr. Reviewed-by: Donald Dong <xdong@csumb.edu> Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru> Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com
* Restructure libpq's handling of send failures.Tom Lane2019-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally, if libpq got a failure (e.g., ECONNRESET) while trying to send data to the server, it would just report that and wash its hands of the matter. It was soon found that that wasn't a very pleasant way of coping with server-initiated disconnections, so we introduced a hack (pqHandleSendFailure) in the code that sends queries to make it peek ahead for server error reports before reporting the send failure. It now emerges that related cases can occur during connection setup; in particular, as of TLS 1.3 it's unsafe to assume that SSL connection failures will be reported by SSL_connect rather than during our first send attempt. We could have fixed that in a hacky way by applying pqHandleSendFailure after a startup packet send failure, but (a) pqHandleSendFailure explicitly disclaims suitability for use in any state except query startup, and (b) the problem still potentially exists for other send attempts in libpq. Instead, let's fix this in a more general fashion by eliminating pqHandleSendFailure altogether, and instead arranging to postpone all reports of send failures in libpq until after we've made an attempt to read and process server messages. The send failure won't be reported at all if we find a server message or detect input EOF. (Note: this removes one of the reasons why libpq typically overwrites, rather than appending to, conn->errorMessage: pqHandleSendFailure needed that behavior so that the send failure report would be replaced if we got a server message or read failure report. Eventually I'd like to get rid of that overwrite behavior altogether, but today is not that day. For the moment, pqSendSome is assuming that its callees will overwrite not append to conn->errorMessage.) Possibly this change should get back-patched someday; but it needs testing first, so let's not consider that till after v12 beta. Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com
* Use correct connection name variable in ecpglib.Michael Meskes2019-03-16
| | | | Fixed-by: Kuroda-san <kuroda.hayato@jp.fujitsu.com>
* Fix potential memory access violation in ecpg if filename of include file isMichael Meskes2019-03-11
| | | | | | shorter than 2 characters. Patch by: "Wu, Fei" <wufei.fnst@cn.fujitsu.com>
* Fix ecpglib regression that made it impossible to close a cursor that wasMichael Meskes2019-03-11
| | | | | | opened in a prepared statement. Patch by: "Kuroda, Hayato" <kuroda.hayato@jp.fujitsu.com>
* Fix whitespacePeter Eisentraut2019-03-01
|
* Fix SCRAM authentication via SSL when mixing versions of OpenSSLMichael Paquier2019-02-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using a libpq client linked with OpenSSL 1.0.1 or older to connect to a backend linked with OpenSSL 1.0.2 or newer, the server would send SCRAM-SHA-256-PLUS and SCRAM-SHA-256 as valid mechanisms for the SASL exchange, and the client would choose SCRAM-SHA-256-PLUS even if it does not support channel binding, leading to a confusing error. In this case, what the client ought to do is switch to SCRAM-SHA-256 so as the authentication can move on and succeed. So for a SCRAM authentication over SSL, here are all the cases present and how we deal with them using libpq: 1) Server supports channel binding, it sends SCRAM-SHA-256-PLUS and SCRAM-SHA-256 as allowed mechanisms. 1-1) Client supports channel binding, chooses SCRAM-SHA-256-PLUS. 1-2) Client does not support channel binding, chooses SCRAM-SHA-256. 2) Server does not support channel binding, sends SCRAM-SHA-256 as allowed mechanism. 2-1) Client supports channel binding, still it has no choice but to choose SCRAM-SHA-256. 2-2) Client does not support channel binding, it chooses SCRAM-SHA-256. In all these scenarios the connection should succeed, and the one which was handled incorrectly prior this commit is 1-2), causing the connection attempt to fail because client chose SCRAM-SHA-256-PLUS over SCRAM-SHA-256. Reported-by: Hugh Ranalli Diagnosed-by: Peter Eisentraut Author: Michael Paquier Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/CAAhbUMO89SqUk-5mMY+OapgWf-twF2NA5sCucbHEzMfGbvcepA@mail.gmail.com Backpatch-through: 11
* Free memory in ecpg bytea regression test.Michael Meskes2019-02-26
| | | | | While not really a problem it's easier to run tools like valgrind against it when fixed.
* Hopefully fixing memory handling issues in ecpglib that Coverity found.Michael Meskes2019-02-26
|
* Fix ecpg bugs caused by missing semicolons in the backend grammar.Tom Lane2019-02-24
| | | | | | | | | | | | | | | | | | | | | | | | | The Bison documentation clearly states that a semicolon is required after every grammar rule, and our scripts that generate ecpg's grammar from the backend's implicitly assumed this is true. But it turns out that only ancient versions of Bison actually enforce that. There have been a couple of rules without trailing semicolons in gram.y for some time, and as a consequence, ecpg's grammar was faulty and produced wrong output for the affected statements. To fix, add the missing semis, and add some cross-checks to ecpg's scripts so that they'll bleat if we mess this up again. The cases that were broken were: * "SET variable = DEFAULT" (but not "SET variable TO DEFAULT"), as well as allied syntaxes such as ALTER SYSTEM SET ... DEFAULT. These produced syntactically invalid output that the server would reject. * Multiple type names in DROP TYPE/DOMAIN commands. Only the first type name would be listed in the emitted command. Per report from Daisuke Higuchi. Back-patch to all supported versions. Discussion: https://postgr.es/m/1803D792815FC24D871C00D17AE95905DB51CE@g01jpexmbkw24
* Add const qualifierPeter Eisentraut2019-02-22
| | | | | | New code introduced in 050710b36964dee7e1b2bf6b5ef00041fd5d2787. The lack of const is not currently a compiler warning, but it's nice to have for consistency with surrounding code.
* Remove duplicate variable declaration in fe-connect.cMichael Paquier2019-02-22
| | | | | | | | The same variables are declared twice when checking if a connection is writable, which is useless. Author: Haribabu Kommi Discussion: https://postgr.es/m/CAJrrPGf=rcALB54w_Tg1_hx3y+cgSWaERY-uYSQzGc3Zt5XN4g@mail.gmail.com
* Fix omissions in ecpg/test/sql/.gitignore.Tom Lane2019-02-18
| | | | Oversights in commits 050710b36 and e81f0e311.
* Properly end string to make sure ecpglib does not read beyond its boundaries.Michael Meskes2019-02-18
|
* Sync ECPG's CREATE TABLE AS statement with backend's.Michael Meskes2019-02-18
| | | | Author: Higuchi-san ("Higuchi, Daisuke" <higuchi.daisuke@jp.fujitsu.com>)
* Add bytea datatype to ECPG.Michael Meskes2019-02-18
| | | | | | | | | | | | So far ECPG programs had to treat binary data for bytea column as 'char' type. But this meant converting from/to escaped format with PQunescapeBytea/ PQescapeBytea() and therefore forcing users to add unnecessary code and cost for the conversion in runtime. By adding a dedicated datatype for bytea most of this special handling is no longer needed. Author: Matsumura-san ("Matsumura, Ryo" <matsumura.ryo@jp.fujitsu.com>) Discussion: https://postgr.es/m/flat/03040DFF97E6E54E88D3BFEE5F5480F737A141F9@G01JPEXMBYT04
* Add DECLARE STATEMENT support to ECPG.Michael Meskes2019-02-16
| | | | | | | | | | | | | | | DECLARE STATEMENT is a statement that lets users declare an identifier pointing at a connection. This identifier will be used in other embedded dynamic SQL statement such as PREPARE, EXECUTE, DECLARE CURSOR and so on. When connecting to a non-default connection, the AT clause can be used in a DECLARE STATEMENT once and is no longer needed in every dynamic SQL statement. This makes ECPG applications easier and more efficient. Moreover, writing code without designating connection explicitly improves portability. Authors: Ideriha-san ("Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>) Kuroda-san ("Kuroda, Hayato" <kuroda.hayato@jp.fujitsu.com>) Discussion: https://postgr.es/m4E72940DA2BF16479384A86D54D0988A565669DF@G01JPEXMBKW04
* More unconstify usePeter Eisentraut2019-02-13
| | | | | | | Replace casts whose only purpose is to cast away const with the unconstify() macro. Discussion: https://www.postgresql.org/message-id/flat/53a28052-f9f3-1808-fed9-460fd43035ab%402ndquadrant.com
* Change error handling of out of scope variables in ecpg.Michael Meskes2019-01-30
| | | | | | The function called can result in an out of memory error that subsequently was disregarded. Instead it should set the appropriate SQL error variables and be checked by whatever whenever statement is defined.
* Make some ecpg test cases more robust against unexpected errors that happenMichael Meskes2019-01-30
| | | | during development. Test cases themselves should not hang or segfault.
* Make sure that ecpglib's statement variable has a defined value no matter what.Michael Meskes2019-01-30
|
* Remove _configthreadlocale() calls in ecpg test suite.Tom Lane2019-01-24
| | | | | | | | | | | | | | | | This essentially reverts commits a772624b1 and 04fbe0e45, which added "_configthreadlocale(_ENABLE_PER_THREAD_LOCALE)" calls to the thread-related ecpg test programs. That was nothing but a hack, because we shouldn't expect that ecpg-using applications have done that for us; and now that we've inserted such calls into ecpglib, the tests should still pass without it. (If they don't, it would be good to know that.) HEAD only; there seems no big need to change this in the back branches. Discussion: https://postgr.es/m/22937.1548307384@sss.pgh.pa.us
* Remove infinite-loop hazards in ecpg test suite.Tom Lane2019-01-24
| | | | | | | | | | | | | | | | | | | | | | | | A report from Andrew Dunstan showed that an ecpglib breakage that causes repeated query failures could lead to infinite loops in some ecpg test scripts, because they contain "while(1)" loops with no exit condition other than successful test completion. That might be all right for manual testing, but it seems entirely unacceptable for automated test environments such as our buildfarm. We don't want buildfarm owners to have to intervene manually when a test goes wrong. To fix, just change all those while(1) loops to exit after at most 100 iterations (which is more than any of them expect to iterate). This seems sufficient since we'd see discrepancies in the test output if any loop executed the wrong number of times. I tested this by dint of intentionally breaking ecpg_do_prologue to always fail, and verifying that the tests still got to completion. Back-patch to all supported branches, since the whole point of this exercise is to protect the buildfarm against future mistakes. Discussion: https://postgr.es/m/18693.1548302004@sss.pgh.pa.us
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 14:54:01 +0000