po 8. 10. 2018 v 17:00 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > The user sent a plan:
>
> > QUERY PLAN
> > Merge Semi Join (cost=82.97..580.24 rows=580 width=8) (actual
> > time=0.503..9557.396 rows=721 loops=1)
> > Merge Cond: (tips.users_id = follows.users_id_to)
> > -> In
On 2018/10/08 3:55, Tom Lane wrote:
> I didn't like the idea of unifying ModifyTable.nominalRelation with
> the partition root info. Those fields serve different masters ---
> nominalRelation, at least in its original intent, is only meant for
> use of EXPLAIN and might have nothing to do with wha
On 2018/10/07 3:59, Tom Lane wrote:
> Amit Langote writes:
>> On 2018/10/05 5:59, Tom Lane wrote:
>>> So I'm inclined to just omit 0003. AFAICS this would only mean that
>>> we couldn't drop the global PlanRowMarks list from PlannedStmt, which
>>> does not bother me much.
>
>> To be honest, I to
On 2018/10/08 0:09, Michael Paquier wrote:
> On Sun, Oct 07, 2018 at 11:13:19AM -0300, Alvaro Herrera wrote:
>> Good point. I cannot do that today, but if you want to, please go
>> ahead.
>
> Okay, done.
Thank you both.
Regards,
Amit
On Mon, Oct 08, 2018 at 09:30:49AM -0700, Andres Freund wrote:
> Sounds less terrible, but still pretty bad. I think we should fix the
> underlying data inconsistency, not paper over it a couple hundred meters
> away.
+1. I am looking at how to make that possible.
--
Michael
signature.asc
Desc
(2018/10/05 19:15), Etsuro Fujita wrote:
(2018/08/02 23:41), Tom Lane wrote:
Andrew Gierth writes:
[ postgres_fdw is not smart about exploiting fast-start plans ]
Yeah, that's basically not accounted for at all in the current design.
One possibility: would it be worth adding an option to EX
On Fri, Oct 05, 2018 at 10:11:45AM +0200, Daniel Gustafsson wrote:
> Thanks! Attached is a v17 which rebases the former 0002 patch on top of
> current master, along with the test fix for Windows that Thomas reported
> upthread (no other changes introduced over earlier versions).
Thanks for the ne
I wrote:
> Thomas Munro writes:
>> On Tue, Oct 9, 2018 at 2:55 PM Tom Lane wrote:
>>> Yeah, I've been burnt by that too recently. It occurs to me we could make
>>> that at least a little less painful if we formatted the macro with one
>>> line per function name:
>> +1, was about to suggest the
On Mon, Oct 08, 2018 at 03:22:55PM +, Pavel Stehule wrote:
> I tested this patch. This patch removes some duplicate rows, what is
> good - on second hand, after this patch, the textToQualifiedNameList
> does one more copy of input string more. I looked where this function
> is used, and I don'
On Tue, Oct 9, 2018 at 2:02 AM, David Rowley wrote:
> Yeah, so subplan_map is just an array that stores the List index of
> the Append or MergeAppend's subplans. When we perform run-time pruning
> during executor initialisation, if we prune away some of these
> subplans then we don't initialise tho
On Mon, Oct 08, 2018 at 10:39:23AM -0300, Alvaro Herrera wrote:
> Pushed now, thanks.
Thanks Alvaro for addressing the issue and back-patching.
--
Michael
signature.asc
Description: PGP signature
On Mon, Oct 08, 2018 at 07:36:50PM +0200, Laurenz Albe wrote:
> The attached patch has regression tests - I though it would be good
> to change some of the existing tests that run standby promotion to
> use the SQL function instead of pg_ctl.
>
> I have left the name though -- as far as I can tell
Hi David,
On 2018/10/05 21:55, David Rowley wrote:
> On 17 September 2018 at 21:15, David Rowley
> wrote:
>> v9 patch attached. Fixes conflict with 6b78231d.
>
> v10 patch attached. Fixes conflict with cc2905e9.
Thanks for rebasing.
> I'm not so sure we need to zero the partition_tuple_slots[]
Thomas Munro writes:
> On Tue, Oct 9, 2018 at 2:55 PM Tom Lane wrote:
>> Yeah, I've been burnt by that too recently. It occurs to me we could make
>> that at least a little less painful if we formatted the macro with one
>> line per function name:
>>
>> AC_CHECK_FUNCS([
>> cbrt
>> clock_gettime
On Wed, Oct 3, 2018 at 3:16 PM Andres Freund wrote:
> On 2018-09-27 20:03:58 -0700, Andres Freund wrote:
> > On 2018-09-28 12:21:08 +1000, Haribabu Kommi wrote:
> > > Here I attached further cleanup patches.
> > > 1. Re-arrange the GUC variable
> > > 2. Added a check function hook for default_tab
On Tue, Oct 2, 2018 at 4:53 PM Thomas Munro
wrote:
> Thanks for the review! And sorry for my delayed response. Here is a
> rebased patch, with changes as requested.
Rebased.
--
Thomas Munro
http://www.enterprisedb.com
0001-Enable-parallel-query-with-SERIALIZABLE-isolatio-v16.patch
Descripti
On Tue, Oct 9, 2018 at 2:55 PM Tom Lane wrote:
> Thomas Munro writes:
> > Rebased again. Patches that touch AC_CHECK_FUNCS are fun like that!
>
> Yeah, I've been burnt by that too recently. It occurs to me we could make
> that at least a little less painful if we formatted the macro with one
>
On Tue, Oct 09, 2018 at 02:14:52AM +, Iwata, Aya wrote:
> Sorry, I made a mistake. You patch currently does not apply. Kindly
> rebase the patch. I'm marking it as "Waiting on Author".
Thanks Iwata-san. I was just trying to apply the patch but it failed so
the new status is fine. On top of
On Tue, Oct 9, 2018 at 1:53 PM Tom Lane wrote:
> Thomas Munro writes:
> > On Mon, Oct 8, 2018 at 1:17 AM Thomas Munro
> > wrote:
> >> That's because the bgworker startup path doesn't contain a call to
> >> srandom(...distinguishing stuff...), unlike BackendRun(). I suppose
> >> do_start_bgworke
> I didn't find any problems with the patch, so I'm marking it as "Ready for
> Committer".
Sorry, I made a mistake. You patch currently does not apply. Kindly rebase the
patch.
I'm marking it as "Waiting on Author".
Regards,
Aya Iwata
On 9 October 2018 at 14:23, Imai, Yoshikazu
wrote:
> I checked codes and I think so too.
>
> Confirmation of my understanding and For more information to others:
>
> The subplan map is used when we call ExecFindInitialMatchingSubPlans or
> ExecFindMatchingSubPlans.
> ExecFindInitialMatchingSubPlan
Thomas Munro writes:
> Rebased again. Patches that touch AC_CHECK_FUNCS are fun like that!
Yeah, I've been burnt by that too recently. It occurs to me we could make
that at least a little less painful if we formatted the macro with one
line per function name:
AC_CHECK_FUNCS([
cbrt
On Mon, Oct 8, 2018 at 05:44:32PM +0200, Adrien NAYRAT wrote:
> On 10/8/18 5:20 PM, Bruce Momjian wrote:
> >Uh, where are you looking? We don't rebuild the beta docs until the
> >next beta release, but you can see the changes in the developer docs:
> >
> > https://www.postgresql.org/docs/deve
Hi, David.
Thanks for the patch!
On Mon, Oct 8, 2018 at 1:00 AM, David Rowley wrote:
> I was looking at this again and I realised that we can completely skip
> the re-sequence of the subplan map when we're not going to perform any
> further pruning during execution.
I checked codes and I think so
On Fri, Sep 28, 2018 at 2:03 AM Jesper Pedersen
wrote:
> Thanks for v5 too.
Rebased again. Patches that touch AC_CHECK_FUNCS are fun like that!
--
Thomas Munro
http://www.enterprisedb.com
0001-Use-pread-pwrite-instead-of-lseek-read-write-v6.patch
Description: Binary data
Thomas Munro writes:
> On Mon, Oct 8, 2018 at 1:17 AM Thomas Munro
> wrote:
>> That's because the bgworker startup path doesn't contain a call to
>> srandom(...distinguishing stuff...), unlike BackendRun(). I suppose
>> do_start_bgworker() could gain a similar call... or perhaps that call
>> sho
Hi Christoph,
> > All similar function are named pg_ls_***dir. It is clear these
> > functions return directory contents information.
> > If the new function intends to display the contents of the directory,
> > pg_ls_***dir style might be better (e.g. pg_ls_archive_statusdir).
> > But everyone kn
So, circling back to the very beginning of this thread where I worried
about all the compile warnings we get on NetBSD-current, I'm pleased
to report that HEAD compiles warning-free so long as you define
PG_PRINTF_ATTRIBUTE to "__syslog__" rather than "gnu_printf".
So attached is a proposed patch
On Mon, Oct 8, 2018 at 1:17 AM Thomas Munro
wrote:
> That's because the bgworker startup path doesn't contain a call to
> srandom(...distinguishing stuff...), unlike BackendRun(). I suppose
> do_start_bgworker() could gain a similar call... or perhaps that call
> should be moved into InitPostmast
On Sun, Oct 7, 2018 at 3:30 PM Thomas Munro
wrote:
> On Sun, Oct 7, 2018 at 5:53 AM Tom Lane wrote:
> > Thomas Munro writes:
> > > Thanks. Here is a version squashed into one commit, with a decent
> > > commit message and a small improvement: the code to create the hash
> > > table is moved int
Bump, and curious if anyone on hackers has any ideas here: of particular
interest is why the (pk, created_at) index can possibly be more valuable
than the (created_at, pk) variant since the former effectively implies
having to scan the entire index.
On Fri, Sep 7, 2018 at 12:17 PM James Coleman wr
On Fri, Jul 7, 2017 at 12:45 AM Alik Khilazhev
wrote:
> PostgreSQL shows very bad results in YCSB Workload A (50% SELECT and 50%
> UPDATE of random row by PK) on benchmarking with big number of clients using
> Zipfian distribution. MySQL also has decline but it is not significant as it
> is in
Andres Freund writes:
> On October 8, 2018 10:14:34 AM PDT, Tom Lane wrote:
>> Surely there is some way that we can directly test whether we're inside
>> a procedure or not? I think the logic should be basically
>> ...
> Seems more reasonable from here.
We are rapidly running out of time to ge
Hi Everyone!
At Percona, we are seeking a remote (work from home) Consultant. The
PostgreSQL Consultant is an individual who is focused on providing the
highest quality technical advice to our Percona customers. You’re the face
of Percona to our customers, and their success in achieving their goa
In the wake of commit 6eb3eb577, I believe we have no remaining buildfarm
animals that don't handle minus zero per spec. gaur is the only one that
was failing on the minus-zero-dependent geometry test cases introduced by
a3d284485, and I've already verified that this makes it pass again.
I think
>
> >I am thinking so simple number should be good enough. We can require
> >equality - Just I need a signal so some is wrong - better than Postgres
> >crash.
>
> It'd cause constant conflicts and / or we would regularly forget updating
> it. It's not that trivial to determine what influences ABI c
Andres Freund writes:
>> I am thinking so simple number should be good enough. We can require
>> equality - Just I need a signal so some is wrong - better than Postgres
>> crash.
> It'd cause constant conflicts and / or we would regularly forget updating it.
> It's not that trivial to determine
Masahiko Sawada wrote:
> Maybe the patch needs regression tests for the new function. And I'd
> suggest to make the function name more clear by changing to
> pg_promote_server(), pg_promote_standby() and so on.
Thanks for the review.
The attached patch has regression tests - I though it would be
On October 8, 2018 10:29:56 AM PDT, Pavel Stehule
wrote:
>po 8. 10. 2018 v 19:24 odesílatel Andres Freund
>napsal:
>
>>
>>
>> On October 8, 2018 10:16:54 AM PDT, Pavel Stehule
>
>> wrote:
>> >po 8. 10. 2018 v 17:59 odesílatel Andres Freund
>> >napsal:
>> >
>> >> Hi,
>> >>
>> >> On 2018-10-08
po 8. 10. 2018 v 19:24 odesílatel Andres Freund napsal:
>
>
> On October 8, 2018 10:16:54 AM PDT, Pavel Stehule
> wrote:
> >po 8. 10. 2018 v 17:59 odesílatel Andres Freund
> >napsal:
> >
> >> Hi,
> >>
> >> On 2018-10-08 11:43:42 -0400, Tom Lane wrote:
> >> > Andres Freund writes:
> >> > > On O
Hi,
On October 8, 2018 10:14:34 AM PDT, Tom Lane wrote:
>Peter Eisentraut writes:
>> On 02/10/2018 16:58, Andres Freund wrote:
>>> It's a bit weird to make this decision based on these two timestamps
>>> differing. For one, it only indirectly seems to be guaranteed that
>>> xactStartTimestamp i
On October 8, 2018 10:16:54 AM PDT, Pavel Stehule
wrote:
>po 8. 10. 2018 v 17:59 odesílatel Andres Freund
>napsal:
>
>> Hi,
>>
>> On 2018-10-08 11:43:42 -0400, Tom Lane wrote:
>> > Andres Freund writes:
>> > > On October 8, 2018 8:03:56 AM PDT, Tom Lane
>wrote:
>> > >> A look in guc.c shows
po 8. 10. 2018 v 17:59 odesílatel Andres Freund napsal:
> Hi,
>
> On 2018-10-08 11:43:42 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On October 8, 2018 8:03:56 AM PDT, Tom Lane wrote:
> > >> A look in guc.c shows that jit defaults to "on" whether or not JIT is
> > >> enabled at compi
Peter Eisentraut writes:
> On 02/10/2018 16:58, Andres Freund wrote:
>> It's a bit weird to make this decision based on these two timestamps
>> differing. For one, it only indirectly seems to be guaranteed that
>> xactStartTimestamp is even set to anything here (to 0 by virtue of being
>> a globa
On 2018-10-08 18:28:52 +0300, Konstantin Knizhnik wrote:
>
>
> On 08.10.2018 18:24, Andres Freund wrote:
> >
> > On October 8, 2018 2:04:28 AM PDT, Konstantin Knizhnik
> > wrote:
> > >
> > > On 05.10.2018 11:04, Michael Paquier wrote:
> > > > On Fri, Oct 05, 2018 at 10:06:45AM +0300, Konstant
On 08/03/2018 05:08 PM, Fabien COELHO wrote:
Among other use cases, this is useful where a database name is
visible but the database is not dumpable by the user. Examples of
this occur in some managed Postgres services.
This looks like a reasonable feature.
Thanks for the review.
I
Hi,
On 2018-10-08 11:43:42 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On October 8, 2018 8:03:56 AM PDT, Tom Lane wrote:
> >> A look in guc.c shows that jit defaults to "on" whether or not JIT is
> >> enabled at compile time.
> >> This seems, at best, rather user-unfriendly.
> >> And it
On 10/8/18 5:20 PM, Bruce Momjian wrote:
Uh, where are you looking? We don't rebuild the beta docs until the
next beta release, but you can see the changes in the developer docs:
https://www.postgresql.org/docs/devel/static/release-11.html
I looked in doc/src/sgml/release-11.sgml
And
Andres Freund writes:
> On October 8, 2018 8:03:56 AM PDT, Tom Lane wrote:
>> A look in guc.c shows that jit defaults to "on" whether or not JIT is
>> enabled at compile time.
>> This seems, at best, rather user-unfriendly.
>> And it's not like our conventions for other compile-option-affected
>
I wrote:
> Keeping that comparison in mind, I'm inclined to think that 0001
> is the best thing to do for now. The incremental win from 0002
> is not big enough to justify the API break it creates, while your
> 0005 is not really attacking the problem the right way.
I've pushed 0001 now. I belie
On 08.10.2018 18:24, Andres Freund wrote:
On October 8, 2018 2:04:28 AM PDT, Konstantin Knizhnik
wrote:
On 05.10.2018 11:04, Michael Paquier wrote:
On Fri, Oct 05, 2018 at 10:06:45AM +0300, Konstantin Knizhnik wrote:
As you can notice, XID 2004495308 is encountered twice which cause
er
po 8. 10. 2018 v 17:22 odesílatel Andres Freund napsal:
>
>
> On October 8, 2018 8:16:06 AM PDT, Pavel Stehule
> wrote:
> >po 8. 10. 2018 v 17:10 odesílatel Andres Freund
> >napsal:
> >
> >>
> >>
> >> On October 8, 2018 8:03:56 AM PDT, Tom Lane
> >wrote:
> >> >Andres Freund writes:
> >> >> Wh
On October 8, 2018 2:04:28 AM PDT, Konstantin Knizhnik
wrote:
>
>
>On 05.10.2018 11:04, Michael Paquier wrote:
>> On Fri, Oct 05, 2018 at 10:06:45AM +0300, Konstantin Knizhnik wrote:
>>> As you can notice, XID 2004495308 is encountered twice which cause
>error in
>>> KnownAssignedXidsAdd:
>>>
On Mon, Oct 8, 2018 at 12:42:39PM +0200, Peter Eisentraut wrote:
> On 05/10/2018 19:01, Bruce Momjian wrote:
> > On Fri, Oct 5, 2018 at 04:53:34PM +0200, Peter Eisentraut wrote:
> >> On 23/05/2018 08:46, Heikki Linnakangas wrote:
> >>> "tls-unique" and "tls-server-end-point" are overly technical
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
Hi
I tested this patch. This patch removes some duplicate ro
On October 8, 2018 8:16:06 AM PDT, Pavel Stehule
wrote:
>po 8. 10. 2018 v 17:10 odesílatel Andres Freund
>napsal:
>
>>
>>
>> On October 8, 2018 8:03:56 AM PDT, Tom Lane
>wrote:
>> >Andres Freund writes:
>> >> Where is the jit=on coming from? Config from before it was turned
>> >off?
>> >
>>
On Mon, Oct 8, 2018 at 12:05:03PM +0200, Adrien NAYRAT wrote:
> On 9/20/18 8:47 AM, Adrien Nayrat wrote:
> >On 8/25/18 11:24 PM, Peter Geoghegan wrote:
> >>On Sat, Aug 25, 2018 at 2:18 PM, Bruce Momjian wrote:
> I think that's less "our" logic and more yours, that has become
> established
po 8. 10. 2018 v 17:10 odesílatel Andres Freund napsal:
>
>
> On October 8, 2018 8:03:56 AM PDT, Tom Lane wrote:
> >Andres Freund writes:
> >> Where is the jit=on coming from? Config from before it was turned
> >off?
> >
> >A look in guc.c shows that jit defaults to "on" whether or not JIT is
>
On October 8, 2018 8:10:45 AM PDT, Andres Freund wrote:
>
>
>On October 8, 2018 8:03:56 AM PDT, Tom Lane wrote:
>> This seems, at best, rather user-unfriendly.
>>And it's not like our conventions for other compile-option-affected
>>GUCs, eg the SSL ones.
>
>That was intentional, even though it
On October 8, 2018 8:03:56 AM PDT, Tom Lane wrote:
>Andres Freund writes:
>> Where is the jit=on coming from? Config from before it was turned
>off?
>
>A look in guc.c shows that jit defaults to "on" whether or not JIT is
>enabled at compile time.
I thought Pavel was talking about 11 somehow
po 8. 10. 2018 v 16:58 odesílatel Andres Freund napsal:
> Hi
>
> On October 8, 2018 2:51:15 AM PDT, Pavel Stehule
> wrote:
> >Hi
> >
> >I configured PostgreSQL without JIT support, but JIT is active by
> >default
> >
> >postgres=# show jit;
> >┌─┐
> >│ jit │
> >╞═╡
> >│ on │
> >└─┘
Andres Freund writes:
> Where is the jit=on coming from? Config from before it was turned off?
A look in guc.c shows that jit defaults to "on" whether or not JIT is
enabled at compile time. This seems, at best, rather user-unfriendly.
And it's not like our conventions for other compile-option-af
Pavel Stehule writes:
> The user sent a plan:
> QUERY PLAN
> Merge Semi Join (cost=82.97..580.24 rows=580 width=8) (actual
> time=0.503..9557.396 rows=721 loops=1)
> Merge Cond: (tips.users_id = follows.users_id_to)
> -> Index Scan using tips_idx_users_id01 on tips (cost=0.43..8378397.19
>
Hi
On October 8, 2018 2:51:15 AM PDT, Pavel Stehule
wrote:
>Hi
>
>I configured PostgreSQL without JIT support, but JIT is active by
>default
>
>postgres=# show jit;
>┌─┐
>│ jit │
>╞═╡
>│ on │
>└─┘
>(1 row)
Where is the jit=on coming from? Config from before it was turned off?
>Un
Here is a rebased version of the patch. It includes some fixes after an
off-list review by Konstantin Knizhnik.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/nodes/equalfuncs.c b/src/backend/nodes/equalfuncs.c
inde
Andrew Dunstan writes:
> On 10/08/2018 09:13 AM, Michael Paquier wrote:
>> I had exactly the same thought, but with "git ls-files". There are
>> still some files which should not be indented, like ppport.h which is
>> generated automatically still part of the tree.
> That's already explicitly ex
On 02/10/2018 07:38, Michael Paquier wrote:
> The patch set does not apply anymore, so this patch is moved to next CF,
> waiting on author.
Attached is a rebased patch set. No functionality changes.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
Hi
I try to understand to a issue
https://stackoverflow.com/questions/52685384/subquery-performance-on-simple-case
The user sent a plan:
QUERY PLAN
Merge Semi Join (cost=82.97..580.24 rows=580 width=8) (actual
time=0.503..9557.396 rows=721 loops=1)
Merge Cond: (tips.users_id = follows.users_i
On 10/08/2018 09:13 AM, Michael Paquier wrote:
On Mon, Oct 08, 2018 at 08:33:38AM -0400, Andrew Dunstan wrote:
Seems reasonable - I tend to do vpath builds so this hasn't been a problem
for me ;-)
+1.
I wonder if a more general solution might be a good idea. Say like ignoring
everything po
On 2018-Oct-08, Alvaro Herrera wrote:
> On 2018-Oct-08, Michael Paquier wrote:
>
> > The fix is obvious because currentCommand is a pointer and not an Oid.
> > Please see attached. Should I fix it myself?
Pushed now, thanks.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
Postgr
Andrew Dunstan writes:
> On 10/08/2018 05:49 AM, Peter Eisentraut wrote:
>> pgindent spends a long time digging through tmp_check and tmp_install
>> directories and ends up re-indenting installed header files. How about
>> excluding those directories, like below or directly in the script?
> I wo
On Mon, Oct 08, 2018 at 08:33:38AM -0400, Andrew Dunstan wrote:
> Seems reasonable - I tend to do vpath builds so this hasn't been a problem
> for me ;-)
+1.
> I wonder if a more general solution might be a good idea. Say like ignoring
> everything pointed to by
>
> git status --porcelain --
On 2018-Oct-08, Michael Paquier wrote:
> Hi Alvaro,
>
> On Sat, Oct 06, 2018 at 10:18:46PM +, Alvaro Herrera wrote:
> > Fix event triggers for partitioned tables
> >
> > Index DDL cascading on partitioned tables introduced a way for ALTER
> > TABLE to be called reentrantly. This caused an a
On 10/08/2018 05:49 AM, Peter Eisentraut wrote:
pgindent spends a long time digging through tmp_check and tmp_install
directories and ends up re-indenting installed header files. How about
excluding those directories, like below or directly in the script?
diff --git a/src/tools/pgindent/excl
On Sun, Oct 7, 2018 at 11:12 AM Konstantin Knizhnik
wrote:
>
> On 07.10.2018 07:58, Amit Kapila wrote:
> > On Sat, Oct 6, 2018 at 9:40 PM Tom Lane wrote:
> >> Konstantin Knizhnik writes:
> >>> On 06.10.2018 00:25, Tom Lane wrote:
> So maybe the right answer is to change the parallel mode in
On 10/7/18, Tom Lane wrote:
> John Naylor writes:
>> On 10/6/18, Thomas Munro wrote:
>>> On Sat, Oct 6, 2018 at 7:47 AM John Naylor wrote:
A while back, Robert Haas noticed that the space taken up by very
small tables is dominated by the FSM [1]. Tom suggested that we could
preve
On 05/10/2018 19:01, Bruce Momjian wrote:
> On Fri, Oct 5, 2018 at 04:53:34PM +0200, Peter Eisentraut wrote:
>> On 23/05/2018 08:46, Heikki Linnakangas wrote:
>>> "tls-unique" and "tls-server-end-point" are overly technical to users.
>>> They don't care which one is used, there's no difference in
po 8. 10. 2018 v 12:06 odesílatel Thomas Munro <
thomas.mu...@enterprisedb.com> napsal:
> On Mon, Oct 8, 2018 at 10:52 PM Pavel Stehule
> wrote:
> >
> > Hi
> >
> > I configured PostgreSQL without JIT support, but JIT is active by default
>
> I think that happens when llvmjit.so is present (ie fro
On Mon, Oct 8, 2018 at 10:52 PM Pavel Stehule wrote:
>
> Hi
>
> I configured PostgreSQL without JIT support, but JIT is active by default
I think that happens when llvmjit.so is present (ie from last time you
built with JIT support and ran make install). You need to remove it.
--
Thomas Munro
h
On 9/20/18 8:47 AM, Adrien Nayrat wrote:
On 8/25/18 11:24 PM, Peter Geoghegan wrote:
On Sat, Aug 25, 2018 at 2:18 PM, Bruce Momjian wrote:
I think that's less "our" logic and more yours, that has become
established because you've done most of the major release notes for a
long time. I'm not tr
Hi
I configured PostgreSQL without JIT support, but JIT is active by default
postgres=# show jit;
┌─┐
│ jit │
╞═╡
│ on │
└─┘
(1 row)
Unfortunately - this combination does crashes on some bigger queries.
Regards
Pavel
pgindent spends a long time digging through tmp_check and tmp_install
directories and ends up re-indenting installed header files. How about
excluding those directories, like below or directly in the script?
diff --git a/src/tools/pgindent/exclude_file_patterns
b/src/tools/pgindent/exclude_file_p
On 08.10.2018 12:14, Michael Paquier wrote:
On Mon, Oct 08, 2018 at 12:04:28PM +0300, Konstantin Knizhnik wrote:
The simplest way to fix the problem is to ignore duplicates before adding
them to KnownAssignedXids.
We in any case perform sort i this place...
I may of course be missing somethi
On 05/10/2018 14:15, Peter Eisentraut wrote:
> On 04/10/2018 22:07, Andres Freund wrote:
>> On 2018-10-04 12:15:28 -0700, Lukas Fittl wrote:
>>> Was this intentional, or an oversight?
>>>
>>> If welcome, I would be happy to work on a patch. Whilst slightly confusing
>>> in terms of naming, we could
Hello,
On 10/6/18 7:50 PM, Alvaro Herrera wrote:
here's my proposed patch.
There is an incorrect assert condition within
EventTriggerCollectAlterTableSubcmd(). Maybe it should be like this?
- Assert(OidIsValid(currentEventTriggerState->currentCommand));
+ Assert(currentEventTriggerState
On Mon, Oct 08, 2018 at 12:04:28PM +0300, Konstantin Knizhnik wrote:
> The simplest way to fix the problem is to ignore duplicates before adding
> them to KnownAssignedXids.
> We in any case perform sort i this place...
I may of course be missing something, but shouldn't we not have
duplicates in
Hi Alvaro,
On Sat, Oct 06, 2018 at 10:18:46PM +, Alvaro Herrera wrote:
> Fix event triggers for partitioned tables
>
> Index DDL cascading on partitioned tables introduced a way for ALTER
> TABLE to be called reentrantly. This caused an an important deficiency
> in event trigger support to b
On Mon, Oct 08, 2018 at 08:40:49AM +0200, Laurenz Albe wrote:
> I'm fine with it.
Thanks, I have pushed this version and back-patched to v11.
--
Michael
signature.asc
Description: PGP signature
On 05.10.2018 11:04, Michael Paquier wrote:
On Fri, Oct 05, 2018 at 10:06:45AM +0300, Konstantin Knizhnik wrote:
As you can notice, XID 2004495308 is encountered twice which cause error in
KnownAssignedXidsAdd:
if (head > tail &&
TransactionIdFollowsOrEquals(KnownAssignedXids[he
Before 5220bb7533f a note in ddl.sgml used to mention that run-time
pruning was only implemented for Append. When we got MergeAppend
support the commit updated this to mention MergeAppend is supported
too. This is slightly weird as it's not all that obvious what exactly
isn't supported when we ment
> Attached is an updated patch.
That's OK now, the patch applying is without any errors.
I have no more remarks.
>Пятница, 5 октября 2018, 13:04 +03:00 от Peter Eisentraut
>:
>
>On 03/10/2018 13:51, Andrey Klychkov wrote:
>> 1. Patch was applied without any errors except a part related to
>> d
Michael Paquier wrote:
> On Sun, Oct 07, 2018 at 05:14:30PM +0900, Michael Paquier wrote:
> > Here is a counter-proposal:
> > "cannot use ONLY for foreign key on partitioned table \"%s\" referencing
> > relation \"%s\""
> >
> > +-- also, adding a NOT VALID foreign key should fail
> > +ALTER TABLE
92 matches
Mail list logo
