derably easier as well (no
> break and re-acquire when scrolling in a new page).
Hmm, indenting the descriptions a couple more spaces might be a workable
compromise. Anyone want to try that and see what it looks like?
Preferably somebody who's not happy with the current layout ;-)
fectly
machine-independent, even if you were hiding costs successfully.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <and...@anarazel.de> writes:
> Indeed that seems plausible. I guess something like the attached should
> fix the issue?
Ah, I see you came to the same conclusion I did. But see comment
about adding a comment.
regards, tom lane
--
Sent via p
n's comment could use adjustment).
Andres?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ed), maybe that should happen.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Kuntal Ghosh <kuntalghosh.2...@gmail.com> writes:
> On Tue, Sep 12, 2017 at 9:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Aleksander Alekseev <a.aleks...@postgrespro.ru> writes:
>>> The following review has been posted through the commitfest application:
variable descriptions.
This proposes to make the vertical space nearly triple what it was in v10.
In a typical-size window that's going to have a pretty severe impact on
how much of the list you can see at once. And the readability gain is
(at least to my eyes) very marginal.
rect
value for pd_lower on that page. This has to be coped with.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I wrote:
> Attached is a patch series that allows us to create arrays of domain
> types.
Here's a rebased-up-to-HEAD version of this patch set. The only
actual change is removal of a no-longer-needed hunk in pl_exec.c.
regards, tom lane
diff --git a/src/b
Thomas Munro <thomas.mu...@enterprisedb.com> writes:
> On Wed, Sep 13, 2017 at 2:34 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org>
> wrote:
>> Tom Lane wrote:
>>> Can you clarify what went wrong for you on that one? I went to rebase it,
>>> but I end up
s out that PQcmdTuples() is not an amazingly cheap function.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Chapman Flack <c...@anastigmatix.net> writes:
> On 09/12/2017 03:41 PM, Tom Lane wrote:
>> So the conclusion at the end of the last commitfest was that this patch
>> should be marked Returned With Feedback, and no new work appears to have
>> been done on it since th
[ changing subject line to possibly draw more attention ]
Mark Dilger <hornschnor...@gmail.com> writes:
>> On Apr 5, 2017, at 9:23 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> In short, if you are supposed to write
>> FOO *val = PG_GETARG_FOO(n);
>> then
at will break all four options,
it's not very obvious why not.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t.
It could be as simple as putting the check-for-done at the bottom of the
loop not the top, perhaps.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
sn't get a SQLSTATE from the PGresult, it should just set the
sqlstate variables to empty strings.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Sep 12, 2017 at 1:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> The trick here is that I don't think we want to change the returned column
>> types for queries that are not being sent to a client. The parser and
>
oesn't sound great
to me. Especially when you've not provided any hard evidence as to why
the current lack-of-information is useful.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
st one transaction
per thread, I'd rather the test not assume that.
I would not necessarily object to doing something in the code that
would guarantee that, though.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
an assumption that we'll never
have any built-in domains just to support such a crock as this.
> 1. Revisit the decision to smash domain types to base types here.
> That change was made by Tom Lane back in 2003
> (d9b679c13a820eb7b464a1eeb1f177c3fea13ece) but the commit message only
> says
w enough to start up that it doesn't get to run
any transactions? IOW, do we need to allow 0 to 3 lines?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
intermediate between two PG major releases. Only
if your patch doesn't get in by v11 freeze would you need to make it a
separate citext--1.5--1.6.sql script.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
on:tested, passed
> Also I didn't manage to find any typos or obvious mistakes in the code.
Thanks for reviewing! I assume this is against the prior version of the
patch, though, not the one I just posted with updates for contrib.
Do you want to look at those?
. Is this a pgbench bug, or is the test
being overoptimistic about how exact the "-T 2" cutoff is?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
ou've got the rest of the week ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e. Updating pg_stat_activity is a lot more common
> than reading it.
+1. I kinda doubt that it is worth optimizing further than that,
really.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera <alvhe...@alvh.no-ip.org> writes:
> Tom Lane wrote:
>> Aleksander Alekseev <a.aleks...@postgrespro.ru> writes:
>>> === Apply Failed: 29 ===
>>> https://commitfest.postgresql.org/14/1235/ (Support arrays over domain
>>> types)
>&g
Here's an updated version of this patch that is rebased against HEAD
(no changes there except line numbers) and adds the necessary updates
for contrib.
I'd like to get this committed fairly soon before it bit-rots.
Anyone want to review it?
regards, tom lane
diff --git
://commitfest.postgresql.org/14/1235/ (Support arrays over domain types)
Can you clarify what went wrong for you on that one? I went to rebase it,
but I end up with the identical patch except for a few line-numbering
variations.
regards, tom lane
--
Sent via pgsql-hack
This patch no longer applies cleanly on HEAD, so here's a rebased version
(no substantive changes). As before, I think the most useful review task
would be to quantify whether it makes planning noticeably slower.
regards, tom lane
diff --git a/src/backend/optimizer/util
Jim Nasby <jim.na...@openscg.com> writes:
> I've verified that the patch still applies and make check-world is clean.
Not any more :-(. Here's a v3 rebased over HEAD. No substantive
change from v2.
regards, tom lane
diff --git a/src/backend/nodes/outfunc
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Mon, Sep 11, 2017 at 11:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Hm, I don't much like having it silently ignore files that are present;
>> that seems like a foot-gun in the long run. What do y
elay.
I don't see this pushed to the repo?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On 11 September 2017 at 23:19, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Uh, what? Sure you can. Just because the existing code never has a
>> reason to create such a dependency doesn't mean it wouldn't work.
>
.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
code never has a
reason to create such a dependency doesn't mean it wouldn't work.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
uments. Still, I follow the point that when there are a lot of
arguments, $n is pretty unhelpful. We can always revert this if
we get complaints.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
an I add a special SQLSTATE for that
> situation where libpq did not report an error?
Meh. If we're going to do that I think it might be better to hack
libpq itself to do so, ie, force PQresultErrorField(..., PG_DIAG_SQLSTATE)
to always return something. But it seems like a hack either way.
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> On 09/08/2017 09:40 AM, Tom Lane wrote:
>> Like you, I'm a bit worried about the code for extracting an exit
>> status from IPC::Run::run. We'll have to keep an eye on the buildfarm
>> for a bit. If there's a
pper-case TRUE/FALSE for the values of ERROR seems a bit
ugly to me; we generally use lower case for other variable values,
so I'd go with true/false.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Sun, Sep 10, 2017 at 12:38 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> The specific case we need to allow is "ENOENT on a file/dir that was
>> there a moment ago". I think it still behooves us to com
be run.
Robert's original LET ... IN ... syntax proposal might be better from that
standpoint.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
be in read-write storage.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
rfinish call, it might help narrow things down.
Offhand my bet is on mysql_fdw needing an update for some PG10
change, but that's just a guess.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
e
ECC memory, though. Race condition against some updater? But the file
is only 512 bytes, and we've always assumed that that size of disk
read or write is atomic. (Platform is RHEL6/x86_64, kernel is
Red Hat 2.6.32-696.10.1.el6.x86_64.)
regards, tom lane
--
Sent via pgsql-
nce.) Is it worth
adding logic for that? Not sure. It's not like we are actively
changing the RB code or have reason to think it is buggy.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
btree as well.
FWIW, now that we've noticed the discrepancy, I'm for using
REGBUF_STANDARD or equivalent for all metapage calls. Even if it
saves no space, inconsistency is bad because it's confusing. And
Michael is correct to point out that we can exploit this to
improve WAL consistency checkin
with their support code, and then drop the portions of
test_rbtree that are needed to exercise them. Any objections?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
nows that a leaf element points to itself.
We could dispense with rb_root(), as well as the test code's knowledge
about RBNIL representation, if we dropped the preorder/postorder cases
... which is another good reason to do so.
regards, tom lane
diff --git a/src/backend
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Sat, Sep 9, 2017 at 1:43 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Yeah, even if we fixed this particular call site, I'm sure the issue
>> would come up again. Certainly we expect hot backups to work with
>
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Fri, Sep 8, 2017 at 5:24 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> In short, this patch needs a significant rewrite, and more analysis than
>> you've done so far on whether there's actually any benefi
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Sat, Sep 9, 2017 at 11:32 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> In a moment of idleness I tried to run the TAP tests on pademelon,
>> which is a mighty old and slow machine.
> How long did it take?
y" or "we need to fix the callers to not call RecursiveCopy
until the source directory is stable". Thoughts?
(I do kinda wonder why we rolled our own RecursiveCopy; surely there's
a better implementation in CPAN?)
regards, tom lane
--
Sent via pgsql-hackers mailing
early 80. I don't buy that that's not a significant
difference. It's also much less ugly if you decide you need one more
line than the English version uses.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
any of the
PLs; their notions of statement blocks all differ from whatever we might
think that is at the interactive-SQL-command level.
(2) AIUI the feature request is specifically for a single-statement
variable change, not any larger scope than that.
regards, tom lane
--
Sent vi
d to be as long as they lead off the statement. But this
proposal would break that. We need to put FOR or IN or another
already-fully-reserved keyword after the SET list, or something's going
to bite us.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Bruce Momjian <br...@momjian.us> writes:
> On Wed, Jul 19, 2017 at 12:39:07PM -0400, Tom Lane wrote:
>> Yeah, I see nothing about 3f902354b in release-10.sgml either.
>> We've had varying policies over the years about whether to mention
>> internal API c
would be; but now that we're actually
documenting how to script multi-command queries, it might be
a good idea to fix it before too many people have scripts that
rely on the current behavior.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
see subject.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
uble, I'd be inclined to drop it down
to just success/fail rather than checking the exact exit code.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ndent
sections of the config file, instead of some common and some library-
specific parameters.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs <si...@2ndquadrant.com> writes:
> On 7 September 2017 at 11:31, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Haas' idea of some kind of syntactic extension, like "LET guc1 = x,
>> guc2 = y FOR statement" seems more feasible to me. I'm not necessaril
Simon Riggs <si...@2ndquadrant.com> writes:
> On 7 September 2017 at 11:24, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Not hearing anything, I already pushed my patch an hour or three ago.
> Yes, I saw. Are you saying that doc commit is all we need? ISTM we
> still had an
I wrote:
> Dmitriy Sarafannikov <dsarafanni...@yandex.ru> writes:
>> [ snapshot_non_vacuumable_v3.patch ]
> In short I think we should just set up the threshold as RecentGlobalXmin.
Pushed with that adjustment and some fooling with the comments.
d arrange for
HeapTupleSatisfiesNonVacuumable to use RecentGlobalXmin directly,
but that seems like it makes it too special-purpose.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
d more analysis than
you've done so far on whether there's actually any benefit to be gained.
It might not be worth messing with.
I'll set the CF entry back to Waiting on Author.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 9/5/17 15:32, Tom Lane wrote:
>> I do agree with the idea that we should use the * notation in cases where
>> the reader might otherwise think that a plain function was being invoked,
>> ie I don't like
&g
ement construct of some kind.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs <si...@2ndquadrant.com> writes:
> On 5 September 2017 at 10:22, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Does anyone want to do further review on this patch? If so, I'll
>> set the CF entry back to "Needs Review".
> OK, I'll review Micha
el free to suggest improvements.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ything in ecpg, IMO.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On 31 August 2017 at 14:49, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> pgbench with log_statement = all would be a pretty easy test case.
> It seems that for this particular workload it was about 20-25% slower.
Ouch. Tha
Catalin Iacob <iacobcata...@gmail.com> writes:
> On Mon, Sep 4, 2017 at 4:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Also, the main thing that we need xact.c's involvement for in the first
>> place is the fact that implicit transaction blocks, unlike regular ones,
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Thu, Sep 7, 2017 at 5:49 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I looked briefly at these patches. I'm not sure that it's safe for the
>> mask functions to assume that meta pages always have valid pd_
* the Julian-date code can allow. We use that same limit for timestamps when
* using floating-point timestamps ... For integer timestamps, the upper
* limit is 294276-12-31.
I would hope that any timestamps you've got beyond 294276AD are erroneous
data that you need to clean up anyway.
hough that's
a bit outside the scope of testing traversal, so if you want to leave
it for some future expansion, that'd be OK.
I'll set this back to Waiting on Author. I do encourage you to finish
it up.
regards, tom lane
--
Sent via pgsql-hackers mailing list (p
Tatsuro Yamada <yamada.tats...@lab.ntt.co.jp> writes:
> The declaration of postgresGetForeignPlan uses baserel, but
> the actual definition uses foreignrel. It would be better to sync.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing
ogrammer.html#nls-guidelines
Usually we just use two independent messages, and that's what I did.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
old index that doesn't
have that field filled?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Sep 6, 2017 at 3:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I'm not entirely following. I thought that add_path was set up to treat
>> "can be parallelized" as an independent dimension of merit, s
_atomic_read_u32_impl and
pg_atomic_read_u64_impl, and recompiled. I get bit-for-bit the
same backend executable. Maybe it would have an effect on some
other compiler, but I doubt it, except perhaps at -O0.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
void generating gather paths until
> after we've applied the target list (and the associated costing
> changes) to both the regular path list and the partial path list.
Might be a tad messy to rearrange things that way.
regards, tom lane
--
Sent via pgsql-hackers ma
Andres Freund <and...@anarazel.de> writes:
> On 2017-09-06 15:25:20 -0400, Tom Lane wrote:
>> I think we can just use "old = ptr->value" to set up for the cmpxchg
>> loop in every generic.h function that uses such a loop.
> I think we might have been talking
Andres Freund <and...@anarazel.de> writes:
> On 2017-09-06 15:12:13 -0400, Tom Lane wrote:
>> It looks to me like two of the three implementations promise no such
>> thing.
> They're volatile vars, so why not?
Yeah, but so are the caller's variables. That is, in
pg_
Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Sep 6, 2017 at 1:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> If somebody's applying apply_projection_to_path to a path that's already
>> been add_path'd, that's a violation of the documented restriction.
Andres Freund <and...@anarazel.de> writes:
> On 2017-09-06 14:31:26 -0400, Tom Lane wrote:
>> However, if that's the reasoning, why don't we make all of these
>> use simple reads? It seems unlikely that a locked read is free.
> We don't really use locked reads? All the
n't think "yes, it really works" is a helpful use of documentation
space.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a comment explaining why.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
y of
the cost estimates.
> I'd feel a lot happier if Tom were to decide how this ought to be
> fixed, because - in spite of some modifications by various parallel
> query code - this is basically all his design and mostly his code.
I can take a look, but not right away.
Simon Riggs <si...@2ndquadrant.com> writes:
> Other than that, I'm good to commit.
> Any last minute objections?
The docs and comments could stand a bit closer copy-editing by a
native English speaker. Other than that, it seemed sane in a
quick read-through.
s there are likely to buy
much more.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ussed about whether PQserverVersion worked correctly
for ancient server versions back then than we need be today.)
> * Clarification to avoid confusion between VERSION and SERVER_VERSION
In what way are these variables not adequately specified already?
regards, tom lane
--
y performance-critical then we should be
looking for better ways.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
etrieving plans from the cache,
and changes in their values from one retrieval to the next might
cause funny behavior. Maybe the relevant settings need to be captured
when the plancache entry is made ... not sure.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pg
k" in src/bin/ when TAP tests are
> enabled, which should be enough to trigger the rewritten test, no?
I think Peter's on about the Windows case. Not sure how that's handled,
but it's not "make check".
regards, tom lane
--
Sent via pgsql-hackers mail
Simon Riggs <si...@2ndquadrant.com> writes:
> Based upon input from Tom and Fabien, I propose this additional doc patch.
I do not think any of this is appropriate, particularly not the reference
to 7.0.3.
regards, tom lane
--
Sent via pgsql-hackers mailing li
Sokolov Yura <funny.fal...@postgrespro.ru> writes:
> On 2017-09-06 15:56, Tom Lane wrote:
>> The point I'm trying to make is that if tweaking generic.h improves
>> performance then it's an indicator of missed cases in the less-generic
>> atomics code, and the latter is
Simon Riggs <si...@2ndquadrant.com> writes:
> Why isn't this an open item for PG10?
Why should it be? This behavior has existed for a long time.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
Simon Riggs <si...@2ndquadrant.com> writes:
> On 5 September 2017 at 21:23, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Moreover, it matters which primitive you're testing, on which platform,
>> with which compiler, because we have a couple of layers of at
401 - 500 of 46745 matches
Mail list logo
