> 18 сент. 2020 г., в 11:10, Michael Paquier написал(а):
>
> On Thu, Sep 17, 2020 at 10:20:16AM +0200, Oleksandr Shulgin wrote:
>> Ouch. I think pg_rewind shouldn't try to remove any random files in pg_wal
>> that it doesn't know about.
>> What if the administrator made a backup of some WAL s
On Wed, Sep 9, 2020 at 10:20 AM Amit Kapila wrote:
>
> On Thu, Jul 30, 2020 at 6:42 PM Amit Kapila wrote:
> >
> > On Thu, Jul 30, 2020 at 12:02 PM Amit Kapila
> > wrote:
> > >
> > > On Wed, Jul 29, 2020 at 7:18 PM Robert Haas wrote:
> > > >
> > > > I still don't agree with this as proposed.
>
On Fri, Sep 18, 2020 at 9:07 AM Amit Langote wrote:
>
> On Fri, Sep 18, 2020 at 12:30 PM Amit Kapila wrote:
> > I am not very excited to add information about structures used in the
> > file especially when we have explained 'LogicalRepPartMapEntry' a few
> > lines after. I think we can leave exp
On Thu, Sep 17, 2020 at 10:20:16AM +0200, Oleksandr Shulgin wrote:
> Ouch. I think pg_rewind shouldn't try to remove any random files in pg_wal
> that it doesn't know about.
> What if the administrator made a backup of some WAL segments there?
IMO, this would be a rather bad strategy anyway, so j
On Thu, Sep 17, 2020 at 08:03:55AM -0700, Mark Dilger wrote:
> Yes, I have prioritized a couple other patches over this one, with
> benchmarking this patch lower down my priority list. Thank you,
> Michael, for the reminder!
Based on the low level of activity and the fact that the patch was
marke
"Tharakan, Robins" writes:
>> During fully-cached SELECT-only test using pgbench, Postgres v13Beta1
>> shows ~45% performance drop [2] at high DB connection counts (when
>> compared with v12.3)
> It'd be great if we could also give credit to "Sean Massey" for this find.
I poked through my Postgr
On Fri, Sep 18, 2020 at 12:30 PM Amit Kapila wrote:
> On Thu, Sep 17, 2020 at 6:46 PM Amit Langote wrote:
> >
> > Thanks for taking a look.
> >
> > On Thu, Sep 17, 2020 at 9:20 PM Amit Kapila wrote:
> > > On Thu, Sep 17, 2020 at 3:22 PM Amit Langote
> > > wrote:
> > > >
> > >
> > >
> > > /*-
On Thu, Sep 17, 2020 at 6:46 PM Amit Langote wrote:
>
> Thanks for taking a look.
>
> On Thu, Sep 17, 2020 at 9:20 PM Amit Kapila wrote:
> > On Thu, Sep 17, 2020 at 3:22 PM Amit Langote
> > wrote:
> > >
> >
> > /*-
> > *
Thanks for your advice! This help me a lot.
> On Sep 17, 2020, at 9:18 PM, Jakub Wartak wrote:
>
> Li Japin wrote:
>
>> If we can improve the efficiency of replay, then we can shorten the database
>> recovery time (streaming replication or database crash recovery).
> (..)
>> For streaming re
At Fri, 18 Sep 2020 09:40:11 +0900, Masahiro Ikeda
wrote in
> Thanks. I confirmed that it causes HOT pruning or killing of
> dead index tuple if DecodeCommit() is called.
>
> As you said, DecodeCommit() may access the system table.
...
> The wals are generated only when logical replication is p
On 2020-09-15 17:10, Fujii Masao wrote:
On 2020/09/15 15:52, Masahiro Ikeda wrote:
On 2020-09-11 01:40, Fujii Masao wrote:
On 2020/09/09 13:57, Masahiro Ikeda wrote:
On 2020-09-07 16:19, Fujii Masao wrote:
On 2020/09/07 9:58, Masahiro Ikeda wrote:
Thanks for the review and advice!
On 2020-0
On Thu, Sep 17, 2020 at 10:47 PM Heikki Linnakangas wrote:
> Hmm, so for speedy response to postmaster death, you're relying on the
> loops to have other postmaster-death checks besides
> HandleStartupProcInterrupts(), in the form of WL_EXIT_ON_PM_DEATH. That
> seems a bit fragile, at the very lea
I wrote:
> Hmm, I came across that paper while doing background reading. Okay,
> now I get that "% (filter->nbits - 1)" is the second hash function in
> that scheme. But now I wonder if that second function should actually
> act on the passed "value" (the original hash), so that they are
> actuall
On Tue, Sep 8, 2020 at 01:36:16PM +0300, Alexey Kondratov wrote:
> Thank you for the link!
>
> After a quick look on the Sawada-san's patch set I think that there are two
> major differences:
>
> 1. There is a built-in foreign xacts resolver in the [1], which should be
> much more convenient fro
On Thu, Sep 17, 2020 at 12:34 PM Tomas Vondra
wrote:
>
> On Thu, Sep 17, 2020 at 10:33:06AM -0400, John Naylor wrote:
> >On Sun, Sep 13, 2020 at 12:40 PM Tomas Vondra
> > wrote:
> >> <20200913 patch set>
> But those are opclass parameters, so the parameters are not specified in
> WITH clause, but
Em qui., 17 de set. de 2020 às 17:09, Tomas Vondra <
tomas.von...@2ndquadrant.com> escreveu:
> On Thu, Sep 17, 2020 at 02:12:12PM -0300, Ranier Vilela wrote:
> >Hi,
> >
> >In case gd->any_hashable is FALSE, grouping_is_hashable is never called.
> >In this case, the planner could use HASH for group
Robert Haas writes:
> I'm not sure who is going to commit this work, and that person may
> have a different preference than me. However, if it's me, I'd like to
> see the removal of the existing postfix operators broken off into its
> own patch, separate from the removal of the underlying facility
On Thu, Sep 17, 2020 at 02:12:12PM -0300, Ranier Vilela wrote:
Hi,
In case gd->any_hashable is FALSE, grouping_is_hashable is never called.
In this case, the planner could use HASH for groupings, but will never know.
The condition is pretty simple - if the query has grouping sets, look at
gro
On Thu, Sep 17, 2020 at 6:04 PM Tom Lane wrote:
> =?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= <
> juanjo.santama...@gmail.com> writes:
> > Thanks for the reminder. Please find attached a rebased version.
>
> (This hasn't shown up on -hackers yet, maybe caught in moderation?)
>
Thanks for l
Em qui., 17 de set. de 2020 às 14:37, Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> escreveu:
>
> On Thu, Sep 17, 2020 at 9:46 AM Michael Paquier
> wrote:
>
>>
>> Could you send a rebase of the patch? Thanks!
>>
>
> Thanks for the reminder. Please find attached a rebased version.
>
Ranier Vilela writes:
> What's wrong with _stat64?
See upthread.
regards, tom lane
I went ahead and added SPI.c, Util.c, and the *kwlist_d.h headers
to the exclusion list. I then tried to run pgindent in a completely
built-out development directory (not distclean'ed, which is the way
I'd always used it before). This found a few more exclusions we
need to have if we want to allo
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> Thanks for the reminder. Please find attached a rebased version.
(This hasn't shown up on -hackers yet, maybe caught in moderation?)
I took a quick look through this. I'm not qualified to review the
actual Windows code in win32stat.c,
On Thu, Sep 17, 2020 at 9:46 AM Michael Paquier wrote:
>
> Could you send a rebase of the patch? Thanks!
>
Thanks for the reminder. Please find attached a rebased version.
Regards,
Juan José Santamaría Flecha
0001-Support-for-large-files-on-Win32-v8.patch
Description: Binary data
On 2020/09/04 13:53, Fujii Masao wrote:
On 2020/09/04 8:29, Anastasia Lubennikova wrote:
On 27.08.2020 16:02, Grigory Smolkin wrote:
Hello!
I`ve noticed, that when running switchover replica to master and back to
replica, new history file is streamed to replica, but not archived,
which is
Hi,
In case gd->any_hashable is FALSE, grouping_is_hashable is never called.
In this case, the planner could use HASH for groupings, but will never know.
Apparently gd pointer, will never be NULL there, verified with Assert(gd !=
NULL).
regards,
Ranier Vilela
v1-0001-check_grouping_is_hashable
Alvaro Herrera writes:
> On 2020-Sep-15, Tom Lane wrote:
>> After further thought, I concluded that's a clearly superior solution,
>> so 0001 attached does it like that. After noting that the enum values
>> are in the opposite direction from how I thought they went, I realized
>> that "increase_l
On 2020/09/17 15:44, Bharath Rupireddy wrote:
Thanks for the review comments. I will post a new patch soon
addressing all the comments.
Thanks a lot!
On Tue, Sep 15, 2020 at 2:49 PM Fujii Masao wrote:
+ PQreset(entry->conn);
Isn't using PQreset() to reconnect to
Daniel Gustafsson writes:
>>> On that note, I
>>> wonder if we should add the plperl .xs generated files as exclusions too
>>> since
>>> we don't control that generator?
>> Not an issue I don't think; pgindent won't touch extensions other than
>> .c and .h.
> Sorry for being unclear, I meant th
čt 17. 9. 2020 v 15:56 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Thu, Sep 17, 2020 at 02:47:54PM +0200, Pavel Stehule wrote:
> > > I have my concerns about the performance side of this implementation as
> > > well as how surprising this would be for users, but at the same tim
čt 17. 9. 2020 v 7:09 odesílatel Michael Paquier napsal:
>
> On Mon, Sep 07, 2020 at 01:13:10PM +0900, Michael Paquier wrote:
> > Josef, the patch has been waiting on author for a bit more than one
> > month, so could you send a rebased version please? It looks that you
> > are still a bit confus
> On Sep 17, 2020, at 5:40 AM, Alvaro Herrera wrote:
>
> On 2020-Sep-17, Michael Paquier wrote:
>
>> On Wed, Jun 10, 2020 at 01:45:02PM -0400, Robert Haas wrote:
>>> My spidey sense is tingling here, telling me that we need some actual
>>> benchmarking.
>>
>> This patch has not received any
On Thu, Sep 17, 2020 at 1:47 AM Michael Paquier wrote:
> On Sat, Aug 15, 2020 at 10:09:15AM +1200, Thomas Munro wrote:
> > And ... now that this has a commitfest entry, cfbot told me about a
> > small problem in a makefile. Third time lucky?
>
> Still lucky since then, and the CF bot does not com
On Sun, Sep 13, 2020 at 12:40 PM Tomas Vondra
wrote:
> <20200913 patch set>
Hi Tomas,
The cfbot fails to apply this, but with 0001 from 0912 it works on my
end, so going with that.
One problem I have is I don't get success with the new reloptions:
create index cd_multi on iot using brin(create
Peter Eisentraut writes:
> committed
A couple of buildfarm animals are reporting instability in the
modified rolenames test, eg
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hoverfly&dt=2020-09-17%2010%3A27%3A36
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2020-09-1
> On Thu, Sep 17, 2020 at 02:47:54PM +0200, Pavel Stehule wrote:
> > I have my concerns about the performance side of this implementation as
> > well as how surprising this would be for users, but at the same time the
> > patch already does something similar and the code change should not be
> > th
Hi,
When I shut down the standby server just after setting up replication
environment and shutting down the primary, I found that it took
five seconds to complete the shutdown of the standby server. Note that
no WAL was generated between the setup of replication and the server
shutdown, in this c
Li Japin wrote:
> If we can improve the efficiency of replay, then we can shorten the database
> recovery time (streaming replication or database crash recovery).
(..)
> For streaming replication, we may need to improve the transmission of WAL
> logs to improve the entire recovery process.
> I’
Thanks for taking a look.
On Thu, Sep 17, 2020 at 9:20 PM Amit Kapila wrote:
> On Thu, Sep 17, 2020 at 3:22 PM Amit Langote wrote:
> >
>
> /*-
> * relation.c
> - *PostgreSQL logical replication
> + *PostgreSQL log
On Wednesday, September 16, 2020 5:32 PM, Kyotaro Horiguchi wrote:
> At Wed, 16 Sep 2020 10:05:32 +0530, Amit Kapila
> wrote in
> > On Wed, Sep 16, 2020 at 9:02 AM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Wed, 16 Sep 2020 08:33:06 +0530, Amit Kapila
> > > wrote in
> > > > On Wed, Sep 16, 2020
On 2020-09-17 15:27, Alexander Kukushkin wrote:
On Thu, 17 Sep 2020 at 14:04, Alexey Kondratov
wrote:
With --restore-target-wal pg_rewind is trying to call restore_command
on
its own and it can happen at two stages:
1) When pg_rewind is trying to find the last checkpoint preceding a
divergen
On Tue, Sep 15, 2020 at 8:54 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Mon, Sep 14, 2020 at 11:26 PM Peter Geoghegan wrote:
> >> The fix seems sensible to me.
>
> > Thanks, I think it is better to wait for a day or two as yesterday
> > only we stamped 13 and we need to backpatch this.
>
> There should be consistency
> >
> > postgres=# create table foo2(a text[]);
> > CREATE TABLE
> > postgres=# insert into foo2 values('{}');
> > INSERT 0 1
> > postgres=# update foo set a[10] = 'AHOJ';
> > UPDATE 1
> > postgres=# select (a)[10] from foo;
> > ┌┐
> > │ a│
> > ╞╡
On 2020-Sep-17, Michael Paquier wrote:
> On Wed, Jun 10, 2020 at 01:45:02PM -0400, Robert Haas wrote:
> > My spidey sense is tingling here, telling me that we need some actual
> > benchmarking.
>
> This patch has not received any replies after this comment for three
> months, so I am marking it a
On Thu, Sep 17, 2020 at 2:02 PM Ajin Cherian wrote:
>
> On Tue, Sep 15, 2020 at 10:43 PM Amit Kapila wrote:
>>
>>
>> Few other comments:
>> ===
>> 1.
>> ReorderBufferProcessTXN()
>> {
>> ..
>> if (streaming)
>> {
>> ReorderBufferTruncateTXN(rb, txn);
>>
>> /* Reset the CheckXidAli
On Thu, 17 Sep 2020 at 14:04, Alexey Kondratov
wrote:
>
> Hm, I cannot understand why wal-g (or any other tool) is trying to run
> pg_rewind, while WAL copying (and prefetch) is still in progress? Why do
> not just wait until it is finished?
wal-g doesn't try to call pg_rewind.
First, we called w
On Thu, Sep 17, 2020 at 3:22 PM Amit Langote wrote:
>
/*-
* relation.c
- *PostgreSQL logical replication
+ *PostgreSQL logical replication relation mapping routines
*
..
* NOTES
* This file contains helper fu
On Mon, Oct 28, 2019 at 06:13:58PM +0100, Juan José Santamaría Flecha wrote:
> At this moment is missing review, so it is probably far from being
> commitable. Any attention is appreciated and might help pushing it forward.
> As a personal note, I have to check that is still applies before the
> up
On Thu, Sep 17, 2020 at 11:38:47AM +0300, Heikki Linnakangas wrote:
> On 15/09/2020 14:36, Heikki Linnakangas wrote:
> > Another patch version, fixed a few small bugs pointed out by assertion
> > failures in the regression tests.
>
> Pushed. Thanks everyone!
+/* FIXME: bump this before pushing! *
On 2020-09-16 15:55, Alexander Kukushkin wrote:
Hello,
Today I bumped into an issue with pg_rewind which is not 100% clear
where should be better fixed.
The first call of pg_rewind failed with the following message:
servers diverged at WAL location A76/39E55338 on timeline 132
could not open fi
> On Thu, Sep 17, 2020 at 01:44:48PM +0900, Michael Paquier wrote:
> On Wed, Sep 16, 2020 at 01:52:27PM +0200, Pavel Stehule wrote:
> > and some natural behaviour - any special case with different behaviour is a
> > bad thing generally.
>
> Please note that v33 of the patch fails to apply, speaking
> On Wed, Sep 16, 2020 at 01:52:27PM +0200, Pavel Stehule wrote:
> > > On Tue, Sep 15, 2020 at 08:42:40PM +0200, Pavel Stehule wrote:
> > >
> > > Maybe I found a another issue.
> > >
> > > create table foo(a jsonb);
> > >
> > > postgres=# select * from foo;
> > > ┌──
On 17/09/2020 13:31, Thomas Munro wrote:
On Thu, Sep 17, 2020 at 10:19 PM Heikki Linnakangas wrote:
If you put the counter in HandleStartupProcInterrupts(), it could be a
long wait if the startup process is e.g. waiting for WAL to arrive in
the loop in WaitForWALToBecomeAvailable(), or in recov
On Thu, Sep 17, 2020 at 10:19 PM Heikki Linnakangas wrote:
> On 17/09/2020 12:48, Thomas Munro wrote:
> > So I think we should do
> > something like what Heikki originally proposed to lower the frequency
> > of checks, on systems where we don't have the ability to skip the
> > check completely. P
On 17/09/2020 12:48, Thomas Munro wrote:
Hello,
In commits 9f095299 and f98b8476 we improved recovery performance on
Linux and FreeBSD but we didn't help other operating systems. David
just confirmed for me that commenting out the PostmasterIsAlive() call
in the main recovery loop speeds up cra
On 2020-09-11 22:05, Alvaro Herrera wrote:
On 2020-Aug-26, Peter Eisentraut wrote:
Here is another patch that also makes comprehensive updates to the rolenames
tests under src/test/modules/unsafe_tests/.
Looks good to me. You need to DROP ROLE "current_role" at the bottom of
rolenames.sql, t
Hi,
$subect needs fixing, because right now it says just:
/*-
* relation.c
*PostgreSQL logical replication
Attached find a patch to expand that a little bit.
--
Amit Langote
EnterpriseDB: http://www.enterprisedb.c
Hello,
In commits 9f095299 and f98b8476 we improved recovery performance on
Linux and FreeBSD but we didn't help other operating systems. David
just confirmed for me that commenting out the PostmasterIsAlive() call
in the main recovery loop speeds up crash recovery considerably on his
Windows sys
On Thu, 17 Sep 2020 at 11:07, Michael Paquier wrote:
>
> On Thu, Jul 16, 2020 at 09:08:09PM +0200, Pavel Stehule wrote:
> > I am sending another patch that tries to allow CachedPlans for CALL
> > statements. I think this patch is very accurate, but it is not nice,
> > because it is smudging very p
At Thu, 17 Sep 2020 17:52:23 +0900 (JST), Kyotaro Horiguchi
wrote in
> Sorry, I sent a wrong version of the patch, contains some spelling
> errors. This is the right one.
Sigh.. I fixed some more wordings.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From bd41d38cb056a6b8fe
Mmm..
At Thu, 17 Sep 2020 17:41:54 +0900 (JST), Kyotaro Horiguchi
wrote in
> While running pgbench, I found tps excluding connection somewhat
> strange. To emphasize the behavior, I inserted some sleep at the end
> of doConnect() and ran pgbench with several times.
Sorry, I sent a wrong versi
> On 17 Sep 2020, at 10:40, Konstantin Knizhnik
> wrote:
> 1. Should I myself change status from WfA to some other?
Yes, when you've addressed any issues raised and posted a new version it's very
helpful to the CFM and the community if you update the status.
> 2. Is there some way to receive n
> 17 сент. 2020 г., в 13:38, Heikki Linnakangas написал(а):
>
> On 15/09/2020 14:36, Heikki Linnakangas wrote:
>> Another patch version, fixed a few small bugs pointed out by assertion
>> failures in the regression tests.
>
> Pushed. Thanks everyone!
That's wonderful! Thank you, Heikki!
Bes
Hello.
While running pgbench, I found tps excluding connection somewhat
strange. To emphasize the behavior, I inserted some sleep at the end
of doConnect() and ran pgbench with several times.
$ pgbench -T 5 -j 1 -c 4 (with 1s sleep in doConnect())
> number of transactions actually processed: 4
On 17.09.2020 8:07, Michael Paquier wrote:
On Thu, Jul 02, 2020 at 06:38:02PM +0300, Konstantin Knizhnik wrote:
Sorry, correct patch is attached.
This needs again a rebase, and has been waiting on author for 6 weeks
now, so I am switching it to RwF.
--
Michael
Attached is rebased version of
On 15/09/2020 14:36, Heikki Linnakangas wrote:
Another patch version, fixed a few small bugs pointed out by assertion
failures in the regression tests.
Pushed. Thanks everyone!
- Heikki
On Tue, Sep 15, 2020 at 10:43 PM Amit Kapila
wrote:
>
> Few other comments:
> ===
> 1.
> ReorderBufferProcessTXN()
> {
> ..
> if (streaming)
> {
> ReorderBufferTruncateTXN(rb, txn);
>
> /* Reset the CheckXidAlive */
> CheckXidAlive = InvalidTransactionId;
> }
> else
> ReorderBuffe
On Wed, Sep 16, 2020 at 2:55 PM Alexander Kukushkin
wrote:
>
> The second time pg_rewind also failed, but the error looked differently:
> servers diverged at WAL location A76/39E55338 on timeline 132
> rewinding from last common checkpoint at A76/1EF254B8 on timeline 132
>
> could not remove file
>>> The attached patch fixes the generation of sql_help.h and perl_opmask.h to
>>> make
>>> sure they conform to pgindent. Those were the only file I got diffs in
>>> after a
>>> pgindent run apart from fmgrprotos.h which gave the below:
>
>> Hmm, I seem to recall there were more when this happ
Horiguchi-san,
Thank you for reviewing.
On Tue, Sep 15, 2020 at 7:01 PM Kyotaro Horiguchi
wrote:
>
> At Tue, 25 Aug 2020 14:28:20 +0200, Daniel Gustafsson wrote
> in
> > > I attach the latest patch that solves the above Werror.
> > > Could you please check it again?
> >
> > This version now
On Wed, Mar 11, 2020 at 04:27:53PM -0700, Paul A Jungwirth wrote:
> Here is a patch rebasing on master (meant to be applied on top of my
> other multirange patch) and newly including UPDATE/DELETE FOR PORTION
> OF. FOR PORTION OF works on any table with a temporal primary key. It
> restricts the UP
On Fri, Sep 04, 2020 at 10:23:34AM +0900, Michael Paquier wrote:
> Adding a markup around OpenSSL in the docs makes things
> consistent. +1.
I have looked at 0001, and applied it after fixing the line length
(thanks for not doing it to ease my lookup), and I found one extra
place in need of fix.
Hi Ashutosh,
I had forgotten about this thread, but Michael's ping email brought it
to my attention.
On Fri, Sep 4, 2020 at 11:12 PM Ashutosh Bapat
wrote:
> Thanks for rebasing patch. It applies cleanly still. Here are some comments
Thanks for the review.
> @@ -3320,7 +3338,9 @@ make_one_parti
73 matches
Mail list logo
