On Fri, 11 Sep 2020 at 18:24, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> > On Tue, 8 Sep 2020 at 13:00, tsunakawa.ta...@fujitsu.com
> > wrote:
> > > 2. 2PC processing is queued and serialized in one background worker. That
> > severely subdues transaction throughput. Each b
В письме от понедельник, 20 июля 2020 г. 18:36:44 MSK пользователь Georgios
Kokolatos написал:
Hi! Sorry for really long delay, I was at my summer vacations, and then has
urgent things to finish first. :-( Now I hope we can continue...
> thank you for the patch. It applies cleanly, compiles a
I happened to try googling for other similar reports, and I found
a very interesting recent thread here:
https://github.com/nodejs/node/issues/33166
It might not have the same underlying cause, of course, but it sure
sounds familiar. If Node.js are really seeing the same effect,
that would point
On Thu, Sep 10, 2020 at 12:20 PM Yaroslav wrote:
> Disclaimer: I'm not a native speaker, so not sure those are actually
> incorrect, and can't offer non-trivial suggestions.
I skimmed about 2/3rds of these and while I agree on the surface that
probably 3/4ths of them are improvements they aren'
While trying to understand a recent buildfarm failure [1], I got annoyed
by the fact that a walsender exposes its last SQL command in
pg_stat_activity even when that was a long time ago and what it's been
doing since then is replication commands. This leads to *totally*
misleading reports, for ins
While implementing streaming replication client functionality for Npgsql
I stumbled upon a minor documentation error at
https://www.postgresql.org/docs/current/protocol-replication.html
The "content" return value for the TIMELINE_HISTORYcommand is advertised
as bytea while it is in fact raw ASCII
Brar Piening wrote:
> This is certainly a minor problem
After thinking about it a little more I think that at least the fact
that even the row description message advertises the content as bytea
could be considered as a bug - no?
Amit Kapila writes:
> Pushed.
Observe the following reports:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=idiacanthus&dt=2020-09-13%2016%3A54%3A03
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=desmoxytes&dt=2020-09-10%2009%3A08%3A03
https://buildfarm.postgresql.org/cgi-bin/s
On Tue, Sep 8, 2020 at 10:53 AM Tom Lane wrote:
> Thomas Munro writes:
> > FWIW I just spotted a couple of very suspicious looking failures for
> > build farm animal "walleye", a "MinGW64 8.1.0" system, that say:
>
> walleye's been kind of unstable since the get-go, so I wouldn't put
> too much f
I wrote:
> I think that walsenders ought to report their current replication command
> as though it were a SQL command. They oughta set debug_query_string, too.
I also notice that a walsender does not maintain its ps status:
postgres 921109 100 0.0 32568 11880 ?Rs 18:57 0:51 post
I wrote:
> Probably this requires a relcache inval at the wrong time;
> although we have recent passes from CLOBBER_CACHE_ALWAYS animals,
> so that can't be the whole triggering condition. I wonder whether
> it is relevant that all of the complaining animals are JIT-enabled.
Hmmm ... I take that
On Sat, Sep 12, 2020 at 12:40:49PM +0200, Julien Rouhaud wrote:
> agreed.
Ok, done as ac673a1 then.
--
Michael
signature.asc
Description: PGP signature
Hi,
Attached fixes $subject.
Thanks,
Naoki Nakamichidiff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index 1c0cd6b248..672d2083cc 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -4106,7 +4106,7 @@ GlobalVisCheckR
On 2020/09/14 11:06, btnakamichin wrote:
Hi,
Attached fixes $subject.
Thanks for the patch! LGTM. I will commit it.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On Mon, Sep 14, 2020 at 3:08 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > Pushed.
>
> Observe the following reports:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=idiacanthus&dt=2020-09-13%2016%3A54%3A03
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=desmoxytes&dt=2020-
I wrote:
> * Starting over, it appears that 001_rep_changes.pl almost immediately
> gets into an infinite loop. It does not complete the third test step,
> rather infinitely waiting for progress to be made.
Ah, looking closer, the problem is that wal_receiver_timeout = 60s
is too short when the s
On Mon, Sep 14, 2020 at 3:08 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > Pushed.
>
> Observe the following reports:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=idiacanthus&dt=2020-09-13%2016%3A54%3A03
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=desmoxytes&dt=2020-
Hello,
On Fri, Aug 7, 2020 at 9:26 PM Amit Langote wrote:
> On Tue, Aug 4, 2020 at 3:15 PM Amit Langote wrote:
> > On Sat, Aug 1, 2020 at 4:46 AM Robert Haas wrote:
> > > On Fri, Jun 26, 2020 at 8:36 AM Amit Langote
> > > wrote:
> > > > 0001 and 0002 are preparatory patches.
> > >
> > > I rea
On Fri, 11 Sep 2020 at 04:08, Alvaro Herrera
wrote:
>
> Pushed, thanks!
>
Thanks Alvaro.
--
Best Wishes,
Ashutosh
On Fri, Sep 11, 2020 at 06:42:09PM +0300, Anastasia Lubennikova wrote:
> I agree that transactional update in index_set_state_flags() is good for
> both cases, that you mentioned and don't see any restrictions. It seems that
> not doing this before was just a loose end, as the comment from 813fb03
On 2020/09/14 11:14, Fujii Masao wrote:
On 2020/09/14 11:06, btnakamichin wrote:
Hi,
Attached fixes $subject.
Thanks for the patch! LGTM. I will commit it.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORP
On Fri, 11 Sep 2020 at 17:48, Thomas Munro wrote:
>
> On Fri, Sep 11, 2020 at 3:53 AM David Rowley wrote:
> > That gets my benchmark down to 60.8 seconds, so 2.2 seconds better than v4b.
>
> . o O ( I wonder if there are opportunities to squeeze some more out
> of this with __builtin_prefetch...
Hi Alvaro,
On Sat, Sep 12, 2020 at 5:42 AM Alvaro Herrera wrote:
>
> I noticed that this bugfix has stalled, probably because the other
> bugfix has also stalled.
>
> It seems that cleanly returning system columns from table AM is not
> going to be a simple task -- whatever fix we get for that is
23 matches
Mail list logo
