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
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...
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, 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 Fri, 11 Sep 2020 at 04:08, Alvaro Herrera
wrote:
>
> Pushed, thanks!
>
Thanks Alvaro.
--
Best Wishes,
Ashutosh
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 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-
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
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 Sat, Sep 12, 2020 at 12:40:49PM +0200, Julien Rouhaud wrote:
> agreed.
Ok, done as ac673a1 then.
--
Michael
signature.asc
Description: PGP signature
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
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
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
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
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?
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
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'
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
В письме от понедельник, 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
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
23 matches
Mail list logo
