Alvaro Herrera writes:
> Fixed the pstrdup problem by replacing with strlcpy() to stack-allocated
> variables (rather than palloc + memcpy as proposed in Michael's patch).
+1
> Tom Lane wrote:
>> I don't especially like the Asserts inside spinlocks, either.
> I didn
fy the
comment a bit 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
Magnus Hagander writes:
> On Tue, Oct 3, 2017 at 6:33 AM, Tom Lane wrote:
>> I'm not an SSL expert, so insert appropriate grain of salt, but AIUI the
>> question is what are you going to verify against?
> One way to do it would be to default to the "system global ce
sult.
Presumably somebody could dig into the libc source code and prove or
disprove this, though it would sure help to know exactly what platform
and version Andreas is testing on.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
iable,
so I'm not sure it would really add any security.
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
ever been supported.
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 writes:
> On 2017-10-02 19:50:51 -0400, Tom Lane wrote:
>> What I saw was that the backend process was consuming 100% of (one) CPU,
>> while the I/O transaction rate viewed by "iostat 1" started pretty low
>> --- under 10% of what the machine is
Andres Freund writes:
> On 2017-10-02 18:33:17 -0400, Tom Lane wrote:
>> I'm kind of surprised that machine B doesn't show obvious tanking in this
>> test given that msync() makes it suck so badly at copying a database.
>> I wonder what is different from the ke
__darwin__
pg_flush_data(dstfd, offset, nbytes);
+#endif
but I don't see any better alternative ...
regards, tom lane
progress: 1.0 s, 8132.9 tps, lat 0.978 ms stddev 0.434
progress: 2.0 s, 8841.0 tps, lat 0.905 ms stddev 0.260
progress: 3.0 s, 9020.1 tps, lat
e prototype code I posted further upthread just used -1 as the "unused"
marker. There's no reason the array can't be int16 rather than uint16,
and "if (index < 0)" is probably a faster test anyway.
regards, tom lane
--
Sent via pgsql-
x27;s completely unsafe. If it isn't,
why is it being kept in shared memory?
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 writes:
> On 2017-10-02 17:30:25 -0400, Tom Lane wrote:
>> Or replace the spinlock with an LWLock?
> That'd probably be a good idea, but I'm loathe to do so in the back
> branches. Not at this callsite, but some others, there's some potential
> for
er bit, so that it's a 63-bit ID?
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
other critical section touching that lock
to see if there are any other blatant coding-rule violations.
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 writes:
> On 2017-10-02 15:54:43 -0400, Tom Lane wrote:
>> Should I expect there to be any difference at all? We don't enable
>> *_flush_after by default on non-Linux platforms.
> Right, you'd have to enable that. But your patch would neuter an
> i
Andres Freund writes:
> On 2017-10-02 15:42:25 -0400, Tom Lane wrote:
>> I experimented with this further by seeing whether the msync() code path
>> is of any value on Sierra either. The answer seems to be "no": cloning
>> a scale-1000 pgbench database takes a
n tell from the thread, only testing on FreeBSD ever
got done. So there's no evidence that this was ever beneficial on macOS,
and we now have evidence that it's between counterproductive and
catastrophic depending on which kernel version you look at.
regards,
here might be any other
> difference besides performance characteristics. The answer to that is,
> I think, "no".
What about non-immutable functions in the generation expression?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
0644
--- a/src/backend/storage/file/fd.c
+++ b/src/backend/storage/file/fd.c
@@ -451,7 +451,7 @@ pg_flush_data(int fd, off_t offset, off_t nbytes)
return;
}
#endif
-#if !defined(WIN32) && defined(MS_ASYNC)
+#if 0
{
void *p;
static int pagesize = 0;
Robert Haas writes:
> On Mon, Oct 2, 2017 at 12:28 PM, Tom Lane wrote:
>> I'm not sure if that's true or not. I am sure, though, that since
>> we've done B for twenty years we can't just summarily change to A.
> I agree, but so what? You said that we coul
Robert Haas writes:
> On Tue, Sep 19, 2017 at 3:18 PM, Tom Lane wrote:
>> That's certainly a case that we ought to support somehow. The problem is
>> staying reasonably consistent with the two-decades-old precedent of the
>> existing behavior for one target variabl
#x27;s needed to keep things moving.
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
-domains patch).
regards, tom lane
diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c
index 7961362..c3fab75 100644
*** a/src/backend/optimizer/util/clauses.c
--- b/src/backend/optimizer/util/clauses.c
*** static List *find_nonnullable_vars_wal
w and document
> ABRT. There's no meaningful difference between the two.
True.
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
hat eqjoinsel_semi has been more or less a constant source of
issues, maybe we need to think about a wholesale redesign rather than
just incremental tweaking. But I have few ideas about what would be
better.
regards, tom lane
--
Sent via pgsql-hackers mailing lis
tests, but it still seems like something we don't want
to encourage users to use. What do you think of leaving it out of the
documentation?
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
se-case, because
it immediately leads to the conclusion that we need to promise stability
of query IDs across PG versions, which seems entirely infeasible to me
(at least with anything like the current method of deriving them).
regards, tom lane
--
Sent via pgsql-hackers
configure --with-extra-version=whateveryouwant
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
ble and then remaking it attached to the new server.
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
Noah Misch writes:
> On Sat, Sep 30, 2017 at 11:25:43AM -0400, Tom Lane wrote:
>> Sure, but dealing with that is mechanical: reindex the necessary indexes
>> and you're done.
> In the general case, one must revalidate CHECK constraints, re-partition
> tables, revalidate
y programmers
build programs, the first woodpecker to come along would destroy
civilization".
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 identifiable indexes and you're done". In the libc world,
when you upgrade libc's locale definitions, you have no idea what the
consequences are.
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
on icu-devel.
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
ving said --with-icu,
I'd be very interested to see how.
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
ols. I'd be a little wary of #ifdef checks in any file you're
about to remove it from, though, as those could mask any obvious
breakage.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Robert Haas writes:
> How about widening the value to uint64?
Doesn't really seem like that would guarantee no collisions.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
here's also not really a pressing need.
We certainly mustn't encourage libpq users to start depending on c.h,
so let's leave that alone.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
Robert Haas writes:
> On Fri, Sep 29, 2017 at 12:43 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> If I understand correctly, problem #1 is that get_rel_oids() can emit
>>> a user-visible cache lookup failure message. There is a proposed patch
>>> by Michae
principle we could support this, I suppose.
Not sure if it's useful enough to be worth the trouble.
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
Andrew Dunstan writes:
> On 09/28/2017 05:44 PM, Tom Lane wrote:
>> Assuming that that's going to happen for v11, I'm inclined to leave the
>> optimization problem until the dust settles around CaseTestExpr.
>> Does anyone feel that this can't be committed bef
of committing the patch to allow VACUUM to mention
> multiple tables, which Tom has indicated he will handle.
I think the conclusion was that this wouldn't actually happen in v10,
but I will take a closer look and do something about it if it is possible.
regar
e rest --- certainly that's true
for btree, for example. I do not think it's a showstopper if that's
true for hash as well.
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 changing the logging behavior, you can resubmit that as a new
patch in a new thread where it will get some visibility and debate on
its own merits.
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 writes:
> On 2017-09-28 18:39:03 -0400, Tom Lane wrote:
>> + * Note: the reason for using a temporary variable "d", here
>> and in
>> + * other places, is that some compilers think "*op->resvalue =
>> f();&quo
Andres Freund writes:
> On 2017-09-28 18:52:28 -0400, Tom Lane wrote:
>> Uh, what? Access to fmgr_nbuiltins shouldn't be part of any critical path
>> anymore after this change.
> Indeed. But the size of the the oid -> fmgr_builtins index array is
> relevant now.
hich fmgr.c could be aware is of size
exactly "FirstBootstrapObjectId" entries.
> Is this roughly what you were thinking of?
I think you need the "no entry" values to be -1; 0 is a valid index
into the fmgr table.
regards, tom lane
--
Sent via pgsql
Andres Freund writes:
> On 2017-09-28 16:21:34 -0400, Tom Lane wrote:
>> We could save a pointless register spill
>> and reload if there were a temporary variable in there,
> Makes sense. Do you want to make it so, or shall I?
I just finished testing a patch, as attached. On
Andrew Dunstan writes:
> On 09/28/2017 01:11 PM, Tom Lane wrote:
>>> I wonder if we need to do any benchmarking to assure ourselves that the
>>> changes to ArrayCoerceExpr don't have a significant performance impact?
>> That would likely be a good idea, though I&#
EEO_NEXT();
}
and likewise in the other FUNCEXPR cases.
This is on a rather old gcc, haven't checked on bleeding-edge versions.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Andrew Dunstan writes:
> On 09/28/2017 01:02 PM, Tom Lane wrote:
>>> I do think that treating a function returning a domain-over-composite
>>> differently from one returning a base composite is a POLA. We'd be very
>>> hard put to explain the reasons for it
ash method,
because the former are going to suffer fewer cache misses that way.
But I don't see a randomized lookup order changing the conclusion much.
regards, tom lane
#include "postgres.h"
#include "fmgr.h"
#include "access/transam.h&qu
Marko Tiikkaja writes:
> On Wed, Sep 27, 2017 at 5:45 PM, Tom Lane wrote:
>> Looking at it another way, the main thing that the combination of hashagg
>> outer path + indexscan inner path knows that eqjoinsel_semi didn't account
>> for is that there's a unique ind
Andrew Dunstan writes:
> On 08/11/2017 01:17 PM, Tom Lane wrote:
>> Attached is a patch series that allows us to create arrays of domain
>> types.
> I've reviewed and tested the updated versions of these patches. The
> patches apply but there's a
Andrew Dunstan writes:
> On 07/13/2017 03:19 PM, Tom Lane wrote:
>> Attached is a draft patch that allows domains over composite types.
>> I think it's probably complete on its own terms, but there are some
>> questions around behavior of functions returning domain-ov
rs that only do work
>if necessary.
Could we please not perpetuate the brain-dead "s" and "l" suffixes
on these names? Given the lack of standardization as to how long
"long" is, that's entirely unhelpful. I'd be fine with names like
pg_ntoh16/32/64
and this problem will go away quickly.
Just putting out a heads-up that there's something to worry about here.
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 writes:
> On 2017-09-27 15:06:15 -0400, Tom Lane wrote:
>> Yeah, constructing an index table of that sort on top of the existing
>> FmgrBuiltin array could be done cheaply enough at startup. It irks me
>> slightly that it's not part of the read-only text s
Andres Freund writes:
> On 2017-09-27 14:58:36 -0400, Tom Lane wrote:
>> Yeah, I'd been kind of wondering about that approach too. We could have,
>> say, a table of int16s indexed by OIDs from 0 to , containing zero or
>> an index into the table of FmgrBuiltin s
x into the table of FmgrBuiltin structs. So 2 bytes of
constant data, and O(negligible) lookup time other than possible cache
misses on this table. But a dynahash-ish hash table built for 2800+
entries would probably be about that size ...
regards, tom lane
--
Sent v
no overhead in practice. I concur
that the idea of marking the relevant functions parallel-restricted is
probably not as safe a fix as I originally thought, and it's not a
very desirable restriction even if it did fix the problem.
regards, tom lane
--
Sent via p
Andres Freund writes:
> On 2017-09-27 13:46:50 -0400, Tom Lane wrote:
>> The other question that ought to be answered is whether a gperf hash
>> table would be faster.
> Ugh, hacking together a quick input file for gperf, I'm *far* from
> convinced. The generated cod
Andres Freund writes:
> On 2017-09-27 11:50:56 -0400, Tom Lane wrote:
>> Robert Haas writes:
>>> I suppose an even better approach would be to build a perfect hash
>>> table at compile time so that nothing needs to be built at run-time at
>>> all, but
how
much of the index you have to search. Even btree works that way for
many combinations of incomplete index constraints.
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
brute-force answer.
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
er setting nd2 = size of inner rel,
we'd end up with an estimate matching the product of these path sizes.
(Caution: inadequate caffeine absorbed yet, this might be all wrong.)
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
Kohei KaiGai writes:
> Does it make sense to put a check of "isinf(val)" and ereport prior to
> the snprintf()?
Yeah, that was my reaction too. Obviously this wasn't thought about
in the original coding ...
regards, tom lane
--
Sent via pgsql
Robert Haas writes:
> On Tue, Sep 26, 2017 at 7:18 PM, Tom Lane wrote:
>> It's not simple, particularly not if you wish that the index would support
>> queries specifying conditions for just a subset of the indexed columns
>> (an assumption that's buried pretty
27;t work that way for me on RHEL6, which surely oughta
behave the same as your CentOS.
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
conditions for just a subset of the indexed columns
(an assumption that's buried pretty deeply in the planner, for one thing).
Then you couldn't compute the hash.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
Jeff Janes writes:
> On Tue, Sep 26, 2017 at 1:10 PM, Tom Lane wrote:
>> Really? The server should have detached itself from your terminal
>> group long before that. What platform is this?
> CentOS release 6.9 (Final)
Hm, same as here. Are you perhaps not using pg_ctl&#
ard thing to do.
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
Bruce Momjian writes:
> On Tue, Sep 26, 2017 at 04:07:02PM -0400, Tom Lane wrote:
>> Any other votes out there?
> Well, I was concerned yesterday that we had a broken build farm so close
> to release. (I got consistent regression failures.) I think PG 11 would
> be bette
nd kills the successfully started-and-running
> server.
Really? The server should have detached itself from your terminal
group long before that. What platform is this?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Andrew Dunstan writes:
> On 09/26/2017 02:37 PM, Tom Lane wrote:
>> ... and the buildfarm's not too happy. It looks like force_parallel_mode
>> breaks all the regression test cases around unsafe enums; which on
>> reflection is unsurprising, because parallel workers
it this time is the source of Jeff's
surprise.
Also, what would you check exactly? Inquiring into what
"postgres --version" returns is not very conclusive about what is
actually running in the data directory pg_ctl has been pointed at.
regards, tom lane
--
is that maybe the existence of a blacklist hash should
be enough to turn off parallel mode altogether ... but ugh.
Or maybe we're back to "revert the whole feature, go back to 9.6
behavior".
Thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing list (
esn't mention EINTR as a possible failure,
I see that's been corrected in later editions.) If not, we should
at least get a better fix on the nature of the failure with this
patch. Awaiting buildfarm results ...
regards, tom lane
--
Sent via pgsql-hackers mailing list
ME TYPE
rather than ALTER OWNER in the test cases requiring an updated pg_type
row. That way we don't need to create a role, even a transient one, which
is a good thing in terms of not risking collisions with other sessions.
regards, tom lane
--
Sent via pgsql-hackers maili
Thomas Munro writes:
> I think the problem here is that posix_fallocate() doesn't set errno.
Huh. So the fact that it worked for me is likely because glibc's
emulation *does* allow errno to get set.
> Will write a patch.
Thanks, I'm out of time for today.
ks.
I suspect that the provisions for EINTR and ENOSYS errors may now be
dead code, since the Linux man page for posix_fallocate mentions
neither. They're not much code though, and POSIX itself *does*
list EINTR, so I'm hesitant to muck with that.
regards, tom l
f glibc to find that out, though, I think
we should just s/fallocate/posix_fallocate/g on this patch. The argument
for using the former seemed pretty thin to begin with.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
27;ll work on that in a little bit.
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 writes:
> On Mon, Sep 25, 2017 at 10:22 AM, Tom Lane wrote:
>> I think we don't really have a lot of choice. I propose applying this
>> as far back as 9.6 --- anyone think differently?
> +1. If applies to 9.5 and 9.4 without a lot of work, I think we
>
Andres Freund writes:
>> On 25/09/17 19:26, Tom Lane wrote:
>>> The problem with this type of argument is that it leads directly to the
>>> conclusion that every feature users want must be in core.
> ... I don't think that should mean that there's no possible
Robert Haas writes:
> On Mon, Sep 25, 2017 at 10:22 AM, Tom Lane wrote:
>> Thomas Munro writes:
>>> So, do we want this patch?
>> I think we don't really have a lot of choice. I propose applying this
>> as far back as 9.6 --- anyone think differently?
>
we need to make use
of that. (If that means we need better docs, then yeah, we'd better get
that part done.)
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
ync. Maybe that accounts
for your not seeing stats?
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
Andrew Dunstan writes:
> On 09/25/2017 10:14 AM, Tom Lane wrote:
>> Oh ... I did not think we were on the same page, because your patch
>> didn't include removal of the same-transaction heuristic. It'd be
>> sensible to do that as a separate patch, though, to make
orth taking risks for post-RC1. OTOH, I would
not be surprised to get bug reports about it down the road.
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
Thomas Munro writes:
> So, do we want this patch?
I think we don't really have a lot of choice. I propose applying this
as far back as 9.6 --- anyone think differently?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Andrew Dunstan writes:
> On 09/24/2017 07:06 PM, Tom Lane wrote:
>> So I think we should just stop with the blacklist test for v10,
>> and then see if we still get complaints (and exactly what they're
>> about) so that we can judge how much more work the problem deserv
Andrew Dunstan writes:
> On 09/24/2017 04:37 PM, Tom Lane wrote:
>> What we still need to debate is whether to remove the heuristic
>> type-is-from-same-transaction test, making the user-visible behavior
>> simply "you must commit an ALTER TYPE ADD VALUE before you can u
test, making the user-visible behavior
simply "you must commit an ALTER TYPE ADD VALUE before you can use the
new value". I'm kind of inclined to do so; the fuzzy (and inadequately
documented) behavior we'll have if we keep it doesn't seem very nice to
me.
ur other programs do this.
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
gt; more than a few hundred enum types. But even a million or two shouldn't
> consume a huge amount of memory, should it?
Dynahash tables are self-expanding, so I don't see a need to stress about
that too much. Anything in 10-100 seems reasonable for initial size.
could hand back. Given that some of these bugs
have been in place for ~ten years and nobody noticed till now, seems
like it might be good enough to fix them in HEAD only.
Comments?
regards, tom lane
diff --git a/src/backend/executor/execExprInterp.c b/src/backen
Andrew Dunstan writes:
> On 09/23/2017 02:00 PM, Tom Lane wrote:
>> So I'm back to not being sure about the path forward. Maybe it would be
>> all right to say "the value added by ADD VALUE can't be used in the same
>> transaction, period". That'
be used in the same
transaction, period". That's still a step forward compared to the pre-v10
prohibition on doing it at all. I don't remember if there were use-cases
where we really needed the exception for new-in-transaction types.
regards, tom lane
--
o AutovacMemCxt that you'd added in
autovacuum_do_vac_analyze ... with this patch, we can drop that.
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
, thanks for reviewing!
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
201 - 300 of 48047 matches
Mail list logo
