On Wed, Jun 24, 2020 at 1:41 PM Bharath Rupireddy
wrote:
>
> Along with the review comments addressed
> patch(0006-Parallel-Copy-For-Binary-Format-Files.patch) also attaching
> all other latest series of patches(0001 to 0005) from [1], the order
> of applying patches is from 0001 to 0006.
>
> [1]
On Mon, Jul 06, 2020 at 10:56:53AM -0400, Alvaro Herrera wrote:
> I think "routine" was more correct. We introduced that terminology to
> encompass both functions and procedures, back when real procedures were
> added. See the definitions in the glossary for example.
Okay, fine by me, while we
On Tue, Jul 07, 2020 at 10:02:29AM +0800, movead...@highgo.ca wrote:
> Thanks, very helpful information and I have followed that.
Cool, thanks. I have gone through your patch in details, and updated
it as the attached. Here are some comments.
'8000' as OID for the new function was not really
On Mon, Jul 06, 2020 at 09:57:08PM -0700, Jeff Davis wrote:
> > I think that we should offer something like hash_mem that can work as
> > a multiple of work_mem, for the reason that Justin mentioned
> > recently.
> > This can be justified as something that more or less maintains some
> > kind of
On Sun, 2020-07-05 at 16:47 -0700, Peter Geoghegan wrote:
> Where does that leave the hash_mem idea (or some other similar
> proposal)?
hash_mem is acceptable to me if the consensus is moving toward that,
but I'm not excited about it.
It would be one thing if hash_mem was a nice clean solution.
On Mon, 2020-07-06 at 15:59 +0530, Amit Kapila wrote:
> I agree that it's good to wait for actual problems. But the
> > challenge
> > is that we can't backport an added GUC.
> >
>
> Is it because we won't be able to edit existing postgresql.conf file
> or for some other reasons?
Perhaps "can't"
>ISTM that a reasonable compromise is that if you use -x (or -c, -m, -O)
>and the input value is outside the range supported by existing files,
>then it's a fatal error; unless you use --force, which turns it into
>just a warning.
I do not think '--force' is a good choice, so I add a '--test,
On Tue, Jul 7, 2020 at 7:07 AM Masahiko Sawada
wrote:
>
> On Mon, 6 Jul 2020 at 20:45, Amit Kapila wrote:
> >
> > > Second, as long as the unique identifier is the slot name there is no
> > > convenient way to distinguish between the same name old and new
> > > replication slots, so the backend
Thanks for the patch!
> Query checks for following restrictions are added:
Are all known supported cases listed below?
> - inheritance parent table
> ...
> - targetlist containing IVM column
> - simple subquery is only supported
>
How to understand 3 items above?
-
Best Regards
Andy Fan
On 2020-Jul-07, Kyotaro Horiguchi wrote:
> At Mon, 6 Jul 2020 20:54:36 -0400, Alvaro Herrera
> wrote in
> > I propose the attached. This is pretty much what was proposed by
> > Kyotaro, but I made a couple of changes. Most notably, I moved the
> > calculation to the view code itself rather
On 2020/07/07 11:50, Masahiro Ikeda wrote:
Hi,
There is the comment which related function name is not same.
I attached the patch to fix it. Please review.
Thanks for the report and patch! LGTM.
I will commit this later.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Hi,
There is the comment which related function name is not same.
I attached the patch to fix it. Please review.
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATIONdiff --git a/src/backend/utils/cache/relfilenodemap.c b/src/backend/utils/cache/relfilenodemap.c
index 68b01ca68f..3acda32d17 100644
>That was fast, thanks. I have not tested the patch, but there are
>two things I missed a couple of hours back. Why do you need
>pg_last_committed_xact_with_origin() to begin with? Wouldn't it be
>more simple to just add a new column to pg_last_committed_xact() for
>the replication origin?
Thanks!
At Mon, 6 Jul 2020 20:54:36 -0400, Alvaro Herrera
wrote in
> On 2020-Jul-06, Alvaro Herrera wrote:
>
> > Hmm, I like safe_wal_size.
I agree to the name, too.
> > I've been looking at this intermittently since late last week and I
> > intend to get it done in the next couple of days.
On Mon, 6 Jul 2020 at 20:45, Amit Kapila wrote:
>
> On Thu, Jul 2, 2020 at 9:01 AM Masahiko Sawada
> wrote:
> >
> > I've attached PoC patch that implements a simple approach. I'd like to
> > discuss how we collect the replication slot statistics in the stats
> > collector before I bring the
On Fri, Jul 3, 2020 at 2:40 PM vignesh C wrote:
>
> The Attached patch has the fix for the same.
>
I have added a commitfest entry for this bug:
https://commitfest.postgresql.org/29/2636/
Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com
On 2020-Jul-06, Alvaro Herrera wrote:
> Hmm, I like safe_wal_size.
>
> I've been looking at this intermittently since late last week and I
> intend to get it done in the next couple of days.
I propose the attached. This is pretty much what was proposed by
Kyotaro, but I made a couple of
Alvaro Herrera writes:
> On 2020-Jul-06, Tom Lane wrote:
>> More generally, I'd be mighty hesitant to change this behavior after
>> it's stood for so many years. I suspect more people would complain
>> that we broke their application than would be happy about it.
> I think the fact that
On Mon, 6 Jul 2020 at 09:35, Dave Cramer wrote:
>
>
> On Mon, 6 Jul 2020 at 09:03, Daniel Gustafsson wrote:
>
>> > On 6 Jul 2020, at 14:58, Dave Cramer wrote:
>>
>> > as far as rebase -i do what is advised here for squashing them. Just
>> one patch now ?
>>
>> One patch per logical change, if
On 2020-Jul-06, Tom Lane wrote:
> More generally, I'd be mighty hesitant to change this behavior after
> it's stood for so many years. I suspect more people would complain
> that we broke their application than would be happy about it.
>
> Having said that, we are already relying on towlower()
Hello,
ccing pgsql-hack...@postgresql.org
Upon investigation, it seems that the problem is caused by the
following:
The slot passed to the call to ExecProcessReturning() inside
ExecInsert() is often a virtual tuple table slot. If there are system
columns other than ctid and tableOid referenced
Alvaro Herrera writes:
> On 2020-Jul-05, Anna Akenteva wrote:
>> -- Swapping primary key's index for an equivalent index,
>> -- but with INCLUDE-d attributes.
>> CREATE UNIQUE INDEX new_idx ON target_tbl (id) INCLUDE (info);
>> ALTER TABLE target_tbl ALTER CONSTRAINT target_tbl_pkey USING INDEX
On 2020-Jul-05, Anna Akenteva wrote:
> -- Swapping primary key's index for an equivalent index,
> -- but with INCLUDE-d attributes.
> CREATE UNIQUE INDEX new_idx ON target_tbl (id) INCLUDE (info);
> ALTER TABLE target_tbl ALTER CONSTRAINT target_tbl_pkey USING INDEX
> new_idx;
> ALTER TABLE
Thank you Flavio, this is helpful.
Have you faced any other challenges or any other problems after installing
Postgres?
Warm regards,
Ajay
On Mon, Jul 6, 2020 at 4:45 PM Flavio Henrique Araque Gurgel <
fha...@gmail.com> wrote:
>
> Em seg., 6 de jul. de 2020 às 21:55, Ajay Patel
> escreveu:
>
Em seg., 6 de jul. de 2020 às 21:55, Ajay Patel
escreveu:
> Hi Postgres team,
>
> I would like to know if PostgreSQL can be installed and used without any
> issues on Amazon Linux EC2 machines.
>
Yes you can, but not with the repositories at yum.postgresql.org. There's a
dependency of a package
Thom Brown writes:
> At the moment, only single-byte characters in identifiers are
> case-folded, and multi-byte characters are not.
> ...
> So my question is, do we yet have the infrastructure to make
> case-folding consistent across all character widths?
We still lack any built-in knowledge
Hi Postgres team,
I would like to know if PostgreSQL can be installed and used without any
issues on Amazon Linux EC2 machines.
https://www.postgresql.org/docs/11/supported-platforms.html
I was going through the documentation and couldn't find very specific
details related to support.
Any
Hi,
At the moment, only single-byte characters in identifiers are
case-folded, and multi-byte characters are not.
For example, abĉDĚF is case-folded to "abĉdĚf". This can be referred
to as "abĉdĚf" or "ABĉDĚF", but not "abĉděf" or "ABĈDĚF".
downcase_identifier() has the following comment:
Robert Haas writes:
> On Mon, Jul 6, 2020 at 6:46 AM Anastasia Lubennikova
> wrote:
>> I am going to implement this via SPI, which allow to simplify checks and
>> calculations. Do you see any pitfalls in this approach?
> I don't really see why we need SPI here.
I would vote against any core
On Mon, Jul 6, 2020 at 6:46 AM Anastasia Lubennikova
wrote:
> CREATE TABLE ... PARTITION BY partition_method (list_of_columns)
> partition_auto_create_clause
>
> where partition_auto_create_clause is
>
> CONFIGURATION [IMMEDIATE| DEFERRED] USING partition_bound_spec
>
> and partition_bound_spec
In the attached v3, I've tried to clarify comments and doc about tokenization
rules relating to comments, strings and continuations.
Attached v4 improves comments & doc as suggested by Justin.
--
Fabien.diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index
On Wed, Jul 1, 2020 at 5:15 AM Bharath Rupireddy
wrote:
> If I understand it correctly, your suggestion is to add
> keep_connection option and use that while defining the server object.
> IMO having keep_connection option at the server object level may not
> serve the purpose being discussed
Hi
čt 11. 6. 2020 v 4:13 odesílatel 曾文旌 napsal:
>
> 2020年6月9日 下午8:15，Prabhat Sahu 写道：
>
>
>
> On Wed, Apr 29, 2020 at 8:52 AM 曾文旌 wrote:
>
>> 2020年4月27日 下午9:48，Prabhat Sahu 写道：
>>
>> Thanks Wenjing, for the fix patch for previous issues.
>> I have verified the issues, now those fix look good
On 2020-Jul-04, Amit Kapila wrote:
> Fair enough. It would be good if we can come up with something better
> than 'distance' for this column. Some ideas safe_wal_limit,
> safe_wal_size?
Hmm, I like safe_wal_size.
I've been looking at this intermittently since late last week and I
intend to
po 6. 7. 2020 v 17:27 odesílatel Alvaro Herrera
napsal:
> On 2020-Jul-06, Pavel Stehule wrote:
>
> > I checking state of https://commitfest.postgresql.org/28/2176/
> >
> > It should be committed, but I don't see a commit?
>
> I reverted it to needs-review. It was marked as committed by me, but
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Per postgres_fdw's get_remote_estimate(), the only data we use right now
> >> is the startup_cost, total_cost, rows and width estimates from the
> >> top-level Plan node.
On 2020-Jul-06, Pavel Stehule wrote:
> I checking state of https://commitfest.postgresql.org/28/2176/
>
> It should be committed, but I don't see a commit?
I reverted it to needs-review. It was marked as committed by me, but
the one I did commit by the same author in the same area is FETCH
Hi
I checking state of https://commitfest.postgresql.org/28/2176/
It should be committed, but I don't see a commit?
Regards
Pavel
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Per postgres_fdw's get_remote_estimate(), the only data we use right now
>> is the startup_cost, total_cost, rows and width estimates from the
>> top-level Plan node. That's available immediately from the Plan tree,
>> meaning
On Mon, Jul 06, 2020 at 01:45:52PM +0300, Anastasia Lubennikova wrote:
> The previous discussion of automatic partition creation [1] has addressed
> static and dynamic creation of partitions and ended up with several syntax
> proposals.
...
> where partition_auto_create_clause is
>
>
On 2020-Jul-06, Michael Paquier wrote:
> While refreshing my mind with this code, I got surprised with the
> choice of "routine" in getProcedureTypeDescription() when we need a
> default object type name for an object not found, so I have switched
> that to "procedure" to be more consistent.
I
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> 2. Wedging this into EXPLAIN would be quite ugly, because (at least
> >> as I envision it) the output would have just about nothing to do with
> >> any existing EXPLAIN
On Thu, Jul 2, 2020 at 4:29 PM Bharath Rupireddy
wrote:
> >
> > This is actually strange. AFAIR the code, without looking at the
> > current code, when a query picks a foreign connection it checks its
> > state. It's possible that the connection has not been marked bad by
> > the time you fire
On Mon, 6 Jul 2020 at 09:03, Daniel Gustafsson wrote:
> > On 6 Jul 2020, at 14:58, Dave Cramer wrote:
>
> > as far as rebase -i do what is advised here for squashing them. Just one
> patch now ?
>
> One patch per logical change, if there are two disjoint changes in the
> patchset
> where one
On 2020/06/11 14:59, torikoshia wrote:
On 2020-06-10 18:00, Kyotaro Horiguchi wrote:
+ TupleDescInitEntry(tupdesc, (AttrNumber) 8, "last_plan",
This could be a problem if we showed the last plan in this view. I
think "last_plan_type" would be better.
+ if
> On 6 Jul 2020, at 14:58, Dave Cramer wrote:
> as far as rebase -i do what is advised here for squashing them. Just one
> patch now ?
One patch per logical change, if there are two disjoint changes in the patchset
where one builds on top of the other then multiple patches are of course fine.
On Sun, 5 Jul 2020 at 17:28, Daniel Gustafsson wrote:
> > On 5 Jul 2020, at 23:11, Alvaro Herrera
> wrote:
> >
> > On 2020-Jul-05, Daniel Gustafsson wrote:
> >
> >>> On 2 Jul 2020, at 18:41, Dave Cramer wrote:
> >>>
> >>> rebased
> >>
> >> Thanks! The new version of 0001 patch has a compiler
> 1 июля 2020 г., в 17:05, Daniel Gustafsson написал(а):
>
>> On 29 Feb 2020, at 18:24, Andrey M. Borodin wrote:
>
>> I've fixed this and added patch with GiST reloption to provide sort support
>> function.
>
> 0002 in this patchset fails to apply, please submit a rebased version. I've
>
On Mon, Jul 6, 2020 at 5:24 PM Daniel Gustafsson wrote:
> > On 12 Jun 2020, at 19:28, Robert Haas wrote:
>
> > I am sure that nobody is arguing that the patch has to be beneficial
> > in all cases in order to justify applying it. However, there are
> > several good arguments against proceding
As a general overview, the series of patches in the mail thread do match their
description. The addition of the stricter, explicit use of instrumentation does
improve the design as the distinction of the use cases requiring a pin or a
lock is made more clear. The added commentary is descriptive
On Sat, 4 Jul 2020 at 01:19, Tom Lane wrote:
>
> I did some performance testing on 0001+0002 here, and found that
> for me, there's basically no change on x86_64 but a win of 2 to 3
> percent on aarch64, using Pavel's pi_est_1() as a representative
> case for simple plpgsql statements. That
> >
> > If I understand it correctly, your suggestion is to add
> > keep_connection option and use that while defining the server object.
> > IMO having keep_connection option at the server object level may not
> > serve the purpose being discussed here.
> > For instance, let's say I create a
> On 12 Jun 2020, at 19:28, Robert Haas wrote:
> I am sure that nobody is arguing that the patch has to be beneficial
> in all cases in order to justify applying it. However, there are
> several good arguments against proceding with this patch:
This thread has stalled with no resolution to the
> This patch no longer applies, can you please submit a rebased version? I've
> marked the entry as Waiting on Author in the meantime.
>
Here's a rebased version of the patch.
Regards,
Greg
v16-0001-Enhance-libpq-target_session_attrs-and-add-target_se.patch
Description: Binary data
On Thu, Jun 18, 2020 at 8:04 PM Alexander Korotkov
wrote:
> On Thu, Jun 18, 2020 at 7:45 PM Tom Lane wrote:
> > Alexander Korotkov writes:
> > > Thank you for your answer. I'm trying to understand your point.
> > > Standard claims that .double() method should behave the same way as
> > > CAST
>>
>> If I understand it correctly, your suggestion is to add
>> keep_connection option and use that while defining the server object.
>> IMO having keep_connection option at the server object level may not
>> serve the purpose being discussed here.
>> For instance, let's say I create a foreign
On Thu, Jul 2, 2020 at 9:01 AM Masahiko Sawada
wrote:
>
> I've attached PoC patch that implements a simple approach. I'd like to
> discuss how we collect the replication slot statistics in the stats
> collector before I bring the patch to completion.
>
> In this PoC patch, we have the array of
The previous discussion of automatic partition creation [1] has
addressed static and dynamic creation of partitions and ended up with
several syntax proposals.
In this thread, I want to continue this work.
Attached is PoC for static partition creation. The patch core is quite
straightforward.
> On Wed, Jul 1, 2020 at 6:26 PM Daniel Gustafsson wrote:
>
> > On 21 Apr 2020, at 18:21, yuzuko wrote:
>
> > I'll update the patch soon.
>
> Do you have an updated version to submit? The previous patch no longer
> applies
> to HEAD, so I'm marking this entry Waiting on Author in the meantime.
On Sun, Jul 5, 2020 at 2:24 AM Jeff Davis wrote:
>
> On Sat, 2020-07-04 at 14:49 +0530, Amit Kapila wrote:
> > > We don't even have a user report yet of a
> > > regression compared to PG 12, or one that can't be fixed by
> > > increasing
> > > work_mem.
> > >
> >
> > Yeah, this is exactly the
On Mon, Jul 6, 2020 at 11:44 AM Dilip Kumar wrote:
>
> On Mon, Jul 6, 2020 at 11:31 AM Amit Kapila wrote:
> >
>
> > > > 10. I have got the below failure once. I have not investigated this
> > > > in detail as the patch is still under progress. See, if you have any
> > > > idea?
> > > > #
On 12/27/19 12:34 PM, Kohei KaiGai wrote:
The attached v2 fixed the problem, and regression test finished correctly.
Using your patch I saw incorrect value of predicted rows at the top node
of the plan: "Append (cost=270.02..35165.37 rows=40004 width=16)"
Full explain of the query plan see in
Hello
I would like to ask about the conditions under which partition pruning is
performed.
In PostgreSQL 12, when I executed following SQL, partition pruning is not
performed.
postgres=# explain select * from a where (c1, c2) < (99, 99);
QUERY PLAN
> attached.
>>
>
> fresh rebase
>
fix test build
Regards
Pavel
> Regards
>
> Pavel
>
>
>> Pavel
>>
>>
>>> --
>>> With Regards,
>>> Amit Kapila.
>>> EnterpriseDB: http://www.enterprisedb.com
>>>
>>
schema-variables-20200706.patch.gz
Description: application/gzip
On Mon, Jul 06, 2020 at 11:12:30AM +0800, movead...@highgo.ca wrote:
> Thanks for the points and follow them, new patch attached.
That was fast, thanks. I have not tested the patch, but there are
two things I missed a couple of hours back. Why do you need
pg_last_committed_xact_with_origin() to
‐‐‐ Original Message ‐‐‐
On Monday, July 6, 2020 3:12 AM, Michael Paquier wrote:
> On Sun, Jul 05, 2020 at 07:13:10AM +0530, vignesh C wrote:
>
> > I'm not sure if we should include showViews, I had seen that the
> > access method was not getting selected for view.
>
> +1. These have
On Fri, Jul 03, 2020 at 11:04:17AM -0400, Alvaro Herrera wrote:
> 0001 and 0002 look good to me.
Thanks for the review.
> I think 0003 could be a little more careful about indentation; some long
> lines are going to result after pgindent that might be better to handle
> in a different way before
On Sat, 4 Jul 2020 at 22:13, Ajin Cherian wrote:
>
>
>
> On Thu, Jul 2, 2020 at 1:31 PM Masahiko Sawada
> wrote:
>>
>>
>>
>> Thanks! Yes, I'm working on this patch while considering to send the
>> stats to stats collector.
>>
>> I've attached PoC patch that implements a simple approach. I'd
On 2020/07/06 12:12, torikoshia wrote:
On Fri, Jul 3, 2020 at 7:33 PM Fujii Masao wrote:
Thanks for your review!
I like more specific name like pg_backend_memory_contexts.
Agreed.
When I was trying to add this function as statistics function,
I thought that naming
On Mon, Jul 6, 2020 at 11:31 AM Amit Kapila wrote:
>
> On Sun, Jul 5, 2020 at 4:47 PM Dilip Kumar wrote:
> >
> > On Sat, Jul 4, 2020 at 11:35 AM Amit Kapila wrote:
> > >
> >
> > > 9.
> > > +ReorderBufferHandleConcurrentAbort(ReorderBuffer *rb, ReorderBufferTXN
> > > *txn,
> > > {
> > > ..
> >
On Sun, Jul 5, 2020 at 4:47 PM Dilip Kumar wrote:
>
> On Sat, Jul 4, 2020 at 11:35 AM Amit Kapila wrote:
> >
>
> > 9.
> > +ReorderBufferHandleConcurrentAbort(ReorderBuffer *rb, ReorderBufferTXN
> > *txn,
> > {
> > ..
> > + ReorderBufferToastReset(rb, txn);
> > + if (specinsert != NULL)
> > +
71 matches
Mail list logo
