policies
doesn't mean you *should*.
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
Peter Eisentraut writes:
> On 10/26/17 16:10, Tom Lane wrote:
>> In view of commit 1ff01b390, aren't we more or less locked into
>> lower-case anchors going forward?
> The details are more complicated. ...
Ah. I'd imagined that we were using the original case
were far enough left to actually not fit into
"char", but otherwise there's nothing 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
27;s result type, which would match the column type.
I think concretely what we need is the attached.
(BTW, the getBaseType() is only necessary in HEAD, since before
domains-over-composites the argument of a FieldSelect couldn't
be a domain type.)
regards, tom lane
dif
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 way if v11 will be incompatible
anyhow.
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
relations change after we've already done some
planning 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
places
you have to teach about 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
ike to go ahead
and commit this.
regards, tom lane
diff --git a/contrib/hstore/hstore_io.c b/contrib/hstore/hstore_io.c
index d828401..e999a8e 100644
*** a/contrib/hstore/hstore_io.c
--- b/contrib/hstore/hstore_io.c
*** typedef struct RecordIOData
*** 752,757 *
Robert Haas writes:
> On Tue, Oct 24, 2017 at 4:36 PM, Tom Lane wrote:
>> Yeah, but I lost the argument. For better or worse, our expected
>> behavior is now that we throw errors. You don't get to change that
>> just because it would save a few cycles.
> I don&#x
Andres Freund writes:
> On 2017-10-24 10:09:09 -0400, Tom Lane wrote:
>> There's an ancient saying that code can be arbitrarily fast if it
>> doesn't have to get the right answer. I think this proposal falls
>> in that category.
> Does it? In plenty of cas
sactionContext might be a subtransaction's context that will
go away at subtransaction commit/abort.
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
are widely portable remains to be seen. Whether they're
faster than what we're doing now also remains to be seen.
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 code is simpler without it.
That's utterly irrelevant. The code would be even simpler with
no crash recovery at all ... but we're not going there.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
Amit Langote writes:
> On 2017/10/23 2:07, Tom Lane wrote:
>> Hmm. adjust_appendrel_attrs() thinks it's only used after conversion
>> of sublinks to subplans, but this is a counterexample. I wonder if
>> that assumption was ever correct? Or maybe we need to re
nup now does, nobody is going to consider that a PG bug.
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
claration seems to have been dropped in a rather
random place in the .h file.
Looks good otherwise.
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
breaks #1 for no very good reason. So I think we
should remove the restriction in FuncNameAsType and instead enforce #2
in a narrowly tailored way, as in the attached patch.
regards, tom lane
diff --git a/src/backend/parser/parse_func.c b/src/backend/parser/parse_func.c
in
nks it's only used after conversion
of sublinks to subplans, but this is a counterexample. I wonder if
that assumption was ever correct? Or maybe we need to rethink what
it does when recursing into RTE subqueries.
regards, tom lane
--
Sent via pgsql-hackers mailin
not sure it would ever come up again.
If we come across another use-case maybe then would be the time to
fix it more cleanly.
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
int of the exclusion wasn't clear.
Some excavation in our git history shows that the exclusion was
added here:
commit 990eb8552e69a492840d46b58ceb630a8a295e54
Author: Tom Lane
Date: Wed Dec 12 03:28:49 2001 +
Don't accept names of complex types (ie, rela
Vik Fearing writes:
> On 10/19/2017 10:54 PM, Tom Lane wrote:
>> Uh ... recommended by whom? pg_statistic has exactly the same reliability
>> guarantees as the rest of the system catalogs.
> For data statistics, sure. One thing I'm unhappy about is that
> pg_stat_
es as the rest of the system catalogs.
I don't deny that there might be cases where this is worth doing, but
it does not seem so likely that it should be part of one's standard
checklist. Much less something that we should expend a great deal
of effort to automate.
I wrote:
> 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
AFAICS, setrefs.c's special treatment of "converted whole row references"
is completely pointless. Why aren't they just treated by the regular
"non var" code paths, thus saving code space and cycles?
regards, tom lane
--
Sent via pgs
away and then
doing your application calculations in whatever chunk size seems
convenient is probably your best bet 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
of the autovac task dispatch code, anyway.)
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
n eye to whether there are any places in our SSL abstraction
API that ought to be rethought now that we have actual non-OpenSSL
implementations to compare to.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
ioning. Inheritance has many
>> undesirable warts.
> I don't think it's a good idea for table partitioning and table
> inheritance to behave differently.
I'm with Robert on this one. I'd be in favor of changing both cases
to make ALTER OWNER recurse by default.
cause the
PG_TRY around autovacuum_do_vac_analyze doesn't do anything about
switching back to AutovacMemCxt. There needs to be a bit more clarity
throughout this code about what CurrentMemoryContext ought to be at each
point. Appropriate fixes might involve switching back to AutovacMemCxt
after each o
Justin Pryzby writes:
> On Tue, Oct 17, 2017 at 09:34:24AM -0400, Tom Lane wrote:
>> So: where did you get the existing binaries? If it's from some vendor
>> packaging system, what you should do is fetch the package source, add
>> the patch to the probably-nonempty se
m some vendor
packaging system, what you should do is fetch the package source, add
the patch to the probably-nonempty set of patches the vendor is applying,
and rebuild your own custom package version. If you haven't done that
before, it's a good skill to acquire ...
Thomas Munro writes:
> On Fri, Oct 13, 2017 at 10:01 AM, Tom Lane wrote:
>> But I see very
>> little case for allowing CTEs to capture such references, because surely
>> we are never going to allow that to do anything useful, and we have
>> several years of precedent
s arguments */
+ slot = ExecProject(pertrans->argproj);
}
+ else
+ slot = aggstate->evalslot;
which seems like a pretty minimal extra cost for the normal case
with no filter.
Let me see what I can make of that ...
regards, tom lane
--
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
graph someplace
earlier, before the optimizer processes the join quals.
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
s worth.
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
ot. If you're overloading functions, you really need
to use regprocedure not regproc.
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
ut the SGML
docs are lacking. Barring objections I'll finish up the docs and
push this.
regards, tom lane
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 9af77c1..cfec246 100644
*** a/doc/src/sgml/catalogs.sgml
--- b/doc/src/sgml/catalogs.sgml
***
And it would be very stupid of the
optimizer not to consider those derived join conditions, because
they may lead to the optimal join order.
In general it's already true that the optimizer doesn't consider
clauseless joins unless there's no other choice. But this example
isn't sho
Andres Freund writes:
> On 2017-10-13 14:07:54 -0400, Tom Lane wrote:
>> One idea might be to see if we can precalculate all the control data
>> needed for the caches and set it up as compile-time constants,
>> a la Gen_fmgrtab.pl, rather than reading it from the catalogs dur
as compile-time constants,
a la Gen_fmgrtab.pl, rather than reading it from the catalogs during
startup. That would make the code less dependent on initialization
order rather than more so.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
he function is trying to accomplish and what the
constraints are. I'll take a whack at improving that and push.
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
there are any user-created OSAs in the wild, but
if there are, they likely borrowed code from orderedsetaggs.c.
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
tays red,
which is probable, we should disable "restrict" for that compiler.
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
Heikki Linnakangas writes:
> On 10/13/2017 02:08 AM, Tom Lane wrote:
>> I started to look into fixing orderedsetaggs.c so that we could revert
>> 52328727b, and soon found a rather nasty problem. Although the plain
>> OSAs seem amenable to supporting multiple fina
Thomas Munro writes:
> On Fri, Oct 13, 2017 at 12:46 PM, Tom Lane wrote:
>> Yeah, I agree --- personally I'd never write a query like that. But
>> the fact that somebody ran into it when v10 has been out for barely
>> a week suggests that people are doing it.
>
David Rowley writes:
> On 13 October 2017 at 12:41, Tom Lane wrote:
>> Yeah, we would probably also want to check the flag in nodeWindowAgg.
>> Not sure exactly how that should play out --- maybe we end up with
>> a tri-valued property "works as normal agg without mergi
Thomas Munro writes:
> On Fri, Oct 13, 2017 at 10:01 AM, Tom Lane wrote:
>> The CTE was simply not part of the available namespace for the INSERT's
>> target, so it found the regular table instead. v10 has thus broken
>> cases that used to work. I think that's a
David Rowley writes:
> On 13 October 2017 at 12:08, Tom Lane wrote:
>> Therefore, I think we need to bite the bullet and provide an aggregate
>> property (CREATE AGGREGATE argument / pg_aggregate column) that tells
>> whether the aggregate supports transition state
the default should be for user-created aggregates.
I am inclined to think that we should err on the side of safety and
default it to false (no merge support). You could argue that the
lack of complaints since 9.6 came out is sufficient evidence that
defaulting to true would be all right, but I'
Thomas Munro writes:
> On Fri, Oct 13, 2017 at 8:50 AM, Tom Lane wrote:
>> Hm. I actually think the bug here is that 18ce3a4ab introduced
>> anything into setTargetTable at all. There was never previously
>> any assumption that the target could be anything but a regular
etRTEForSpecialRelationTypes
check there. I tend to agree that getRTEForSpecialRelationTypes
should probably contain an explicit check for unqualified name
rather than relying on its caller ... but that's a matter of
future-proofing not a bug fix.
regards, tom lane
Gourav Kumar writes:
> A Join clause/predicate will only mention 2 relations. It can't have 3 or
> more relations.
Really? What of, say,
select ... from a,b,c where (a.x + b.y) = c.z;
regards, tom lane
--
Sent via pgsql-hackers mailing list (pg
use() and
have_relevant_eclass_joinclause(). Or maybe you could just use them
as-is ... depends on what you have in mind to do with join clauses
that mention 3 or more relations.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
is looking like a whole lot more work than we could
ever hope to save by not having to maintain these file lists anymore.
So I'm not planning to pursue it. If someone else wants to, though,
have at it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-
they
likely got converted into EquivalenceClass data structures instead.
These days the joininfo lists only contain "unstructured" join
conditions.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
e start of the table. Cancelling it partway through allows
the syncscan pointer to be left pointing somewhere in the middle of the
table.
If you turn off synchronize_seqscans, you should find that you always
get the physically-first table row from that subselect.
regards
hat is a can of worms.
Yeah, I'm pretty suspicious of the idea too. We've had an awful lot of
bad experience with local plan caching, to the point where people wonder
why we don't just auto-replan every time. How would a shared cache
make that better? (Even assuming it was otherwi
ute executables that don't get built from a clean state.
But they put a crimp in the usefulness of the idea for developers.
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
tomic_t *'
Those seem like maybe something to look into. MemSet is evidently
casting away pointer properties that it perhaps shouldn't.
regards, tom lane
diff --git a/src/include/c.h b/src/include/c.h
index b6a9697..f7ea3a5 100644
*** a/src/include/c.h
--- b/sr
BLIC by default:
Yup, that's an oversight.
> Hence I propose the attached documentation patch.
Pushed, with a bit of additional wordsmithing.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Andres Freund writes:
> On 2017-10-11 11:58:58 -0400, Tom Lane wrote:
>> I agree the PITA factor of the current approach keeps increasing.
>> It sounds a bit silly to build libpgport three ways, but maybe
>> we should just do that.
> We already kinda are, just by copyin
Alvaro Herrera writes:
> Tom Lane wrote:
>> Also, why is the patch apparently changing whitespace in all the help
>> lines? Seems like that will create a lot of make-work for translators.
> I think we don't have translations for pg_regress.
Good point
Maybe just "if empty, use PATH ..." ?
Also, why is the patch apparently changing whitespace in all the help
lines? Seems like that will create a lot of make-work for translators.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Thoughts?
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
the system. If we did build it like that,
what we'd end up with would be very reminiscent of mysql's storage
engines, complete with inconsistent behaviors and varying feature sets
across engines. I don't much want to go there.
regards, tom lane
ng some slop in the initial allocation.
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-08 11:28:09 -0400, Tom Lane wrote:
>> https://commitfest.postgresql.org/15/1001/
>> The reason that's not in v10 is we haven't been able to convince
>> ourselves whether it's 100% correct.
> Unfortunately it won'
Petr Jelinek writes:
> Okay, that makes sense, thanks for explanation. Your patch is the way to
> go then.
Hearing no further comment, pushed. Thanks for reviewing it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
for that then:
https://commitfest.postgresql.org/15/1001/
The reason that's not in v10 is we haven't been able to convince
ourselves whether it's 100% correct.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
was 1e7c4bb00. (I guess the commit
log message is a bit misleading, because it only talks about unknown
literals ... but undetermined parameters and undecorated NULL constants
would receive the same force-to-text-type treatment.)
regards, tom lane
--
Sent via pgsql-hacker
is probably good
enough for a first cut.
regards, tom lane
diff --git a/src/backend/storage/file/copydir.c b/src/backend/storage/file/copydir.c
index a5e074e..eae9f5a 100644
--- a/src/backend/storage/file/copydir.c
+++ b/src/backend/storage/file/copydir.c
@@ -139,10 +139,24 @@ copy_f
Petr Jelinek writes:
> On 07/10/17 18:15, Tom Lane wrote:
>> No, I'm afraid you didn't read that comment closely enough. This will
>> flat out fail for cases like "select ... where x=x order by x", because
>> there will already be a single-elemen
;d go for the former approach; seems like less new code and fewer cycles
> used to enforce the rule.
Concretely, how about the attached? (Obviously we'd have to fix
parallel_schedule before committing this.)
regards, tom lane
diff --git a/src/test/regress/GNUmake
to express an opinion that that would
likely be wasted effort. If you disagree, and are willing to expend
such effort speculatively, I'm not stopping you.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
Petr Jelinek writes:
> On 07/10/17 04:19, Tom Lane wrote:
>> (edit: a few minutes later, I seem to remember that equivclass.c has
>> to do something special with the X=X case, so maybe it could do
>> something else special instead, with little new overhead.)
> So I wrot
Robert Haas writes:
> On Fri, Oct 6, 2017 at 4:16 PM, Tom Lane wrote:
>> The other routine mistake, which I see Robert just made again,
>> is to break the at-most-twenty-parallel-tests-at-once convention.
>> I wonder if we can get in some sort of automated check for that.
this.
I can't get very excited about that one either.
In the end, what the article fails to consider is that all of these are
tradeoffs, not unalloyed goods. If you spend planner cycles on every
query to look for cases that only the most unabashedly brain-dead ORMs
ever generate, you're n
n argument
against it offhand.
The other routine mistake, which I see Robert just made again,
is to break the at-most-twenty-parallel-tests-at-once convention.
I wonder if we can get in some sort of automated check for that.
regards, tom lane
--
Sent via pgsql-hackers maili
.)
#2 is probably the worst of these problems.
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
. That would surely offer far higher rewards, but the costs
to get there are likewise orders of magnitude greater.
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
ymore. But I'm unconvinced that
rewriting existing code that works fine is the most productive
way to exploit such a choice if we were to make it.)
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
"Joshua D. Drake" writes:
> I get being able to change my search_path on the fly but it seems odd
> that as user foo I can change my default search path?
Why is that odd? It's a USERSET variable.
regards, tom lane
--
Sent via pgsql-hacker
up
the name of a built-in function from its OID. (Don't know that anyone
actually does that, but I see no reason to break their code if they 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
Robert Haas writes:
> On Tue, Aug 29, 2017 at 5:14 PM, Tom Lane wrote:
>> We'd definitely need to do things that way in 9.6. I'm not quite sure
>> whether it's too late to adopt the clean solution in v10.
> It probably is now. Are you still planning to do
seem to have been a bit sloppy with
maintaining these comments too, so I ended up doing more than 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
gt;'Active' end
;
ERROR: syntax error at or near "select"
LINE 3: where case when (select pg_has_role(select "current_user"(),...
^
I'm betting that the complainant has tried to obscure what they actually
did, and has obscur
ush_data() call.
One thing that occurs to me is that even a 64KB file copy buffer is pretty
small on any modern machine. If we were to up that to, say, 1MB, does
that help any? See COPY_BUF_SIZE in src/backend/storage/file/copydir.c.
regards, tom lane
--
Sent via pgsql-h
diverge.
> Please let's unify whatever we can. The fewer manual sync we need, the
> better.
Isn't pgtypeslib/*.h exposed to ecpg-using applications?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
-> 3.0 change.
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
assign typenames[0] and typeoids[0] from linitial(object)
assign typenames[1] and typeoids[1] from lsecond(object)
This would involve duplicating the loop body, but that's only 3 lines,
so I think it wouldn't even net out as more code.
regards
egards, 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 warnings
should be issued for any tables not explicitly named.
In any case, though, the extent to which we should add more warning
or log output seems like a fit topic for a new thread and a separate
patch. Let's call this one done.
regards, tom lane
--
"DT_PM" ... there's a little bit of precedent
for the DT_ prefix already.
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
ce we could just say "we don't really recommend that
usage pattern".
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
Still, we might want to
revisit it if we find any other problems 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
ta fields to show that the "latch" field is now
treated as protected by the spinlock. In the back branches, we shouldn't
do that, just in case some external code is touching the mutex field.
regards, tom lane
diff --git a/src/backend/replication/walre
Alvaro Herrera writes:
> Tom Lane wrote:
>> Alvaro Herrera writes:
>>> I think the latch is only used locally. Seems that it was only put in
>>> shmem to avoid a separate variable ...
>> Hm, I'm strongly tempted to move it to a separate static variable t
use the set of column names to be
considered is very constrained --- only columns belonging to tables
listed in FROM. The parser has already sucked in the column name
lists for those tables, so no additional catalog fetches are needed.
regards, tom lane
--
Sent v
101 - 200 of 48047 matches
Mail list logo
