On Fri, 30 Nov 2018 at 20:15, Kato, Sho wrote:
> Will we improve creating the generic plan in the future?
I think Amit's patch will improve the UPDATE/DELETE planning
performance even when nothing can be pruned. Currently planning those
are quite inefficient as a separate grouping planner call i
On Sun, Nov 25, 2018 at 3:05 PM Vik Fearing
wrote:
>
> I assume you meant 200 rows there, but the correct number of rows to
> return is 203 for that query. Please fix it.
>
Attach is a patch that include a fix for it
regards
Surafel
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/s
Hi,
> Hello.
>
> At Thu, 29 Nov 2018 09:16:01 +0900 (JST), Tatsuo Ishii
> wrote in <20181129.091601.830026250066724330.t-is...@sraoss.co.jp>
>> >>> Hi, it makes sense to me. One can submit transaction again same as
>> >>> other cases you mentioned.
>> >>>
>> >>> I didn't attach the patch but ac
On Friday, November 30, 2018 3:44 PM, Amit Langote wrote:
> Yeah, maybe we haven't explained in the documentation where generic plans
> are described that making them for partitioned table is an expensive
> affair.
Will we improve creating the generic plan in the future?
For example, if there is U
Hello.
At Thu, 29 Nov 2018 09:16:01 +0900 (JST), Tatsuo Ishii
wrote in <20181129.091601.830026250066724330.t-is...@sraoss.co.jp>
> >>> Hi, it makes sense to me. One can submit transaction again same as
> >>> other cases you mentioned.
> >>>
> >>> I didn't attach the patch but according to my sim
On Fri, 30 Nov 2018 at 19:44, Amit Langote
wrote:
> Yeah, maybe we haven't explained in the documentation where generic plans
> are described that making them for partitioned table is an expensive
> affair. Although, by definition, they are built once for a given query
> and PG 11 with it's execu
On Thu, Nov 29, 2018 at 01:10:57PM +0100, Dmitry Dolgov wrote:
> On Sun, Aug 12, 2018 at 8:48 AM Noah Misch wrote:
> > With 9.3 having a few months left, that's less interesting, but ...
> I'm a bit out of context, but taking into account that 9.3 is already beyond
> EOL, is it still interesting?
On Fri, 16 Nov 2018 at 12:06, Thomas Munro
wrote:
> Oh, I just found the throw-away patch I wrote ages ago down the back
> of the sofa. Here's a rebase. It somehow breaks initdb so you have
> to initdb with unpatched. Unfortunately I couldn't seem to measure
> any speed-up on a random EDB test
Hi
čt 29. 11. 2018 v 14:44 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Fri, Sep 21, 2018 at 1:30 PM Pavel Stehule
> wrote:
> >
> > Thank you for comments
> >
> > Attached updated patch
>
> Unfortunately, current version of the patch doesn't pass make check,
> something
> is m
Hello.
At Wed, 28 Nov 2018 14:41:40 +0900, Tatsuro Yamada
wrote in
<54bd214b-d0d3-8654-e71f-45e7b4f97...@lab.ntt.co.jp>
> On 2018/11/28 13:14, Kyotaro HORIGUCHI wrote:
> > Hello.
> > At Wed, 28 Nov 2018 11:27:23 +0900, Tatsuro Yamada
> > wrote in
> >
> >> Hi,
> >>
> >> On 2018/11/26 11:05, Ta
On 2018/11/30 14:58, David Rowley wrote:
> On Fri, 30 Nov 2018 at 15:04, Amit Langote
> wrote:
>>
>> On 2018/11/29 19:54, David Rowley wrote:
>>> The problem is only made worse in PG11 from PG10
>>> because generating the custom plan has become faster than it
>>> previously was due to the new part
On Thu, Nov 29, 2018 at 1:49 PM Alvaro Herrera
wrote:
> Thanks! I pushed this with two changes -- one was to reword the docs a
> bit more, and the other was to compute in_sample only if it's going to
> be used (when exceeded is true). I hope this won't upset any compilers ...
>
This is a great
On Thu, Nov 29, 2018 at 04:20:24PM +0900, Michael Paquier wrote:
> From what I can see in my backlog, this never actually got into the
> tree, and it seems to me that fixing those issues is always better than
> nothing:
> https://www.postgresql.org/message-id/20180309075538.gd9...@paquier.xyz
>
>
On Fri, 30 Nov 2018 at 15:04, Amit Langote
wrote:
>
> On 2018/11/29 19:54, David Rowley wrote:
> > The problem is only made worse in PG11 from PG10
> > because generating the custom plan has become faster than it
> > previously was due to the new partition pruning code which might make
> > it appe
On Fri, Nov 30, 2018 at 01:36:43AM +, Michael Paquier wrote:
> Switch pg_verify_checksums back to a blacklist
>
> This basically reverts commit d55241af705667d4503638e3f77d3689fd6be31,
> leaving around a portion of the regression tests still adapted with
> empty relation files, and corrupted c
Hi,
>
> PFA, latest patchset which implements the above.
>
The newly added test_decoding test was failing due to a slight
expected output mismatch. The attached patch-set corrects that.
Regards,
Nikhil
> Regards,
> Nikhil
> > regards
> >
> > --
> > Tomas Vondra http://www.2ndQ
Hi Ideriha-san,
Hi, it makes sense to me. One can submit transaction again same as
other cases you mentioned.
I didn't attach the patch but according to my simple experiment in
psql the output would become the following:
FATAL: terminating connection due to idle
> "Andrew" == Andrew Gierth writes:
Andrew> Here is a script that reproduces the issue conveniently.
Andrew> This is targetted for pg11, might also work on pg10
Nope, forgot I'd used non-atomic DO, so pg11 or later only.
It could be rewritten easily enough to avoid that.
--
Andrew (irc:R
Here is a script that reproduces the issue conveniently.
This is targetted for pg11, might also work on pg10 (uses declarative
partitioning as a convenient way to spread traffic over many tables).
What it does is:
- spin up a new server in ./data1
- populate some data
- start a base backup
On Thursday, November 29, 2018 7:55 PM David Rowley wrote:
>I don't quite see any way around that other than ensuring you have
>plan_cache_mode as >force_custom_plan, but then you're still going against the
>manual's recommendations about not >having thousands of partitions.
Ok, I got it.
Reg
thanks for the reply, amul.
-
--
Thanks,
Rajan.
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On Fri, Nov 30, 2018 at 3:48 AM, Dmitry Dolgov wrote:
> Hi,
>
> Thanks for reviewing. Since another CF is about to end, maybe you can
> post the full review feedback?
Since I had been busy with my private work, I couldn't review.
I want to review next commit fest. I am sorry I postponed many tim
On Fri, Nov 30, 2018 at 10:48 AM Michael Paquier wrote:
>
> On Thu, Nov 29, 2018 at 06:21:34PM +0100, Dmitry Dolgov wrote:
> > Nothing changed since then, but also the patch got not enough review to say
> > that there was substantial feedback. I'll move it to the next CF.
>
> I would have suggeste
On 2018/11/29 19:54, David Rowley wrote:
> The problem is only made worse in PG11 from PG10
> because generating the custom plan has become faster than it
> previously was due to the new partition pruning code which might make
> it appear we can handle more partitions than we could previously,
Actu
On Wed, Nov 28, 2018 at 06:36:25AM +0900, Michael Paquier wrote:
> Yes, let's do so rather sooner than later if there are no objections
> from others. I am going to ping the other thread about what's discussed
> here additionally in case folks missed what you reported. Fixing the
> temp file issu
On Thu, Nov 29, 2018 at 12:15:08PM -0500, Tom Lane wrote:
> I'm also wondering whether to back-patch such a change. Since we've
> not heard field complaints that match up to this problem, it may be
> that it's unlikely enough that fixing it in HEAD is good enough.
HEAD sounds good enough for to m
On Thu, Nov 29, 2018 at 06:21:34PM +0100, Dmitry Dolgov wrote:
> Nothing changed since then, but also the patch got not enough review to say
> that there was substantial feedback. I'll move it to the next CF.
I would have suggested to mark the patch as returned with feedback
instead as the thing d
On Thu, Nov 29, 2018 at 11:03:54AM +0900, Michael Paquier wrote:
> Thanks David for the input. I think that I will be able to finish
> wrapping and commit this stuff tomorrow.
And done. I kept the split into two commits for clarity as suggested by
Stephen, as bisect would actually complain only
On Thu, Nov 29, 2018 at 07:31:02PM -0500, Stephen Frost wrote:
> * Tsunakawa, Takayuki (tsunakawa.ta...@jp.fujitsu.com) wrote:
>> From: Christoph Berg [mailto:christoph.b...@credativ.de]
>> > A customer was complaining that the "checkpoint starting: xlog"
>> > message was not included in the grand
On Fri, Nov 30, 2018 at 1:17 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Mon, Oct 1, 2018 at 8:54 AM Michael Paquier wrote:
> >
> > On Wed, Jun 06, 2018 at 07:03:47PM +0530, Amit Kapila wrote:
> > > I think Robert's chash stuff [1] might be helpful to reduce the contention
> > > you a
Greetings,
* Tsunakawa, Takayuki (tsunakawa.ta...@jp.fujitsu.com) wrote:
> From: Christoph Berg [mailto:christoph.b...@credativ.de]
> > A customer was complaining that the "checkpoint starting: xlog"
> > message was not included in the grand PG10 rename of user-visible bits.
> > The attached patch
From: Christoph Berg [mailto:christoph.b...@credativ.de]
> A customer was complaining that the "checkpoint starting: xlog"
> message was not included in the grand PG10 rename of user-visible bits.
> The attached patch fixes that.
Can we make use of this chance to change elog() to ereport(), so tha
On Fri, Oct 26, 2018 at 2:08 AM Marius Timmer
wrote:
> We (Julian and I) would like to show you the seventh version of this
> patch which includes all the things mentioned before. Unfortunately
> we did not find the time to do this earlier.
+case uaCert:
case uaTrust:
Maybe add
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2018-Nov-29, Robert Haas wrote:
> > On Thu, Nov 29, 2018 at 4:10 AM Michael Paquier wrote:
> > > On Thu, Nov 29, 2018 at 10:04:12AM +0100, Christoph Berg wrote:
> > > > There's hundreds of other internal uses of xlog that were not
Hi,
On 2018-11-29 16:23:42 -0500, Robert Haas wrote:
> Generally, I think Andres is wrong to argue that immutability
> shouldn't mean *anything* across major versions. If we can readily
> foresee that something is going to change in the future, then we
> shouldn't mark it immutable. However:
I w
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-11-29 16:34:13 -0500, Tom Lane wrote:
> > Yeah, I was disappointed too. OpenSSL has had a squirrelly enough track
> > record that it'd be nice not to be totally dependent on it.
>
> GnuTLS seems, if anything, worse though. There's
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Thu, Nov 29, 2018 at 8:28 AM Peter Eisentraut
> > wrote:
> >> I have decided that I don't want to pursue this patch anymore. It has
> >> served its purpose having allowed us to refine the SSL library
> >> abstraction
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> Generally, I think Andres is wrong to argue that immutability
> shouldn't mean *anything* across major versions. If we can readily
> foresee that something is going to change in the future, then we
> shouldn't mark it immutable. However:
> On Sun, Oct 14, 2018 at 8:30 PM Matheus de Oliveira
> wrote:
>
> Updated the last patch so it can apply cleanly on HEAD.
>
> About the bugfixes, do you think it is better to move to another thread?
I think it makes sense, this way discussions on two relatively different topics
will not interfe
On 2018-Nov-29, Robert Haas wrote:
> On Thu, Nov 29, 2018 at 4:10 AM Michael Paquier wrote:
> > On Thu, Nov 29, 2018 at 10:04:12AM +0100, Christoph Berg wrote:
> > > There's hundreds of other internal uses of xlog that were not touched
> > > either, only the user-facing parts were changed.
> >
>
Thanks! I pushed this with two changes -- one was to reword the docs a
bit more, and the other was to compute in_sample only if it's going to
be used (when exceeded is true). I hope this won't upset any compilers ...
I wonder if there's any sensible way to verify the behavior in an
automated fas
Hi,
On 2018-11-29 16:34:13 -0500, Tom Lane wrote:
> Yeah, I was disappointed too. OpenSSL has had a squirrelly enough track
> record that it'd be nice not to be totally dependent on it.
GnuTLS seems, if anything, worse though. There's obviously good reasons
to add support for TLS libraries that
On 29/11/2018 08:26, Lætitia Avrot wrote:
> # What stays in my mind
>
> * It's pretty difficult to handle line breaks
> * Markdown is not standardised and several flavours exist for table
> implementation (so why favor one over the others?)
>
> # The question I'd like to ask you
> So now, I thin
Robert Haas writes:
> On Thu, Nov 29, 2018 at 8:28 AM Peter Eisentraut
> wrote:
>> I have decided that I don't want to pursue this patch anymore. It has
>> served its purpose having allowed us to refine the SSL library
>> abstractions so that alternative implementations such as macOS Secure
>> T
On Thu, Nov 29, 2018 at 4:10 AM Michael Paquier wrote:
> On Thu, Nov 29, 2018 at 10:04:12AM +0100, Christoph Berg wrote:
> > There's hundreds of other internal uses of xlog that were not touched
> > either, only the user-facing parts were changed.
>
> I have heard of them ;)
> Just wondering if th
On Thu, Nov 29, 2018 at 8:28 AM Peter Eisentraut
wrote:
> On 29/11/2018 13:28, Dmitry Dolgov wrote:
> > Unfortunately it needs to be rebased one more time, could you do this? Also
> > I'm
> > wondering about this:
> >
> >> I'm moving this patch forward to CF 2018-09, since it's not going to be
>
On Fri, 30 Nov 2018 at 02:01, Peter Eisentraut
wrote:
> committed
Thanks
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Thu, Nov 29, 2018 at 4:01 PM Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Thu, Nov 29, 2018 at 3:50 PM Stephen Frost wrote:
> > > I'd suggest you read through the rest of the thread and see my response
> > > to Tom.
> >
> > I already did that.
>
> Great, then it's
On 11/29/18 6:35 PM, Alvaro Herrera wrote:
>
> Sounds good to me (we -> you, I suppose?). I'd tweak the extra_desc for
> log_min_duration_statement too, because we no longer log "all" when the
> rate is <1; maybe "Zero prints all queries, subject to
> log_statement_sample_rate. -1 turns this fea
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 29, 2018 at 3:50 PM Stephen Frost wrote:
> > I'd suggest you read through the rest of the thread and see my response
> > to Tom.
>
> I already did that.
Great, then it's unclear, to me at least, what you're getting at in your
On Thu, Nov 29, 2018 at 3:50 PM Stephen Frost wrote:
> I'd suggest you read through the rest of the thread and see my response
> to Tom.
I already did that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Nov 28, 2018 at 9:17 PM Stephen Frost wrote:
> > > Actually, some geometric comparisons are performed counting
> > > tolerance margin, the validity of which is in doubt. Their
> > > behavior has been changed in recent major versio
On Wed, Nov 28, 2018 at 9:17 PM Stephen Frost wrote:
> > Actually, some geometric comparisons are performed counting
> > tolerance margin, the validity of which is in doubt. Their
> > behavior has been changed in recent major version and still has a
> > room for improvement, and the functions are
On 11/29/2018 12:46 PM, Tom Lane wrote:
Alvaro Herrera writes:
On 2018-Nov-28, Tom Lane wrote:
Color me skeptical --- ruleutils has never especially been designed
to be fast, and I can't see that the overhead of this is going to be
acceptable to anybody who needs pg_stat_statements in producti
On 11/29/2018 10:59 AM, Stephen Frost wrote:
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
On 2018-Nov-28, Tom Lane wrote:
Alvaro Herrera writes:
On 2018-Nov-28, Tom Lane wrote:
This would also entail rather significant overhead to find out schema
names and interpolate them
Alvaro Herrera writes:
> On 2018-Nov-28, Tom Lane wrote:
>> Color me skeptical --- ruleutils has never especially been designed
>> to be fast, and I can't see that the overhead of this is going to be
>> acceptable to anybody who needs pg_stat_statements in production.
> Good point.
> Maybe we ca
> On Wed, Oct 10, 2018 at 7:10 PM Chris Travers
> wrote:
>
>> More generally, I'd like this material to be code comments. It's the
>> kind of stuff that gets outdated before long if it's kept separate.
>
> The problem is that code comments are not going to be good places to document
> "how do I
On 11/29/2018 10:47 AM, Alvaro Herrera wrote:
On 2018-Nov-28, Tom Lane wrote:
Alvaro Herrera writes:
On 2018-Nov-28, Tom Lane wrote:
This would also entail rather significant overhead to find out schema
names and interpolate them into the text.
True. I was thinking that the qualified-names
Alexander Kuzmenkov writes:
> Oh, one more thing: I see a warning without --enable-cassert in
> create_resultscan_plan, because rte is only used in an Assert.
> src/backend/optimizer/plan/createplan.c:3457:17: warning: variable ‘rte’
> set but not used [-Wunused-but-set-variable]
> RangeTblEn
> On Mon, Aug 13, 2018 at 8:48 PM Robert Haas wrote:
>
> I agree with the critiques from Robbie Harwood and Michael Paquier
> that the way in that compression is being hooked into the existing
> architecture looks like a kludge. I'm not sure I know exactly how it
> should be done, but the current
Alexander Kuzmenkov writes:
> I was also looking at this patch, here are some things I noticed:
Thanks for reviewing! I incorporated your suggestions in the v4
patch I just sent.
regards, tom lane
Mark Dilger writes:
> Patch applies cleanly on master (b238527664ec6f6c9d00dba4cc2f3dab1c8b8b04),
> compiles, and passes both 'make check-world' and 'make installcheck-world'.
Thanks for reviewing!
> The patch includes changes to the expected output of a few tests, and adds
> new code comments
> On Wed, Oct 3, 2018 at 12:51 AM Thomas Munro
> wrote:
>
> On Sat, Sep 29, 2018 at 1:07 AM Michael Banck
> wrote:
> > I've attached v4 of the patch.
>
> Hi Michael,
>
> Windows doesn't like sigaction:
>
> https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.15189
>
> I'm not s
Oh, one more thing: I see a warning without --enable-cassert in
create_resultscan_plan, because rte is only used in an Assert.
src/backend/optimizer/plan/createplan.c:3457:17: warning: variable ‘rte’
set but not used [-Wunused-but-set-variable]
RangeTblEntry *rte;
--
Alexander Kuzmenkov
Pos
> On Tue, Oct 2, 2018 at 11:12 PM Robbie Harwood wrote:
>
> Michael Paquier writes:
>
> > On Mon, Aug 06, 2018 at 05:23:28PM -0400, Robbie Harwood wrote:
> >> If you're in a position where you're using Kerberos (or most other
> >> things from the GSSAPI) for authentication, the encryption comes a
> On Tue, Oct 2, 2018 at 7:43 AM Michael Paquier wrote:
>
> On Thu, Jul 12, 2018 at 03:07:33PM -0400, Robbie Harwood wrote:
> > This patch looks good to me. +1; Álvaro, please update the CF entry
> > when you're also satisfied.
>
> The patch set does not apply anymore, so I have moved it to next
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2018-Nov-28, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > On 2018-Nov-28, Tom Lane wrote:
> > >> This would also entail rather significant overhead to find out schema
> > >> names and interpolate them into the text.
> >
> > >
> On Mon, Oct 1, 2018 at 2:55 PM Etsuro Fujita
> wrote:
>
> (2018/10/01 19:42), Michael Paquier wrote:
> > On Mon, Jul 23, 2018 at 02:17:38PM +0530, Ashutosh Bapat wrote:
> > Fujita-san, you are registered as a reviewer of this patch. Are you
> > planning to look at it soon?
>
> Yeah, I'm planni
On 2018-Nov-28, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2018-Nov-28, Tom Lane wrote:
> >> This would also entail rather significant overhead to find out schema
> >> names and interpolate them into the text.
>
> > True. I was thinking that the qualified-names version of the query
> > wou
> On Tue, Oct 2, 2018 at 4:53 AM Michael Paquier wrote:
>
> On Mon, Aug 06, 2018 at 06:00:54PM +0900, Yoshimi Ichiyanagi wrote:
> > The libpmem's pmem_map_file() supported 2M/1G(the size of huge page)
> > alignment, since it could reduce the number of page faults.
> > In addition, libpmem's pmem_m
On 2018-Nov-29, Adrien NAYRAT wrote:
> > =# select name, short_desc, extra_desc, category from pg_settings where
> > category like 'Reporting%When%' ;
> > ─[ RECORD 1
> > ]
> > name │ log_mi
> On Tue, Oct 2, 2018 at 4:42 AM Michael Paquier wrote:
>
> On Thu, Jun 28, 2018 at 04:20:53PM +0900, Masahiko Sawada wrote:
> > If there is an up-to-date information meaning either that there is no
> > tables needing vacuum or that there is only table needing vacuum but
> > being vacuumed by othe
The discussion around bug #15525 prompted me to go back and review
our previous go-round with parallelism issues in the ECPG build,
https://www.postgresql.org/message-id/flat/26240C1F-5AA0-41D6-B1F1-D336BFD14CEA%40logicalchaos.org
At that time we'd identified several maybe-issues with parallel
ECP
On 11/29/18 2:27 PM, Alvaro Herrera wrote:
=# select name, short_desc, extra_desc, category from pg_settings where
category like 'Reporting%When%' ;
─[ RECORD 1
]
name │ log_min_duration_s
> On Tue, Oct 2, 2018 at 4:22 AM Michael Paquier wrote:
>
> On Thu, May 24, 2018 at 04:00:33PM +0300, Marina Polyakova wrote:
> > Here there's a 9-th version of the patches for the precalculation of stable
> > or immutable functions, stable or immutable operators and other nonvolatile
> > expressi
> On Tue, Oct 2, 2018 at 4:16 AM Michael Paquier wrote:
>
> On Sat, Jun 30, 2018 at 09:19:13AM +1200, Gavin Flower wrote:
> > Additionally put an upper limit threshold on the number of combinations to
> > check, fairly large by default?
> >
> > If first threshold is exceeded, could consider checki
> On Tue, Oct 2, 2018 at 3:58 AM Michael Paquier wrote:
>
> On Sun, Jul 22, 2018 at 10:22:10PM +0200, Tomas Vondra wrote:
> > Could you perhaps summarize the reasoning or at least point me to the
> > relevant parts of the sources, so that I know which parts to focus on?
>
> Teodor, this patch is w
> On Mon, Oct 1, 2018 at 2:24 PM Liudmila Mantrova
> wrote:
>
> We'll continue working with Nikita and Oleg to improve the
> content before we resend an updated patch; I believe we might still need
> a separate source file if we end up having a separate chapter with usage
> examples and implement
> On Mon, Oct 1, 2018 at 9:10 AM Michael Paquier wrote:
>
> By the way, I can see that the latest patch available does not apply at
> tries to juggle with multiple concepts. I can see at least two of them:
> failover_timeout and hostorder. You should split things. I have moved
> the patch to ne
> On Mon, Oct 1, 2018 at 8:54 AM Michael Paquier wrote:
>
> On Wed, Jun 06, 2018 at 07:03:47PM +0530, Amit Kapila wrote:
> > I think Robert's chash stuff [1] might be helpful to reduce the contention
> > you are seeing.
>
> Latest patch available does not apply, so I moved it to next CF. The
> th
> On Mon, Oct 1, 2018 at 8:34 AM Michael Paquier wrote:
>
> On Fri, Mar 23, 2018 at 02:18:09PM +0100, Daniel Verite wrote:
> > There's a batch mode for pgbench in a patch posted in [1],
> > with \beginbatch and \endbatch commands, but nothing
> > for psql AFAICS.
> > psql is more complicated becau
> On Mon, Oct 1, 2018 at 8:30 AM Michael Paquier wrote:
>
> On Tue, Apr 17, 2018 at 05:58:44PM +0200, Vik Fearing wrote:
> > I think I handle that well enough with permission checking, but I'm open
> > to more debate on it.
>
> The recent version bump in pg_stat_statements (Sorry my fault!) is
> c
> On Tue, Sep 25, 2018 at 1:04 AM Joe Wildish
> wrote:
>
> All agreed. I’ll give the patch some TLC and get a new version that
> addresses the above.
Hi,
Just a reminder, that the patch still needs to be rebased, could you please do
this? I'm moving the item to the next CF.
> On Fri, Sep 28, 2018 at 10:46 AM Yamaji, Ryo
> wrote:
>
> On Tuesday, August 7, 2018 at 0:36 AM, Konstantin Knizhnik wrote:
>
> > I have registered the patch for next commitfest.
> > For some reasons it doesn't find the latest autoprepare-10.patch and still
> > refer to autoprepare-6.patch as t
Peter Eisentraut writes:
> On 28/11/2018 22:41, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> My suggestion is to either
>>> - Change the probe order to python, python3 in master, or
>>> - Don't change anything until PEP 394 is updated.
>> It's hard to evaluate the latter unless we have some i
> On Wed, Sep 26, 2018 at 5:41 PM Nikita Glukhov
> wrote:
>
> Attached 3rd version of the patches rebased onto the current master.
>
> Changes from the previous version:
> - Added support of INCLUDE columns to get_index_column_opclass() (1st patch).
> - Added parallel kNN scan support.
> - amcano
> On Wed, Jul 25, 2018 at 1:35 PM Arseny Sher wrote:
>
> Hello,
>
> I have looked through the patches and found them pretty accurate. I'd
> fixed a lot of small issues here and there; updated patchset is
> attached.
Hi,
Thank you for working on this patch. Unfortunately, the patch has some
confl
On 11/27/18, 3:53 PM, "Michael Paquier" wrote:
> On Tue, Nov 27, 2018 at 09:49:29PM +, Bossart, Nathan wrote:
>> That sounds good to me. I was actually thinking of using the same
>> retry counter that we use for pgarch_archiveXlog(), but on second
>> thought, it is probably better to have two
Hi Tomas,
> Any progress on the issues discussed in the last couple of messages?
> That is:
>
> 1) removing of the sleep() from tests
>
Done. Now the test_decoding plugin takes a new option "check-xid". We
will pass the XID which is going to be aborted via this option. The
test_decoding plugin wi
> On Fri, Sep 21, 2018 at 2:29 PM Thomas Munro
> wrote:
>
> Hi Kevin, all,
>
> /me pokes ancient thread
This amazing feeling of being like Indiana Jones, thinking whether it's worth
it to touch another ancient artifact.
On Tue, Sep 25, 2018 at 4:51 PM Kevin Grittner wrote:
>
> On Fri, Sep 21,
Dear Mentor,
I want to be a part of the organisation by mentoring the students at Google
Code-In and share my knowledge with other students and help them gain knowledge
please allow me to be a mentor at our organisation
Thanking you
Yours faithfully
Rishabh jain
Attached Resume
Resume 11-201
On 29/11/2018 01:27, Lou Picciano wrote:
> Further, I’m not sure exposing details about Cert Issuer, etc. to
> non-privileged users is much of an issue. For the most part, in most use
> cases, ‘users’ should//would/ want to know what entity is the issuer. If
> we’re talking about client certs, most
> On Fri, Sep 21, 2018 at 1:30 PM Pavel Stehule wrote:
>
> Thank you for comments
>
> Attached updated patch
Unfortunately, current version of the patch doesn't pass make check, something
is missing for xml tests. Could you please rebase it?
After that I hope someone from reviewers (Kyotaro?) ca
On 28/11/2018 22:41, Tom Lane wrote:
> Peter Eisentraut writes:
>> My suggestion is to either
>> - Change the probe order to python, python3 in master, or
>> - Don't change anything until PEP 394 is updated.
>
> It's hard to evaluate the latter unless we have some idea how soon
> that update is l
Greetings,
* Christoph Berg (christoph.b...@credativ.de) wrote:
> A customer was complaining that the "checkpoint starting: xlog"
> message was not included in the grand PG10 rename of user-visible
> bits. The attached patch fixes that.
+1
Thanks!
Stephen
signature.asc
Description: PGP signat
On 29/11/2018 13:28, Dmitry Dolgov wrote:
> Unfortunately it needs to be rebased one more time, could you do this? Also
> I'm
> wondering about this:
>
>> I'm moving this patch forward to CF 2018-09, since it's not going to be
>> ready for -07, and we're still whacking around some channel binding
=# select name, short_desc, extra_desc, category from pg_settings where
category like 'Reporting%When%' ;
─[ RECORD 1
]
name │ log_min_duration_statement
short_desc │ Sets the minimum execut
> On Fri, Sep 21, 2018 at 5:52 AM Andrey Lepikhov
> wrote:
>
> The v6 version of quick vacuum, which utilizes the amtargetdelete()
> interface for retail indextuple deletion.
> Now it is more simple and laconic.
> It must be applied after Retail-IndexTuple-Deletion-Access-Method.patch.
>
> BENCHM
> On Tue, Jul 24, 2018 at 7:25 AM Thomas Munro
> wrote:
>
> Here's a new version. I did some cosmetic clean-up, and I dropped the
> changes to pg_controldata output, replication epoch/xid processing
> code and various similar non-essential changes. For this patch I want
> just the new type + ne
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Certainly, if we make a change that we know is likely to require people to
> reindex affected indexes, that should be documented in the release notes.
> But I think it's pointless to imagine that we can achieve perfection in
> identifying trouble
1 - 100 of 125 matches
Mail list logo
