suggest an actual
pgbench bug, independently of anything else.)
Possibly you can duplicate skink's issue by running things under
valgrind.
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
API that lets an operator estimation
function replace convert_to_scalar in toto, but that seems like
you'd still end up duplicating code in many cases. Not sure about
how to find a happy medium.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> On 09/22/2017 11:19 PM, Tom Lane wrote:
>> Yeah, I was considering the same thing over dinner, though I'd phrase
>> it oppositely: keep a list of enum type OIDs created in the current
>> transaction, so t
, so you're promising not to whine when we break backwards compatibility
on this point in v11?
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 <andrew.duns...@2ndquadrant.com> writes:
> On 09/22/2017 05:46 PM, Tom Lane wrote:
>> I'm not sure if that qualifies as a stop-ship problem, but it ain't
>> good, for sure. We need to look at whether we should revert 15bc038f9
>> or somehow revise i
s a stop-ship problem, but it ain't
good, for sure. We need to look at whether we should revert 15bc038f9
or somehow revise its rules.
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
.
Comments, objections?
regards, tom lane
PS: I was disappointed to find out that perform_work_item() isn't
exercised at all in the standard regression tests.
diff --git a/src/backend/postmaster/autovacuum.c b/src/backend/postmaster/autovacuum.c
index b745d89..1a32433 100644
ZE.
This would mean a few more cycles in lock management, but since this
only applies to a manual VACUUM or ANALYZE that specifies a table
name, I'm not too concerned about that.
Thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
ht
as well try to make the buildfarm green pending investigation of how
this is happening.
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 <peter.eisentr...@2ndquadrant.com> writes:
> On 9/21/17 17:38, Tom Lane wrote:
>> Meanwhile, I see that Peter has posted a fix for the immediate problem.
>> I propose that Peter should apply his fix in HEAD and v10, and then
> done
>> I'll rip out
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 9/21/17 14:58, Tom Lane wrote:
>> I've just been going through their git commit log to see what else has
>> changed since tzcode2017b, and I note that there are half a dozen other
>> portability-ish fixes.
one just for this.
I'll take a look at the updated 0002 tomorrow, but if anyone living in
a different timezone wants to review it meanwhile, feel free.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
!USE_WIDE_UPPER_LOWER code paths in HEAD only.
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
RRAY_P/)
but for convenience here's an updated patch set.
regards, tom lane
diff --git a/src/backend/optimizer/prep/preptlist.c b/src/backend/optimizer/prep/preptlist.c
index 9d75e86..d7db32e 100644
*** a/src/backend/optimizer/prep/preptlist.c
--- b/src/backend/optimizer/prep/prept
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 9/21/17 11:46, Tom Lane wrote:
>> This also means that the portability problem is purely hypothetical;
>> given valid tz reference data the code wouldn't ever try to increment
>> "hit" to 2 anyway
,
and then either leave the problem to be fixed by our next regular sync
with a released tzcode version, or else force a sync with their git tip
to absorb their fix now. In either case we should keep all our live
branches in sync. I'm willing to do the code-sync work either way.
Comments?
ault. If they both produce results with the same
conversion_convention, then we can treat the converted_values as
commensurable.
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
ack branches is worth something for
maintenance --- but should that outweigh the risk of breaking something
post-rc1?
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
as just memset for MSVC. Maybe later that could be extended
to other compilers.
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
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Thu, Sep 21, 2017 at 9:08 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Um ... so? With Nathan's proposed behavior, there are two cases depending
>> on just when the unexpected schema change happens:
>> 1. *
ast some cases, eg for a box ((0,1),(1,inf))
there's no reason to give up our knowledge of finite bounds for the
other three boundaries. But certainly for a NaN circle radius
what you suggest seems the most sensible thing to do.
regards, tom lane
--
Sent via pgsql-hacke
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Thu, Sep 21, 2017 at 8:18 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> "Bossart, Nathan" <bossa...@amazon.com> writes:
>>> I agree that the patch might be simpler without this, but the user-vis
these calls and nearby ones, but it would be good to understand just
what's wrong here. And why it's only showing up in that file; seems
nearly certain that we have similar coding elsewhere.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
evious thread, I think the
most salable alternative is probably ilmari's: get rid of the variable
and write the assert like
Assert(planner_rt_fetch(rel->relid, root)->rtekind == RTE_SUBQUERY);
That's a pretty minimal change and it doesn't add any cycles to the
non-Assert case.
east it's slightly more apparent what we're trying to ensure.
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
"Bossart, Nathan" <bossa...@amazon.com> writes:
> On 9/20/17, 2:29 PM, "Tom Lane" <t...@sss.pgh.pa.us> wrote:
>> I think that the way this ought to work is you process the VacuumRelation
>> structs purely sequentially, each in its own transaction,
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> On 9/20/17 12:06, Tom Lane wrote:
>> I'm tempted to propose that we invent some kind of "unknown"
>> collation, which the planner would have to be taught to not equate to any
>> other colum
Nikita Glukhov <n.glu...@postgrespro.ru> writes:
> On 20.09.2017 23:19, Alexander Korotkov wrote:
>> On Wed, Sep 20, 2017 at 11:07 PM, Tom Lane <t...@sss.pgh.pa.us
>> <mailto:t...@sss.pgh.pa.us>> wrote:
>>> Maybe I'm missing something, but it appears to m
--with-libxml you can still build.
I found this out the hard way on longfin's host, so I've
temporarily removed --with-libxml from that animal's
configuration to restore it to service. I trust I'll be
able to re-enable that after 10.13 comes out.
regards, tom lane
--
Sent via
t.
> How about removing circle from the scope of this patch, so it is smaller and
> cleaner?
Neither of those patches would be particularly large, and since they'd need
to touch adjacent code in some places, the diffs wouldn't be independent.
I think splitting them is just make-work.
ce if it's looked up the same column number
twice. That would be more likely to lead to a back-patchable fix,
too. 0002 as it stands is useless as a back-patch basis, since it
proposes modifying code that doesn't even exist in the back branches.
regards, tom lane
--
Sent v
it's going to fix anything at all for us in this area. It seems to
be just about as squishy as glibc in terms of locale identification,
if not worse.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
tever pg_database says".
Non-default collations go through strcoll_l(), which might not even
exist on a given platform. So they're entirely separate code paths.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
oduce incorrect
plans by default.
This is, of course, not at all a back-patchable fix.
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
if we picked a functionally equivalent collation, it would impede
query optimization because the planner wouldn't know it was equivalent.
Perhaps, rather than trying to fix this automatically, we should
leave it to the user. We could invent another import option that
says what to translate "default"
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Wed, Sep 20, 2017 at 12:33 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> That would indicate that something isn't ever retrying the worker
>> start; but if that's the case, how is it that we get through the
>>
Alexander Korotkov <a.korot...@postgrespro.ru> writes:
> On Wed, Sep 20, 2017 at 4:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Yes. We don't allow out-of-line values, but we do allow compressed and
>> short-header values.
> BTW, this comment looks still invalid f
big
>> long lived DSA area you have nothing like that.
> We need, IMO, a DSA-backed heirachical MemoryContext system.
Perhaps the ResourceManager subsystem would help here.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
tuples?
Yes. We don't allow out-of-line values, but we do allow compressed and
short-header values.
If you don't believe me, look at index_form_tuple().
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
vor of expanding the underlying bgworker slot with some additional
fields that would carry whatever extra info we need about a logicalrep
worker. Such fields could also be repurposed for additional info about
other kinds of bgworkers, when (not if) we find out we need that.
no-longer-needed
no-op functions in the core GiST opclasses. There's still room
to improve the contrib opclasses, but that's much more tedious
(you need to write an extension update script) so I didn't feel
like messing with those now.
regards, tom lane
--
Sent via pgsq
Michael Paquier <michael.paqu...@gmail.com> writes:
> On Fri, Sep 1, 2017 at 5:33 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
>>> As an aside, is there a reason why the archiver process is not includ
"David G. Johnston" <david.g.johns...@gmail.com> writes:
> On Tue, Sep 19, 2017 at 2:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Notice the parens/comma positioning. It's only because text is such
>> a lax datatype that you didn't notice the problem
Andres Freund <and...@anarazel.de> writes:
> On 2017-09-19 17:15:21 -0400, Tom Lane wrote:
>> Meh --- Carp::Always isn't standard either, so I think this is just extra
>> complication with little value-add. Let's just do the Devel::Confess
>> incantation as Dagfi
when they upgrade to PostgreSQL 11.
> What if they have specified the locale in the old non-ICU format or they
> have a bogus value and we then error out on pg_upgrade or pg_restore?
Well, if PG10 shipped with that restriction in place then it wouldn't
be an issue ;-)
"Merge mismatch" message.
On a slow/loaded machine, perhaps it could be that the postmaster loses
patience and SIGKILLs a backend that's still writing its .gcda data?
If so, maybe we could make SIGKILL_CHILDREN_AFTER_SECS longer in
coverage builds? Or bite the bullet and make it configurable ...
rd either, so I think this is just extra
complication with little value-add. Let's just do the Devel::Confess
incantation as Dagfinn has it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
a lax datatype that you didn't notice the problem.
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
eems pretty weird. I don't see a big reason not to just put it with
the bullet point about SCRAM. People who care will notice it there just
fine.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
t mkc(1,2) into c;
raise notice 'c = %', c;
end$$;
select test();
I get
ERROR: invalid input syntax for type double precision: "(1,2)"
CONTEXT: PL/pgSQL function test() line 4 at SQL statement
That's because it's trying to assign the result of mkc() into c.r,
not into the whole com
b64/perl5/vendor_perl
/usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
$ perl -e 'eval { require Carp::Always; }'
$ echo $?
0
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsq
Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes:
> On 09/19/2017 11:11 AM, Tom Lane wrote:
>> Actually, after looking closer, my advice is just to drop the new
>> test cases involving accented letters. It surprises me not in the
>> least that those would have non
existing behavior for one target variable.
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
"David G. Johnston" <david.g.johns...@gmail.com> writes:
> On Tuesday, September 19, 2017, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I'd be much happier if there were some notational difference
>> between I-want-the-composite-variable-to-absorb-a-composite-column
Pavel Stehule <pavel.steh...@gmail.com> writes:
> [ faster-concat-2.patch ]
Pushed with some cosmetic adjustments (mostly better comments).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
verse-engineer N from context, but I think that'd be overly
complicated and bug prone.)
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
than add a new run of the standard regression
> tests, is to avoid bloating the regression time unnecessarily.
Maybe there's a way to set up a buildfarm animal or two that run all
the tests with a different segsize?
regards, tom lane
--
Sent via pgsql-hackers mailin
(which do rely on shmem being ok to some extent), pmsignal,
> BackgroundWorkerStateChange(), ...
Well, the point is to avoid touching data structures that could be
corrupted enough to confuse the postmaster. I don't have any problem with
adding some more functionality to pmsignal, say.
rofiles in feature
> releases?.
Not particularly. You can do that sort of thing already via PAM,
for example.
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'" <br...@momjian.us> writes:
> On Tue, Sep 19, 2017 at 12:30:01PM -0400, Tom Lane wrote:
>> Well, if the intent of the note was to encourage people to raise
>> shared_buffers, it didn't do a very good job of that as written,
>> because I sure
"'Bruce Momjian'" <br...@momjian.us> writes:
> On Tue, Sep 19, 2017 at 12:22:39PM -0400, Tom Lane wrote:
>> We don't normally release-note documentation changes. If this
>> wasn't purely a documentation change, then I was probably in error
>> to dec
y to improve 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
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
if we started to do so, that would be a concrete benefit of this
patch ...
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
isn't ever retrying the worker
start; but if that's the case, how is it that we get through the
other subscription tests with my random-failure patch in place?
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
nportable behavior: probably, some
locales will case-fold them and some won't.
(This does open up some questions about whether the opclass will
ever be of use for Alexey's original purpose :-()
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
locale did you use to create citext_1.out? We've never before
needed more than one output file for non-C locales.
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
by_message_timeout = atoi(optarg) * 1000;
fairly easily:
if (!pg_int_convert(optarg, 0, INT_MAX/1000,
_message_timeout))
... complain-and-exit ...
standby_message_timeout *= 1000;
regards, t
with Alvaro that it'd be better to get rid of
BT_READ/BT_WRITE in favor of using the same buffer flags used
elsewhere; but I also agree that as long as they're there we
should use them, so I included that change as well.
regards, tom lane
--
Sent via pgsql-hackers mailing
Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Jul 25, 2017 at 9:54 PM, Kyotaro HORIGUCHI
> <horiguchi.kyot...@lab.ntt.co.jp> wrote:
>> The patch is a kind of straightforward and looks fine for me.
> +1 for this change.
LGTM too, pushed.
enabled, maybe your kernel is doing something like
(1) close files, (2) dump core, (3) exit process (resulting in SIGCHLD)?
I don't think I've ever seen this myself. Peculiarity of some kernels,
perhaps.
regards, tom lane
--
Sent via pgsql-hackers mailing list (p
original point about adding a wrapper for GISTENTRY fetches remains
open ...
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:
> On 2017-09-18 11:50:06 -0400, Tom Lane wrote:
>> The reason seems to be that its method of waiting for replication
>> to happen is completely inapropos. It's watching for the master
>> to say that the slave has received
would not bother with (2); I think (1) would
capture most of the win for a very small fraction of the complication.
Just for starters, I do not think (2) works for batched hashes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
Robert Haas <robertmh...@gmail.com> writes:
> On Mon, Sep 18, 2017 at 9:47 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Now, for pg_stat_activity part of the argument why this wouldn't be
>> confusing was that you could also see the "state" field. Maybe we
>
oth of those cases, the buildfarm will not like you.
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
Amit Kapila <amit.kapil...@gmail.com> writes:
> On Mon, Sep 18, 2017 at 7:46 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> The subscriber log includes
>> 2017-09-18 08:43:08.240 UTC [15672] WARNING: out of background worker slots
>> Maybe that's harmless, but I'm s
tionality into ForgetBackgroundWorker itself, so we can't forget
it again?
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
WAL, but that does not
ensure that the logicalrep apply workers have caught up, does 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
slot, and we're just
walking away from it.
I'll go see if I can't reproduce this by injecting random failures right
there.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgres
orker-fork-failure error recovery I bitched about months ago
[1], leading to subscription startup waiting forever for a worker that's
never going to report finishing.
I see Amit K. just posted a patch in that area [2], haven't looked at it
yet.
regards, tom lane
[1] ht
rn equivalent info into the crash log entry?
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
yntax more like other similar
utility commands such as CREATE AGGREGATE --- basically just
adding some parens, IIRC.
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 looks like the code to check for distinctness in the subquery
> fails to consider that the join condition may contain RelabelTypes
> instead of plain Vars.
>
> The attached fixes.
Looks like a good fix to me (except for the copied-and-pasted,
not-quite-on-point comment ;-)). Pushed.
y cover even that case by noting whether or not the tail
chunk's freeptr moved, but I think it's too much complication for too
little chance of gain.
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:
> On 2017-09-16 14:30:21 -0400, Tom Lane wrote:
>> I wonder whether we shouldn't just revert this patch altogether.
> The problem is that the patch that makes the segment size configurable
> also adds a bunch more ordering constr
le values from the file; if a system crash isn't
enough to get it to flush its cache, then what is?
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
. AFTER STATEMENT behavior. Objections?
regards, tom lane
diff --git a/src/backend/commands/trigger.c b/src/backend/commands/trigger.c
index 7e391a1..78e6ce7 100644
*** a/src/backend/commands/trigger.c
--- b/src/backend/commands/trigger.c
*** static void
et
ControlFile to null.
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
necessary
delta in the final code, with the attendant hazards for back-patches.
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'm starting to think that (4) might be the best avenue. Or we could
consider
(5) drop contrib/chkpass altogether, on the grounds that it's too badly
designed, and too obsolete crypto-wise, to be useful or supportable.
regards, tom lane
--
Se
ogical
decoding plug-in watching the WAL output.)
> Commit triggers also allow one to record transaction boundaries, and
> NOTIFY listeners less frequently than if one did a NOTIFY in normal
> for-each-row/statement triggers.
Um, NOTIFY already collapses duplicate notifications per-transac
Andres Freund <and...@anarazel.de> writes:
> On 2017-09-14 23:29:05 -0400, Tom Lane wrote:
>> FWIW, I'm not on board with that. I think the version of typedefs.list
>> in the tree should reflect the last official pgindent run.
> Why? I see pretty much no upside to that. Y
go for (1) at least as a short-term answer. It's not clear to me
that it's worth the effort to do (2) or (3). Also, (3) probably breaks
backwards compatibility, if there is anyone out there actually using
this datatype.
regards, tom lane
--
Sent via pgsql-hacke
elect * from pg_get_object_address('operator of access method',
'{btree,integer_ops,1}', '{int4,bool}');
I wonder if this indicates you forgot to consider transmission of state
to parallel worker processes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (p
nd then add any typedefs created by the patch I'm working on to that.
But I don't put the result into the commit. Maybe we need a bit better
documentation and/or tool support for using an unofficial typedef list.
regards, tom lane
--
Sent via pgsql-hackers mai
larify
the relationships between these make targets.
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
ssion so far, 0001
> through 0007 might be ready; the other two need some more work.
Do you need me to do another round of tests on prairiedog/gaur/pademelon?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
sn't seem
super urgent to fix, so I'm not going to try to address it while
hacking the transition table business. But we'll need to return
to it later. Whatever we do about it has to be back-patched
further than v10, anyway.
regards, tom lane
--
Sent via pgsql-hacker
Andres Freund <and...@anarazel.de> writes:
> Re-upping this topic.
> On 2016-10-07 10:06:07 -0400, Tom Lane wrote:
>> In the same line, maybe we should kill libpq's support for V2 protocol
>> (which would make the cutoff 7.4). And maybe the server's support too,
>>
301 - 400 of 46745 matches
Mail list logo
