aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Code review for NextValueExpr expression node type.Tom Lane2017-07-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add missing infrastructure for this node type, notably in ruleutils.c where its lack could demonstrably cause EXPLAIN to fail. Add outfuncs/readfuncs support. (outfuncs support is useful today for debugging purposes. The readfuncs support may never be needed, since at present it would only matter for parallel query and NextValueExpr should never appear in a parallelizable query; but it seems like a bad idea to have a primnode type that isn't fully supported here.) Teach planner infrastructure that NextValueExpr is a volatile, parallel-unsafe, non-leaky expression node with cost cpu_operator_cost. Given its limited scope of usage, there *might* be no live bug today from the lack of that knowledge, but it's certainly going to bite us on the rear someday. Teach pg_stat_statements about the new node type, too. While at it, also teach cost_qual_eval() that MinMaxExpr, SQLValueFunction, XmlExpr, and CoerceToDomain should be charged as cpu_operator_cost. Failing to do this for SQLValueFunction was an oversight in my commit 0bb51aa96. The others are longer-standing oversights, but no time like the present to fix them. (In principle, CoerceToDomain could have cost much higher than this, but it doesn't presently seem worth trying to examine the domain's constraints here.) Modify execExprInterp.c to execute NextValueExpr as an out-of-line function; it seems quite unlikely to me that it's worth insisting that it be inlined in all expression eval methods. Besides, providing the out-of-line function doesn't stop anyone from inlining if they want to. Adjust some places where NextValueExpr support had been inserted with the aid of a dartboard rather than keeping it in the same order as elsewhere. Discussion: https://postgr.es/m/23862.1499981661@sss.pgh.pa.us
* Fix broken link-command-line ordering for libpgfeutils.Tom Lane2017-07-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the frontend Makefiles that pull in libpgfeutils, we'd generally done it like this: LDFLAGS += -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport) That method is badly broken, as seen in bug #14742 from Chris Ruprecht. The -L flag for src/fe_utils ends up being placed after whatever random -L flags are in LDFLAGS already. That puts us at risk of pulling in libpgfeutils.a from some previous installation rather than the freshly built one in src/fe_utils. Also, the lack of an "override" is hazardous if someone tries to specify some LDFLAGS on the make command line. The correct way to do it is like this: override LDFLAGS := -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport) $(LDFLAGS) so that libpgfeutils, along with libpq, libpgport, and libpgcommon, are guaranteed to be pulled in from the build tree and not from any referenced system directory, because their -L flags will appear first. In some places we'd been even lazier and done it like this: LDFLAGS += -L$(top_builddir)/src/fe_utils -lpgfeutils -lpq which is subtly wrong in an additional way: on platforms where we can't restrict the symbols exported by libpq.so, it allows libpgfeutils to latch onto libpgport and libpgcommon symbols from libpq.so, rather than directly from those static libraries as intended. This carries hazards like those explained in the comments for the libpq_pgport macro. In addition to fixing the broken libpgfeutils usages, I tried to standardize on using $(libpq_pgport) like so: override LDFLAGS := $(libpq_pgport) $(LDFLAGS) even where libpgfeutils is not in the picture. This makes no difference right now but will hopefully discourage future mistakes of the same ilk. And it's more like the way we handle CPPFLAGS in libpq-using Makefiles. In passing, just for consistency, make pgbench include PTHREAD_LIBS the same way everyplace else does, ie just after LIBS rather than in some random place in the command line. This might have practical effect if there are -L switches in that macro on some platform. It looks to me like the MSVC build scripts are not affected by this error, but someone more familiar with them than I might want to double check. Back-patch to 9.6 where libpgfeutils was introduced. In 9.6, the hazard this error creates is that a reinstallation might link to the prior installation's copy of libpgfeutils.a and thereby fail to absorb a minor-version bug fix. Discussion: https://postgr.es/m/20170714125106.9231.13772@wrigleys.postgresql.org
* Fix pg_basebackup output to stdout on Windows.Heikki Linnakangas2017-07-14
| | | | | | | | | | | | | | | When writing a backup to stdout with pg_basebackup on Windows, put stdout to binary mode. Any CR bytes in the output will otherwise be output incorrectly as CR+LF. In the passing, standardize on using "_setmode" instead of "setmode", for the sake of consistency. They both do the same thing, but according to MSDN documentation, setmode is deprecated. Fixes bug #14634, reported by Henry Boehlert. Patch by Haribabu Kommi. Backpatch to all supported versions. Discussion: https://www.postgresql.org/message-id/20170428082818.24366.13134@wrigleys.postgresql.org
* Fix dumping of FUNCTION RTEs that contain non-function-call expressions.Tom Lane2017-07-13
| | | | | | | | | | | | | | | | | | | | | | | | | | The grammar will only accept something syntactically similar to a function call in a function-in-FROM expression. However, there are various ways to input something that ruleutils.c won't deparse that way, potentially leading to a view or rule that fails dump/reload. Fix by inserting a dummy CAST around anything that isn't going to deparse as a function (which is one of the ways to get something like that in there in the first place). In HEAD, also make use of the infrastructure added by this to avoid emitting unnecessary parentheses in CREATE INDEX deparsing. I did not change that in back branches, thinking that people might find it to be unexpected/unnecessary behavioral change. In HEAD, also fix incorrect logic for when to add extra parens to partition key expressions. Somebody apparently thought they could get away with simpler logic than pg_get_indexdef_worker has, but they were wrong --- a counterexample is PARTITION BY LIST ((a[1])). Ignoring the prettyprint flag for partition expressions isn't exactly a nice solution anyway. This has been broken all along, so back-patch to all supported branches. Discussion: https://postgr.es/m/10477.1499970459@sss.pgh.pa.us
* Fix typo in v10 release notesAlvaro Herrera2017-07-13
| | | | | | | The new functions return a list of files in the corresponding directory, not the name of the directory itself. Pointed out by Gianni Ciolli.
* Fix race between GetNewTransactionId and GetOldestActiveTransactionId.Heikki Linnakangas2017-07-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The race condition goes like this: 1. GetNewTransactionId advances nextXid e.g. from 100 to 101 2. GetOldestActiveTransactionId reads the new nextXid, 101 3. GetOldestActiveTransactionId loops through the proc array. There are no active XIDs there, so it returns 101 as the oldest active XID. 4. GetNewTransactionid stores XID 100 to MyPgXact->xid So, GetOldestActiveTransactionId returned XID 101, even though 100 only just started and is surely still running. This would be hard to hit in practice, and even harder to spot any ill effect if it happens. GetOldestActiveTransactionId is only used when creating a checkpoint in a master server, and the race condition can only happen on an online checkpoint, as there are no backends running during a shutdown checkpoint. The oldestActiveXid value of an online checkpoint is only used when starting up a hot standby server, to determine the starting point where pg_subtrans is initialized from. For the race condition to happen, there must be no other XIDs in the proc array that would hold back the oldest-active XID value, which means that the missed XID must be a top transaction's XID. However, pg_subtrans is not used for top XIDs, so I believe an off-by-one error is in fact inconsequential. Nevertheless, let's fix it, as it's clearly wrong and the fix is simple. This has been wrong ever since hot standby was introduced, so backport to all supported versions. Discussion: https://www.postgresql.org/message-id/e7258662-82b6-7a45-56d4-99b337a32bf7@iki.fi
* Fix ruleutils.c for domain-over-array cases, too.Tom Lane2017-07-12
| | | | | | | | | | | | | Further investigation shows that ruleutils isn't quite up to speed either for cases where we have a domain-over-array: it needs to be prepared to look past a CoerceToDomain at the top level of field and element assignments, else it decompiles them incorrectly. Potentially this would result in failure to dump/reload a rule, if it looked like the one in the new test case. (I also added a test for EXPLAIN; that output isn't broken, but clearly we need more test coverage here.) Like commit b1cb32fb6, this bug is reachable in cases we already support, so back-patch all the way.
* Reduce memory usage of tsvector type analyze function.Heikki Linnakangas2017-07-12
| | | | | | | | | | | | | | | | | compute_tsvector_stats() detoasted and kept in memory every tsvector value in the sample, but that can be a lot of memory. The original bug report described a case using over 10 gigabytes, with statistics target of 10000 (the maximum). To fix, allocate a separate copy of just the lexemes that we keep around, and free the detoasted tsvector values as we go. This adds some palloc/pfree overhead, when you have a lot of distinct lexemes in the sample, but it's better than running out of memory. Fixes bug #14654 reported by James C. Reviewed by Tom Lane. Backport to all supported versions. Discussion: https://www.postgresql.org/message-id/20170514200602.1451.46797@wrigleys.postgresql.org
* commit_ts test: Set node name in testAlvaro Herrera2017-07-12
| | | | | | Otherwise, the script output has a lot of pointless warnings. This was forgotten in 9def031bd2821f35b5f506260d922482648a8bb0
* Avoid integer overflow while sifting-up a heap in tuplesort.c.Tom Lane2017-07-12
| | | | | | | | | | | | | | | | If the number of tuples in the heap exceeds approximately INT_MAX/2, this loop's calculation "2*i+1" could overflow, resulting in a crash. Fix it by using unsigned int rather than int for the relevant local variables; that shouldn't cost anything extra on any popular hardware. Per bug #14722 from Sergey Koposov. Original patch by Sergey Koposov, modified by me per a suggestion from Heikki Linnakangas to use unsigned int not int64. Back-patch to 9.4, where tuplesort.c grew the ability to sort as many as INT_MAX tuples in-memory (commit 263865a48). Discussion: https://postgr.es/m/20170629161637.1478.93109@wrigleys.postgresql.org
* Fix variable and type name in comment.Heikki Linnakangas2017-07-12
| | | | | | Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/20170711.163441.241981736.horiguchi.kyotaro@lab.ntt.co.jp
* Fix ordering of operations in SyncRepWakeQueue to avoid assertion failure.Heikki Linnakangas2017-07-12
| | | | | | | | | | | | | | | | Commit 14e8803f1 removed the locking in SyncRepWaitForLSN, but that introduced a race condition, where SyncRepWaitForLSN might see syncRepState already set to SYNC_REP_WAIT_COMPLETE, but the process was not yet removed from the queue. That tripped the assertion, that the process should no longer be in the uqeue. Reorder the operations in SyncRepWakeQueue to remove the process from the queue first, and update syncRepState only after that, and add a memory barrier in between to make sure the operations are made visible to other processes in that order. Fixes bug #14721 reported by Const Zhang. Analysis and fix by Thomas Munro. Backpatch down to 9.5, where the locking was removed. Discussion: https://www.postgresql.org/message-id/20170629023623.1480.26508%40wrigleys.postgresql.org
* Remove unnecessary braces, to match the surrounding style.Heikki Linnakangas2017-07-12
| | | | | | | | | Mostly in the new subscription-related commands. Backport the few that were also present in older versions. Thomas Munro Discussion: https://www.postgresql.org/message-id/CAEepm=3CyW1QmXcXJXmqiJXtXzFDc8SvSfnxkEGD3Bkv2SrkeQ@mail.gmail.com
* Fix multiple assignments to a column of a domain type.Tom Lane2017-07-11
| | | | | | | | | | | | | | | | | | | We allow INSERT and UPDATE commands to assign to the same column more than once, as long as the assignments are to subfields or elements rather than the whole column. However, this failed when the target column was a domain over array rather than plain array. Fix by teaching process_matched_tle() to look through CoerceToDomain nodes, and add relevant test cases. Also add a group of test cases exercising domains over array of composite. It's doubtless accidental that CREATE DOMAIN allows this case while not allowing straight domain over composite; but it does, so we'd better make sure we don't break it. (I could not find any documentation mentioning either side of that, so no doc changes.) It's been like this for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/4206.1499798337@sss.pgh.pa.us
* Stamp 10beta2.REL_10_BETA2Tom Lane2017-07-10
|
* Translation updatesAlvaro Herrera2017-07-10
| | | | | Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: c5a8de3653bb1af6b0eb41cc6bf090c5522df52b
* On Windows, retry process creation if we fail to reserve shared memory.Tom Lane2017-07-10
| | | | | | | | | | | | | | | We've heard occasional reports of backend launch failing because pgwin32_ReserveSharedMemoryRegion() fails, indicating that something has already used that address space in the child process. It's not very clear what, given that we disable ASLR in Windows builds, but suspicion falls on antivirus products. It'd be better if we didn't have to disable ASLR, anyway. So let's try to ameliorate the problem by retrying the process launch after such a failure, up to 100 times. Patch by me, based on previous work by Amit Kapila and others. This is a longstanding issue, so back-patch to all supported branches. Discussion: https://postgr.es/m/CAA4eK1+R6hSx6t_yvwtx+NRzneVp+MRqXAdGJZChcau8Uij-8g@mail.gmail.com
* Fix missing tag in the docs.Heikki Linnakangas2017-07-10
| | | | | | Masahiko Sawada Discussion: https://www.postgresql.org/message-id/CAD21AoBCwcTNMdrVWq8T0hoOs2mWSYq9PRJ_fr6SH8HdO+m=0g@mail.gmail.com
* Fix check for empty hostname.Heikki Linnakangas2017-07-10
| | | | | | | As reported by Arthur Zakirov, Gcc 7.1 complained about this with -Wpointer-compare. Discussion: https://www.postgresql.org/message-id/CAKNkYnybV_NFVacGbW=VspzAo3TwRJFNi+9iBob66YqQMZopwg@mail.gmail.com
* Fix COPY's handling of transition tables with indexes.Andrew Gierth2017-07-10
| | | | | | | | | Commit c46c0e5202e8cfe750c6629db7852fdb15d528f3 failed to pass the TransitionCaptureState object to ExecARInsertTriggers() in the case where it's using heap_multi_insert and there are indexes. Repair. Thomas Munro, from a report by David Fetter Discussion: https://postgr.es/m/20170708084213.GA14720%40fetter.org
* Allow multiple hostaddrs to go with multiple hostnames.Heikki Linnakangas2017-07-10
| | | | | | | | | | | | | | | Also fix two other issues, while we're at it: * In error message on connection failure, if multiple network addresses were given as the host option, as in "host=127.0.0.1,127.0.0.2", the error message printed the address twice. * If there were many more ports than hostnames, the error message would always claim that there was one port too many, even if there was more than one. For example, if you gave 2 hostnames and 5 ports, the error message claimed that you gave 2 hostnames and 3 ports. Discussion: https://www.postgresql.org/message-id/10badbc6-4d5a-a769-623a-f7ada43e14dd@iki.fi
* Doc: remove claim that PROVE_FLAGS defaults to '--verbose'.Tom Lane2017-07-10
| | | | | | Commit e9c81b601 changed this, but missed updating the documentation. The adjacent claim that we use TAP tests only in src/bin seems pretty obsolete as well. Minor other copy-editing.
* Doc: clarify wording about tool requirements in sourcerepo.sgml.Tom Lane2017-07-10
| | | | | | | | | Original wording had confusingly vague antecedent for "they", so replace that with a more repetitive but clearer formulation. In passing, make the link to the installation requirements section more specific. Per gripe from Martin Mai, though this is not the fix he initially proposed. Discussion: https://postgr.es/m/CAN_NWRu-cWuNaiXUjV3m4H-riWURuPW=j21bSaLADs6rjjzXgQ@mail.gmail.com
* Doc: desultory copy-editing for v10 release notes.Tom Lane2017-07-09
| | | | | Improve many item descriptions, improve markup, relocate some items that seemed to be in the wrong section.
* Doc: update v10 release notes through today.Tom Lane2017-07-09
|
* Doc: fix backwards description of visibility map's all-frozen data.Tom Lane2017-07-09
| | | | | | | | Thinko in commit a892234f8. Vik Fearing Discussion: https://postgr.es/m/b6aaa23d-e26f-6404-a30d-e89431492d5d@2ndquadrant.com
* MSVC: Repair libpq.rc generator.Noah Misch2017-07-09
| | | | | | It generates an empty file, so libpq.dll advertises no version information. Commit facde2a98f0b5f7689b4e30a9e7376e926e733b8 mistranslated "print O;" in this one place.
* Avoid unreferenced-function warning on low-functionality platforms.Tom Lane2017-07-08
| | | | | | | On platforms lacking both locale_t and ICU, collationcmds.c failed to make any use of its static function is_all_ascii(), thus probably drawing a compiler warning. Oversight in my commit ddb5fdc06. Per buildfarm member gaur.
* Fix typoAlvaro Herrera2017-07-07
| | | | Noticed while reviewing code.
* Fix out of date commentMagnus Hagander2017-07-07
| | | | Author: Masahiko Sawada <sawada.mshk@gmail.com>
* Fix potential data corruption during freezeTeodor Sigaev2017-07-06
| | | | | | | Fix oversight in 3b97e6823b94 bug fix. Bitwise AND is used instead of OR and it cleans all bits in t_infomask heap tuple field. Backpatch to 9.3
* Clarify the contract of partition_rbound_cmp().Dean Rasheed2017-07-06
| | | | | | | | | | | | | | | | | | | | | partition_rbound_cmp() is intended to compare range partition bounds in a way such that if all the bound values are equal but one is an upper bound and one is a lower bound, the upper bound is treated as smaller than the lower bound. This particular ordering is required by RelationBuildPartitionDesc() when building the PartitionBoundInfoData, so that it can consistently keep only the upper bounds when upper and lower bounds coincide. Update the function comment to make that clearer. Also, fix a (currently unreachable) corner-case bug -- if the bound values coincide and they contain unbounded values, fall through to the lower-vs-upper comparison code, rather than immediately returning 0. Currently it is not possible to define coincident upper and lower bounds containing unbounded columns, but that may change in the future, so code defensively. Discussion: https://postgr.es/m/CAAJ_b947mowpLdxL3jo3YLKngRjrq9+Ej4ymduQTfYR+8=YAYQ@mail.gmail.com
* Simplify the logic checking new range partition bounds.Dean Rasheed2017-07-06
| | | | | | | | | | | | | | | | The previous logic, whilst not actually wrong, was overly complex and involved doing two binary searches, where only one was really necessary. This simplifies that logic and improves the comments. One visible change is that if the new partition overlaps multiple existing partitions, the error message now always reports the overlap with the first existing partition (the one with the lowest bounds). The old code would sometimes report the clash with the first partition and sometimes with the last one. Original patch idea from Amit Langote, substantially rewritten by me. Discussion: https://postgr.es/m/CAAJ_b947mowpLdxL3jo3YLKngRjrq9+Ej4ymduQTfYR+8=YAYQ@mail.gmail.com
* Fix another race-condition-ish issue in recovery/t/001_stream_rep.pl.Tom Lane2017-07-05
| | | | | | | | | | | | | | | | | | | | | | | Buildfarm members hornet and sungazer have shown multiple instances of "Failed test 'xmin of non-cascaded slot with hs feedback has changed'". The reason seems to be that the test is checking the current xmin of the master server's replication slot against a past xmin of the first slave server's replication slot. Even though the latter slot is downstream of the former, it's possible for its reported xmin to be ahead of the former's reported xmin, because those numbers are updated whenever the respective downstream walreceiver feels like it (see logic in WalReceiverMain). Instrumenting this test shows that indeed the slave slot's xmin does often advance before the master's does, especially if an autovacuum transaction manages to occur during the relevant window. If we happen to capture such an advanced xmin as $xmin, then the subsequent wait_slot_xmins call can fall through before the master's xmin has advanced at all, and then if it advances before the get_slot_xmins call, we can get the observed failure. Yeah, that's a bit of a long chain of deduction, but it's hard to explain any other way how the test can get past an "xmin <> '$xmin'" check only to have the next query find that xmin does equal $xmin. Fix by keeping separate images of the master and slave slots' xmins and testing their has-xmin-advanced conditions independently.
* Restore linking libpq into pg_ctl on Mingw builds.Tom Lane2017-07-05
| | | | Commit 1ae853654 missed this. Per Andrew Dunstan.
* Remove unnecessary pg_is_in_recovery calls in testsPeter Eisentraut2017-07-05
| | | | | Since pg_ctl promote already waits for recovery to end, these calls are obsolete.
* pg_ctl: Make failure to complete operation a nonzero exitPeter Eisentraut2017-07-05
| | | | | | If an operation being waited for does not complete within the timeout, then exit with a nonzero exit status. This was previously handled inconsistently.
* Fix output of char node fieldsPeter Eisentraut2017-07-05
| | | | | | | WRITE_CHAR_FIELD() didn't do any escaping, so that for example a zero byte would cause the whole output string to be truncated. To fix, pass the char through outToken(), so it is escaped like a string. Adjust the reading side to handle this.
* psql documentation fixesPeter Eisentraut2017-07-04
| | | | | | | | Update the documentation for \pset to mention columns|linestyle|pager_min_lines. Add various mentions of \pset command equivalences that were previously inconsistent. Author: Дилян Палаузов <dpa-postgres@aegee.org>
* Document how logical replication deals with statement triggersPeter Eisentraut2017-07-03
| | | | | Reported-by: Константин Евтеев <konst583@gmail.com> Bug: #14699
* Improve subscription lockingPeter Eisentraut2017-07-03
| | | | | | | This avoids "tuple concurrently updated" errors when a ALTER or DROP SUBSCRIPTION writes to pg_subscription_rel at the same time as a worker. Author: Petr Jelinek <petr.jelinek@2ndquadrant.com>
* Don't mention SSL methods that aren't reachable in docsMagnus Hagander2017-07-03
| | | | Author: Michael Paquier <michael.paquier@gmail.com>
* Treat clean shutdown of an SSL connection same as the non-SSL case.Heikki Linnakangas2017-07-03
| | | | | | | | | | If the client closes an SSL connection, treat it the same as EOF on a non-SSL connection. In particular, don't write a message in the log about that. Michael Paquier. Discussion: https://www.postgresql.org/message-id/CAB7nPqSfyVV42Q2acFo%3DvrvF2gxoZAMJLAPq3S3KkjhZAYi7aw@mail.gmail.com
* Forbid gen_random_uuid() with --disable-strong-randomHeikki Linnakangas2017-07-03
| | | | | | | | | | | | | | | Previously, gen_random_uuid() would fall back to a weak random number generator, unlike gen_random_bytes() which would just fail. And this was not made very clear in the docs. For consistency, also make gen_random_uuid() fail outright, if compiled with --disable-strong-random. Re-word the error message you get with --disable-strong-random. It is also used by pgp functions that require random salts, and now also gen_random_uuid(). Reported by Radek Slupik. Discussion: https://www.postgresql.org/message-id/20170101232054.10135.50528@wrigleys.postgresql.org
* Fix race condition in recovery/t/009_twophase.pl test.Tom Lane2017-07-02
| | | | | | | | | | | | | | | | | | | | Since reducing pg_ctl's reaction time in commit c61559ec3, some slower buildfarm members have shown erratic failures in this test. The reason turns out to be that the test assumes synchronous replication (because it does not provide any lag time for a commit to replicate before shutting down the servers), but it had only enabled sync rep in one direction. The observed symptoms correspond to failure to replicate the last committed transaction in the other direction, which can be expected to happen if the shutdown command is issued soon enough and we are providing no synchronous-commit guarantees. Fix that, and add a bit more paranoid state checking at the bottom of the script. Michael Paquier and myself Discussion: https://postgr.es/m/908.1498965681@sss.pgh.pa.us
* Fix bug in PostgresNode::query_hash's split() call.Tom Lane2017-07-02
| | | | | | | | | By default, Perl's split() function drops trailing empty fields, which is not what we want here. Oversight in commit fb093e4cb. We'd managed to miss it thus far thanks to the very limited usage of this function. Discussion: https://postgr.es/m/14837.1499029831@sss.pgh.pa.us
* Try to improve readability of recovery/t/009_twophase.pl test.Tom Lane2017-07-02
| | | | | | | | | | | | | | | | | | | | | The original coding here was very confusing, because it named the two servers it set up "master" and "slave" even though it swapped their replication roles multiple times. At any given point in the script it was very unobvious whether "$node_master" actually referred to the server named "master" or the other one. Instead, pick arbitrary names for the two servers --- I used "london" and "paris" --- and distinguish those permanent names from the nonce references $cur_master and $cur_slave. Add logging to help distinguish which is which at any given point. Also, use distinct data and transaction names to make all the prepared transactions easily distinguishable in the postmaster logs. (There was one place where we intentionally tested that the server could cope with re-use of a transaction name, but it seems like one place is sufficient for that purpose.) Also, add checks at the end to make sure that all the transactions that were supposed to be committed did survive. Discussion: https://postgr.es/m/28238.1499010855@sss.pgh.pa.us
* Improve TAP test function PostgresNode::poll_query_until().Tom Lane2017-07-02
| | | | | | | | | | | | | | | | | Add an optional "expected" argument to override the default assumption that we're waiting for the query to return "t". This allows replacing a handwritten polling loop in recovery/t/007_sync_rep.pl with use of poll_query_until(); AFAICS that's the only remaining ad-hoc polling loop in our TAP tests. Change poll_query_until() to probe ten times per second not once per second. Like some similar changes I've been making recently, the one-second interval seems to be rooted in ancient traditions rather than the actual likely wait duration on modern machines. I'd consider reducing it further if there were a convenient way to spawn just one psql for the whole loop rather than one per probe attempt. Discussion: https://postgr.es/m/12486.1498938782@sss.pgh.pa.us
* doc: Document that logical replication supports synchronous replicationPeter Eisentraut2017-07-02
| | | | | | Update the documentation a bit to include that logical replication as well as other and third-party replication clients can participate in synchronous replication.
* Refine memory allocation in ICU conversionsPeter Eisentraut2017-07-01
| | | | | | | | The simple calculations done to estimate the size of the output buffers for ucnv_fromUChars() and ucnv_toUChars() could overflow int32_t for large strings. To avoid that, go the long way and run the function first without an output buffer to get the correct output buffer size requirement.
generated by cgit v1.2.3 (git 2.25.1) at 2025-05-31 12:24:39 +0000