> 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
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]
>
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
> 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
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
> >
> 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
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
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
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
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
> 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
> 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
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
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
> 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
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 │
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 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
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
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
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,
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
> 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
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
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
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
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
thanks for the reply, amul.
-
--
Thanks,
Rajan.
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
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
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
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 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
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
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.
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 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
>On Mon, Nov 26, 2018 at 02:48:39PM +0900, myungkyu.lim wrote:
>> So I selected 'reply_time' because 'timestamp' was not used in stat
>> field.
>
>Fine by me. Could you send a new patch please? I am switching the patch
as
>waiting on author for now.
Ok.
Changed field name 'last_msg_send_time'
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 this one is worth renaming as the variable is
isolated. It is not a
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.
Christoph
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
On Thu, Nov 29, 2018 at 09:47:09AM +0100, Christoph Berg 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.
At the same time it would make sense to rename
Re: Michael Paquier 2018-11-29 <20181129085902.gd9...@paquier.xyz>
> On Thu, Nov 29, 2018 at 09:47:09AM +0100, Christoph Berg 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
On Thu, Nov 29, 2018 at 04:35:06PM +0900, Amit Langote wrote:
> On 2018/11/29 16:27, Michael Paquier wrote:
>> Any thoughts or objections?
>
> It's an oversight. Thanks for fixing it.
Okay, done as long as I don't forget..
--
Michael
signature.asc
Description: PGP signature
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
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
>
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
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:
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
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
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
> 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
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
> >>
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
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
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
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
>>
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 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.
> >
>
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,
* 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
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
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
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
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
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
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
>
>
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
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
> "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
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
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
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
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
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
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
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,
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
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
> Is the point 3 change related to pgindent? I think even if you want
> these, then don't prepare other patches on top of this, keep it
> entirely separate.
Both removed.
>> Also, we don't quite have a consensus on the threshold value, but I
>> have set it to 4 pages for v8. If this is still
> On Sun, Aug 12, 2018 at 8:48 AM Noah Misch wrote:
>
> On Wed, Sep 11, 2013 at 10:28:00PM -0400, Noah Misch wrote:
> > On Wed, Sep 11, 2013 at 11:32:01AM -0400, Stephen Frost wrote:
> > > * Noah Misch (n...@leadboat.com) wrote:
> > > > Concretely, that means
> > > > not removing postmaster.pid
> On Fri, Aug 24, 2018 at 7:06 AM Tatsuro Yamada
> wrote:
>
> On 2017/11/22 6:07, Peter Geoghegan wrote:
> > On Mon, Oct 2, 2017 at 6:04 AM, Robert Haas wrote:
> >> Progress reporting on sorts seems like a tricky problem to me, as I
> >> said before. In most cases, a sort is going to involve
Re: Tomas Vondra 2018-11-28
<1b4e4c5e-7007-cd61-aae5-4a1c248e3...@2ndquadrant.com>
> Wouldn't it be sufficient / better to just store the search_path used
> when executing the query? That should be enough to resolve the object
> names correctly, and the overhead would be much lower (both in terms
On 2018-Nov-28, Tomas Vondra wrote:
> > v10-0004-Shared-memory-based-stats-collector.patch
> > updated not to touch guc.
> > v10-0005-Remove-the-GUC-stats_temp_directory.patch
> > collected all guc-related changes.
> > updated not to break other programs.
> >
Alvaro Herrera-9 wrote
> 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
> would be obtained via ruleutils or some
Hi Peter,
Thank you for your reply!
> On 27/11/2018 08:42, Iwata, Aya wrote:
> > I created a new version patch. Please find attached my patch.
>
> This does not excite me. It seems mostly redundant with using tcpdump.
I will develop "log level". I'm planning not to output redundant message at
> On Thu, Aug 23, 2018 at 4:16 PM Surafel Temesgen
> wrote:
>
> The attached patch add error handling for
> Extra data
>
> missing data
>
> invalid oid
>
> null oid and
>
> row count mismatch
Hi,
Unfortunately, the patch conflict-handling-onCopy-from-v2.patch has some
conflicts now, could you
On Thu, 29 Nov 2018 at 20:40, Kato, Sho wrote:
> Sorry for my lack of explanation. I didn't get a generic plan with
> plan_cache_mode = auto.
> What I am worried about is that if users don't know the flow of PREPARE
> EXECUTE, query execution seems to be suddenly slow and they will be in
>
I was also looking at this patch, here are some things I noticed:
In remove_useless_results_recurse where it processes JOIN_SEMI there is
this comment:
* However, we can't simplify if there are PHVs to
evaluate at
* the RTE_RESULT ... but that's impossible
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
> On Fri, Aug 31, 2018 at 1:28 PM Peter Eisentraut
> wrote:
>
> On 20/08/2018 05:13, Michael Paquier wrote:
> > Patch v6 of this thread is failing to apply. Could you rebase?
>
> attached
>
> Changes in v7 since v6:
>
> - Added support for ssl_passphrase_command.
>
> - Test suite needed some
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
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
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
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,
Hi,
Unfortunately, current version of this patch has some conflicts, could you
rebase it?
On Mon, Nov 26, 2018 at 2:13 PM Amit Kapila wrote:
>
> On Tue, Nov 20, 2018 at 7:37 PM Dilip Kumar wrote:
> > Along with that I have merged latest changes in zheap branch committed
> > by Rafia Sabih for cleaning up the undo buffer information in abort
> > path.
> >
>
> Thanks, few more
=# 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
> 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.
>
>
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
> On Sun, Sep 2, 2018 at 12:50 AM Noah Misch wrote:
>
> On Fri, Jan 26, 2018 at 04:54:08PM +0300, a.parfe...@postgrespro.ru wrote:
> > As it mentioned in pg_locale.c, the variable LC_MESSAGES is ignored in
> > Windows(pg_locale.c:162).
>
> That comment says "On Windows, setlocale(LC_MESSAGES)
> On Fri, Aug 24, 2018 at 5:53 PM Alexander Korotkov
> wrote:
>
> Given I've no feedback on this idea yet, I'll try to implement a PoC
> patch for that. It doesn't look to be difficult. And we'll see how
> does it work.
Unfortunately, current version of the patch doesn't pass the tests and
1 - 100 of 124 matches
Mail list logo
