By default, the fallback_application_name for a physical walreceiver is
"walreceiver". This means that multiple standbys cannot be
distinguished easily on a primary, for example in pg_stat_activity or
synchronous_standby_names.
I propose, if cluster_name is set, use that for
fallback_application_
čt 7. 2. 2019 v 9:51 odesílatel Amit Langote
napsal:
> Hi Pavel,
>
> Thanks for sending the updated patch.
>
> On 2018/12/19 15:38, Pavel Stehule wrote:
> > út 18. 12. 2018 v 8:49 odesílatel Amit Langote <
> >> On 2018/12/17 17:48, Pavel Stehule wrote:
> >>> I can imagine new additional flag - li
> On 8 Feb 2019, at 01:10, Michael Paquier wrote:
>
> On Thu, Feb 07, 2019 at 10:03:30AM +0100, Daniel Gustafsson wrote:
>> Doh, managed to completely overlook that. The attached updated patch also
>> fixes the comment, thanks!
>
> That looks fine to me. Could you just add it to the next CF as
From: Bruce Momjian [mailto:br...@momjian.us]
> I am thinking we should see which items we really want for PG 12 _now_
> and allocate resources/help to get them done, rather than being
> surprised they didn't make it. I am glad we are in good shape with
> CTEs, since that has been a long-requested
On Fri, Feb 8, 2019 at 1:34 AM, I wrote:
> On Wed, Feb 6, 2019 at 2:04 AM, Tsunakawa, Takayuki wrote:
> > Can you compare the performance of auto and force_custom_plan again
> > with the attached patch? It uses PGPROC's LOCALLOCK list instead of
> > the hash table.
>
> Thanks for the patch, but i
On Fri, Feb 8, 2019 at 12:48 PM Andres Freund wrote:
> Hi,
>
> On 2019-02-08 12:18:32 +0530, Ashutosh Sharma wrote:
> > When "ON SELECT" rule is created on a table without columns, it
> > successfully converts a table into the view. However, when the same is
> > done using CREATE VIEW command, it
On Fri, Feb 8, 2019 at 12:48 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-02-08 12:18:32 +0530, Ashutosh Sharma wrote:
> > When "ON SELECT" rule is created on a table without columns, it
> > successfully converts a table into the view. However, when the same is
> > done using CREATE VIEW command, i
On 08.02.2019 10:01, Iwata, Aya wrote:
Hi,
I am sorry for my late reply.
I fixed all issues you have reported except using list of supported compression
algorithms.
Sure. I confirmed that.
It will require extra round of communication between client and server to
make a decision about use
From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> target_session_attrs checks for the default_transaction_readonly or not?
PG 11 uses transaction_read_only, not default_transaction_readonly. That's
fine, because its purpose is to get a read-only session as the name suggests,
not to conne
On Fri, 8 Feb 2019 at 22:12, Amit Langote wrote:
> 0001 is now a patch to remove duplicate code from set_append_rel_size. It
> combines multiple blocks that have the same body doing
> set_dummy_rel_pathlist().
>
> 0002 is the "overhaul inherited update/delete planning"
I had started looking at v
> On 8 Feb 2019, at 10:15, Konstantin Knizhnik
> wrote:
> Frankly speaking, I do not think that such flexibility in choosing
> compression algorithms is really needed.
> I do not expect that there will be many situations where old client has to
> communicate with new server or visa versa.
> In
On February 8, 2019 10:05:03 AM GMT+01:00, Rushabh Lathia
wrote:
>On Fri, Feb 8, 2019 at 12:48 PM Andres Freund
>wrote:
>
>> Hi,
>>
>> On 2019-02-08 12:18:32 +0530, Ashutosh Sharma wrote:
>> > When "ON SELECT" rule is created on a table without columns, it
>> > successfully converts a table i
>From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
>I made a rerun of benchmark using "-S -T 30" on the server build with no
>assertion and
>-O2. The numbers are the best of three successive attempts. The patched
>version is
>running with cache_target_memory = 0, cache_prune_min_a
On Fri, Feb 08, 2019 at 09:36:59AM +0100, Daniel Gustafsson wrote:
> Done, thanks! I took the liberty to mark you as reviewer since you’ve already
> spent time looking at the patch.
Thanks. Please note that I can take care of the patch in a couple of
days if need be.
--
Michael
signature.asc
D
On Fri, Feb 8, 2019 at 3:05 PM Andres Freund wrote:
>
>
>
> On February 8, 2019 10:05:03 AM GMT+01:00, Rushabh Lathia
> wrote:
> >On Fri, Feb 8, 2019 at 12:48 PM Andres Freund
> >wrote:
> >
> >> Hi,
> >>
> >> On 2019-02-08 12:18:32 +0530, Ashutosh Sharma wrote:
> >> > When "ON SELECT" rule is c
On 13/01/2019 01:55, Paul Martinez wrote:
> The two constraints have nearly identical names. With my patch the default
> names
> will include both column names, so we have we will instead have this output:
>
> Foreign-key constraints:
> "comments_tenant_id_commenter_id_fkey" FOREIGN KEY (tenan
On Wed, 6 Feb 2019 at 18:30, Amit Khandekar wrote:
>
> On Mon, 21 Jan 2019 at 08:31, Andres Freund wrote:
> >
> > Hi,
> >
> > (resending with compressed attachements, perhaps that'll go through)
> >
> > On 2018-12-10 18:13:40 -0800, Andres Freund wrote:
> > > On 2018-11-26 17:55:57 -0800, Andres
On 7/2/19 23:03, Andres Freund wrote:
Hi,
On 2019-02-07 09:03:06 +, Dave Page wrote:
On Thu, Feb 7, 2019 at 8:26 AM Peter Eisentraut
wrote:
I suggest we declare it deprecated in PG12 and remove it altogether in PG13.
Much as I'd like to get rid of it, we don't have an alternative for
Win
Meskes-san
Thank you for your comment.
I remove it and attach a new patch. Please review it.
I feel sorry for asking you to reveiw without contribution.
Regards
Ryo Matsumura
> -Original Message-
> From: Michael Meskes [mailto:mes...@postgresql.org]
> Sent: Friday, February 1, 2019 6:29
Bruce Momjian wrote:
> On Wed, May 30, 2018 at 09:28:54AM -0400, Alvaro Herrera wrote:
> > On 2018-May-30, Antonin Houska wrote:
> >
> > > In the header comment, SnapBuildInitialSnapshot() claims to set
> > > snapshot->satisfies to the HeapTupleSatisfiesMVCC test function, and
> > > indeed it
>
On 08/02/2019 11:01, Michael Paquier wrote:
> On Fri, Feb 08, 2019 at 09:36:59AM +0100, Daniel Gustafsson wrote:
>> Done, thanks! I took the liberty to mark you as reviewer since you’ve
>> already
>> spent time looking at the patch.
>
> Thanks. Please note that I can take care of the patch in a
On Fri, Feb 8, 2019 at 9:40 AM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Bruce Momjian [mailto:br...@momjian.us]
> > I am thinking we should see which items we really want for PG 12 _now_
> > and allocate resources/help to get them done, rather than being
> > surprised t
On Thu, Feb 7, 2019 at 10:34 PM Gavin Flower
wrote:
> On 08/02/2019 00:53, Peter Eisentraut wrote:
> > On 06/02/2019 21:09, Magnus Hagander wrote:
> >> This has now been pushed and is available. I've set it up with stable,
> >> 12 and 13 as possible versions for now, but I have not added any tags
>From: Tomas Vondra [mailto:tomas.von...@2ndquadrant.com]
>But it's a bit funnier, because there's also DropRelationFiles() which does
>smgrclose on
>a batch of relations too, and it says this
>
>/*
> * Call smgrclose() in reverse order as when smgropen() is called.
> * This trick enab
> On 8 Feb 2019, at 12:01, Peter Eisentraut
> wrote:
>
> On 08/02/2019 11:01, Michael Paquier wrote:
>> On Fri, Feb 08, 2019 at 09:36:59AM +0100, Daniel Gustafsson wrote:
>>> Done, thanks! I took the liberty to mark you as reviewer since you’ve
>>> already
>>> spent time looking at the patch.
On Fri, 8 Feb 2019 at 22:27, David Rowley wrote:
> I had started looking at v20's 0001. I've not done a complete pass
> over it yet, but I'll likely just start again since v21 is out now:
I've now done a complete pass over v21.
Here's what I wrote down.
8. Is this code in the wrong patch? I do
Hi,
Any way I can help to get this commited? Should we add this to the commitfest?
Regards,
--
Raúl Marín Rodríguez
carto.com
Hi Antonin,
(2019/02/08 2:04), Antonin Houska wrote:
Etsuro Fujita wrote:
Here is an updated version of the patch set. Changes are:
I've spent some time reviewing the patches.
Thanks for the review!
First, I wonder if the information on LIMIT needs to be passed to the
FDW. Cannot the FD
On 08/02/2019 12:27, Magnus Hagander wrote:
> I'd be more than happy for somebody with morge knowledge of such matters
> than me to think up a better color scheme. The only reason it has those
> colors is that they're the default ones in the Bootstrap CSS framework.
Can we have that column just no
> On 8 Feb 2019, at 13:33, Raúl Marín Rodríguez wrote:
> Any way I can help to get this commited? Should we add this to the commitfest?
Please do, it’s a good way to ensure that the patch is tracked and not
forgotten about.
cheers ./daniel
On 2/8/19 12:32 PM, Ideriha, Takeshi wrote:
>> From: Tomas Vondra [mailto:tomas.von...@2ndquadrant.com]
>> But it's a bit funnier, because there's also DropRelationFiles() which does
>> smgrclose on
>> a batch of relations too, and it says this
>>
>>/*
>> * Call smgrclose() in reverse o
From: Tomas Vondra
> I don't think we need to remove the expired entries right away, if
there
> are only very few of them. The cleanup requires walking the hash
table,
> which means significant fixed cost. So if there are only few expired
> entries (say, less than 25% of the cache), we can just lea
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Tested `pgbench-tap-glob-fix-1.patch` with a "+" in the path and the tap
From: Alvaro Herrera
> I think seqscanning the hash table is going to be too slow;
Ideriha-san
> idea of having a dlist with the entries in LRU order (where each
entry
> is moved to head of list when it is touched) seemed good: it allows
you
> to evict older ones when the time comes, without having
Andres Freund writes:
> You misunderstood my point: I'm asking why we shouldn't remove that check
> from views, rather than adding it to create rule.
+1. This seems pretty obviously to be something we just missed when
we changed things to allow zero-column tables.
regar
On 21.01.2019 23:50, a.kondra...@postgrespro.ru wrote:
Thank you for the review! I have updated the patch according to your
comments and remarks. Please, find new version attached.
During the self-reviewing of the code and tests, I discovered some
problems with build on Windows. New version of
Hi list,
I've attached a patch that implements SortSupport for the
inet/cidr types. It has the effect of typically reducing
the time taken to sort these types by ~50-60% (as measured
by `SELECT COUNT(DISTINCT ...)` which will carry over to
common operations like index creation, `ORDER BY`, and
`DI
I wrote:
> I believe that we need to establish the following principles:
>
> * The terminology "internal_auto" is disastrously unhelpful.
> I propose calling these things "partition" dependencies instead.
>
> * Partition dependencies are not singletons. They should *always*
> come in pairs, one on
Konstantin Knizhnik writes:
> On 08.02.2019 10:01, Iwata, Aya wrote:
>
>>> I fixed all issues you have reported except using list of supported
>>> compression algorithms.
>>
>> Sure. I confirmed that.
>>
>>> It will require extra round of communication between client and
>>> server to make a deci
On Fri, Feb 8, 2019 at 7:55 PM Tom Lane wrote:
>
> Andres Freund writes:
> > You misunderstood my point: I'm asking why we shouldn't remove that check
> > from views, rather than adding it to create rule.
>
> +1. This seems pretty obviously to be something we just missed when
> we changed thing
On 08.02.2019 12:33, Daniel Gustafsson wrote:
On 8 Feb 2019, at 10:15, Konstantin Knizhnik wrote:
Frankly speaking, I do not think that such flexibility in choosing compression
algorithms is really needed.
I do not expect that there will be many situations where old client has to
communicat
The purpose of this patch is to stop the execution of continuous
requests in case of a disconnection from the client. In most cases, the
client must wait for a response from the server before sending new data
- which means there should not remain unread data on the socket and we
will be able to
On 08.02.2019 19:26, Robbie Harwood wrote:
Konstantin Knizhnik writes:
On 08.02.2019 10:01, Iwata, Aya wrote:
I fixed all issues you have reported except using list of supported
compression algorithms.
Sure. I confirmed that.
It will require extra round of communication between client
On Sat, Feb 2, 2019 at 9:18 AM Noah Misch wrote:
> On Mon, Jan 28, 2019 at 07:29:39PM +0100, Magnus Hagander wrote:
> > On Mon, Jan 28, 2019 at 7:26 PM Tom Lane wrote:
> > > Stephen Frost writes:
> > > >> On Sun, Jan 27, 2019 at 2:28 AM Noah Misch
> wrote:
> > > >>> What are those blocked infr
Why don't we provide a small reserved OID range that can be used by
patch authors temporarily, with the expectation that they'll be
replaced by "real" OIDs at the point the patch gets committed? This
would be similar the situation with catversion bumps -- we don't
expect patches that will eventuall
Ashutosh Sharma writes:
> Attached is the patch that allows us to create view on a table without
> columns. I've also added some test-cases for it in create_view.sql.
> Please have a look and let me know your opinion.
Haven't read the patch, but a question seems in order here: should
we regard th
Peter Geoghegan writes:
> Why don't we provide a small reserved OID range that can be used by
> patch authors temporarily, with the expectation that they'll be
> replaced by "real" OIDs at the point the patch gets committed? This
> would be similar the situation with catversion bumps -- we don't
>
On Fri, Feb 8, 2019 at 10:14 AM Tom Lane wrote:
> A script such as you suggest might be a good way to reduce the temptation
> to get lazy at the last minute. Now that the catalog data is pretty
> machine-readable, I suspect it wouldn't be very hard --- though I'm
> not volunteering either. I'm e
Attached a V2 patch: identical to V1 except rebased and
with a new OID selected.
SortSupport-for-inet-cidr-types-v2.patch
Description: Binary data
Peter Geoghegan writes:
> On Fri, Feb 8, 2019 at 10:14 AM Tom Lane wrote:
>> A script such as you suggest might be a good way to reduce the temptation
>> to get lazy at the last minute. Now that the catalog data is pretty
>> machine-readable, I suspect it wouldn't be very hard --- though I'm
>>
On Fri, Feb 8, 2019 at 10:29 AM Tom Lane wrote:
> Um. That would not be just an add-on script but something that
> genbki.pl would have to accept. I'm not excited about that; it would
> complicate what's already complex, and if it works enough for test
> purposes then it wouldn't really stop a c
On Fri, Feb 8, 2019 at 11:32 PM Tom Lane wrote:
>
> Ashutosh Sharma writes:
> > Attached is the patch that allows us to create view on a table without
> > columns. I've also added some test-cases for it in create_view.sql.
> > Please have a look and let me know your opinion.
>
> Haven't read the
On 2019-02-08 12:15:58 +0300, Konstantin Knizhnik wrote:
> Frankly speaking, I do not think that such flexibility in choosing
> compression algorithms is really needed.
> I do not expect that there will be many situations where old client has to
> communicate with new server or visa versa.
> In mos
On 2/8/19 2:27 PM, MauMau wrote:
> From: Tomas Vondra
>> I don't think we need to remove the expired entries right away, if
>> there are only very few of them. The cleanup requires walking the
>> hash table, which means significant fixed cost. So if there are
>> only few expired entries (say, le
On 2019-Feb-08, Tom Lane wrote:
> Also, I came across some coding in CloneFkReferencing() that looks fishy
> as hell: that function imagines that it can delete an existing trigger
> with nothing more than a summary CatalogTupleDelete(). I didn't do
> anything about that here, but if it's not brok
On Fri, Feb 8, 2019 at 8:15 AM Tom Lane wrote:
> > * Partition dependencies are not singletons. They should *always*
> > come in pairs, one on the parent partitioned object (partitioned
> > index, constraint, trigger, etc) and one on the child partitioned
> > table.
> > * Partition dependencies
On 2/8/19 2:27 PM, Tomas Vondra wrote:
>
>
>
> On 2/8/19 12:32 PM, Ideriha, Takeshi wrote:
>>> From: Tomas Vondra [mailto:tomas.von...@2ndquadrant.com]
>>> But it's a bit funnier, because there's also DropRelationFiles() which does
>>> smgrclose on
>>> a batch of relations too, and it says this
On 08.02.2019 21:57, Andres Freund wrote:
On 2019-02-08 12:15:58 +0300, Konstantin Knizhnik wrote:
Frankly speaking, I do not think that such flexibility in choosing
compression algorithms is really needed.
I do not expect that there will be many situations where old client has to
communicate
On 2/8/19 11:10 PM, Konstantin Knizhnik wrote:
>
>
> On 08.02.2019 21:57, Andres Freund wrote:
>> On 2019-02-08 12:15:58 +0300, Konstantin Knizhnik wrote:
>>> Frankly speaking, I do not think that such flexibility in choosing
>>> compression algorithms is really needed.
>>> I do not expect that t
Alvaro Herrera writes:
> On 2019-Feb-08, Tom Lane wrote:
>> Also, I came across some coding in CloneFkReferencing() that looks fishy
>> as hell: that function imagines that it can delete an existing trigger
>> with nothing more than a summary CatalogTupleDelete(). I didn't do
>> anything about th
... are committed at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5996cfc4665735a7e6e8d473bd66e8b11e320bbb
Please send comments/corrections by Sunday.
regards, tom lane
On Fri, Feb 8, 2019 at 5:19 PM Tom Lane wrote:
> Please send comments/corrections by Sunday.
Note that "Fix deadlock in GIN vacuum introduced by 218f51584d5"
(which is commit fd83c83d on the master branch) is not that far from
being a complete revert of a v10 feature (this appears as "Reduce page
Peter Geoghegan writes:
> Note that "Fix deadlock in GIN vacuum introduced by 218f51584d5"
> (which is commit fd83c83d on the master branch) is not that far from
> being a complete revert of a v10 feature (this appears as "Reduce page
> locking during vacuuming of GIN indexes" in the v10 release n
On Fri, Feb 8, 2019 at 6:00 PM Tom Lane wrote:
> Yeah, I saw that in the commit message, but didn't really think that
> the release note entry needed to explain it that way. Could be
> argued differently though.
I'm pretty confident that somebody is going to miss this
functionality, if this acco
On Sat, Feb 9, 2019 at 6:49 AM Tom Lane wrote:
>
> ... are committed at
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5996cfc4665735a7e6e8d473bd66e8b11e320bbb
>
Author: Alvaro Herrera
+Branch: master [0464fdf07] 2019-01-21 20:08:52 -0300
+Branch: REL_11_STABLE [123cc697a
Amit Kapila writes:
> On Sat, Feb 9, 2019 at 6:49 AM Tom Lane wrote:
> + Create or delete foreign key enforcement triggers correctly when
> + attaching or detaching a partition in a a partitioned table that
> + has a foreign-key constraint (Amit Langote, Álvaro Herrera)
> It seems
On Fri, Feb 8, 2019 at 6:55 AM Haribabu Kommi wrote:
>
> On Thu, Feb 7, 2019 at 9:31 PM Haribabu Kommi
> wrote:
>>
>>
>> This is because of larger xact_commit value than default configuration. With
>> the changed server configuration, that leads to generate more parallel
>> workers and every p
On Sat, 9 Feb 2019 at 04:48, Brandur Leach wrote:
> I've attached a patch that implements SortSupport for the
> inet/cidr types. It has the effect of typically reducing
> the time taken to sort these types by ~50-60% (as measured
> by `SELECT COUNT(DISTINCT ...)` which will carry over to
> common
On Sat, Feb 9, 2019 at 9:41 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Feb-08, Tom Lane wrote:
> >> Also, I came across some coding in CloneFkReferencing() that looks fishy
> >> as hell: that function imagines that it can delete an existing trigger
> >> with nothing more than a summa
Amit Langote writes:
> On Sat, Feb 9, 2019 at 9:41 AM Tom Lane wrote:
>> +1. The best solution would presumably be to go through the normal
>> object deletion mechanism; though possibly there's a reason that
>> won't work given you're already inside some other DDL.
> Maybe:
> - CatalogTupleDele
70 matches
Mail list logo
