Hello.
The attached is the version that is compactified from the previous
version.
At Thu, 01 Oct 2020 16:47:18 +0900 (JST), Kyotaro Horiguchi
wrote in
> This is the rebased version.
It occurred to me suddenly that static parameters to inline functions
causes optimization. I split SearchCatC
Hi Justin,
Thank you for your comments.
I attached the latest patch(v11) to the previous email.
>
> +* Get its all ancestors to propagate changes_since_analyze
> count.
> +* However, when ANALYZE inheritance tree, we get ancestors of
> +* toprel_oi
On Thu, Oct 15, 2020 at 03:56:21PM +0900, Michael Paquier wrote:
> I got my hands on that, and this proves to simplify a lot things. In
> bonus, attached is a 0003 that cleans up some code in pgcrypto so as
> it uses the in-core resowner facility to handle EVP contexts.
This conflicted on HEAD wi
On Thu, Nov 5, 2020 at 9:44 AM Masahiko Sawada wrote:
>
> On Thu, Nov 5, 2020 at 11:18 AM Kyotaro Horiguchi
> wrote:
> > As another issue, just replace memcpy with strlcpy makes compiler
> > complain of type mismatch, as the first paramter to memcpy had an
> > needless "&" operator. I removed it
On Thu, Nov 5, 2020 at 8:26 AM k.jami...@fujitsu.com
wrote:
>
> On Thursday, November 5, 2020 10:22 AM, Horiguchi-san wrote:
> > >
> > > Can we do a Truncate optimization once we decide about your other
> > > patch as I see a few problems with it? If we can get the first patch
> > > (vacuum optimi
At Mon, 02 Nov 2020 14:43:32 +, Georgios Kokolatos
wrote in
> Hi,
>
> apologies for the very, very late reply to your fixes.
>
> You have answered/addressed all my questions concerns. The added documentation
> reads well, at least to a non native English speaker.
>
> The patch still appli
Horiguchi-san,
Thank you for your comments.
On Fri, Oct 23, 2020 at 8:23 PM Kyotaro Horiguchi
wrote:
>
> Thanks you for the new version.
>
> At Fri, 23 Oct 2020 15:12:51 +0900, yuzuko wrote in
> > Hello,
> >
> > I reconsidered a way based on the v5 patch in line with
> > Horiguchi-san's commen
Hello Osumi-san.
I have checked the v15 patch with regard to my v14 review comments.
On Wed, Nov 4, 2020 at 2:53 PM osumi.takami...@fujitsu.com
wrote:
> > (1) COMMENT
> > File: NA
> > Maybe next time consider using format-patch to make the patch. Then you
> > can include a comment to give the ba
On Thu, Nov 5, 2020 at 7:55 AM Euler Taveira
wrote:
>
> No. Don't worry with translations during the development. Make sure to
follow
> the instructions provided here [1]. Translations are coordinated in a
different
> mailing list: pgsql-translators [2]. There is a different repository [3]
for
> h
On Thu, Nov 5, 2020 at 11:18 AM Kyotaro Horiguchi
wrote:
>
> At Wed, 4 Nov 2020 22:49:57 +0900, Masahiko Sawada
> wrote in
> > On Wed, Nov 4, 2020 at 6:49 PM Amit Kapila wrote:
> > >
> > > On Wed, Nov 4, 2020 at 2:25 PM Kyotaro Horiguchi
> > > wrote:
> > > >
> > > > Hello.
> > > >
> > > > Whil
On Tue, Nov 3, 2020 at 7:19 AM Dave Cramer wrote:
> David,
>
> On Thu, 24 Sep 2020 at 00:22, Michael Paquier wrote:
>
>> On Tue, Sep 08, 2020 at 12:18:23PM -0700, Andres Freund wrote:
>> > A test verifying that a non-transactional message in later aborted
>> > transaction is handled correctly wo
On Wed, Nov 04, 2020 at 10:05:48AM +0100, Magnus Hagander wrote:
> Yes, we should absolutely do that. We already do this for
> pg_strong_random() itself, and we should definitely repeat the pattern
> in the init function.
This poked at my curiosity, so I looked at it. The result looks
indeed like
At Wed, 4 Nov 2020 21:16:29 +0530, Bharath Rupireddy
wrote in
> On Wed, Nov 4, 2020 at 2:36 PM Fujii Masao
> wrote:
> >
> > Regarding other two patches, I think that it's better to use MyLatch
> > rather than MyProc->procLatch or walrcv->latch in WaitLatch() and
> > ResetLatch(), like other co
On Thursday, November 5, 2020 10:22 AM, Horiguchi-san wrote:
> Hello.
>
> Many of the quetions are on the code following my past suggestions.
Yeah, I was also about to answer with the feedback you have given.
Thank you for replying and taking a look too.
> At Wed, 4 Nov 2020 15:59:17 +0530, Amit
On Mon, Nov 2, 2020 at 10:03 AM Peter Geoghegan wrote:
> Actually, it seems better to always count num_index_tuples the old way
> during cleanup-only index VACUUMs, despite the inaccuracy that that
> creates with posting list tuples.
Pushed a fix for this just now.
Thanks for the report!
--
Pet
On Wed, 4 Nov 2020 at 22:52, Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Tue, Nov 3, 2020 at 12:49 PM vignesh C wrote:
>
> 1. Do we need to generate and add the translation of the new GSS
> message in all the language specific files under po/ directory?. See
> below fo
@cfbot: rebased
On Tue, Oct 27, 2020 at 07:33:12PM -0500, Justin Pryzby wrote:
> I'm attaching a counter-proposal to your catalog change, which preserves
> indisclustered on children of clustered, partitioned indexes, and invalidates
> indisclustered when attaching unclustered indexes.
..and now
At Wed, 4 Nov 2020 22:49:57 +0900, Masahiko Sawada
wrote in
> On Wed, Nov 4, 2020 at 6:49 PM Amit Kapila wrote:
> >
> > On Wed, Nov 4, 2020 at 2:25 PM Kyotaro Horiguchi
> > wrote:
> > >
> > > Hello.
> > >
> > > While updating a patch, I noticed that the replication slot stats
> > > patch (9868
On Wed, Nov 04, 2020 at 05:41:39PM +0100, Michael Banck wrote:
> Am Mittwoch, den 04.11.2020, 17:48 +0900 schrieb Michael Paquier:
>> So, I have done much more testing of this patch using an instance with
>> a small shared buffer pool and pgbench running in parallel for having
>> a large eviction r
On Tue, Nov 3, 2020 at 12:49 PM vignesh C wrote:
>
> Thanks for the explanation, I have attached a v5 patch with the
> changes where the translation should not have any problem.
>
I took a look at the V5 patch. Below are some comments:
1. Do we need to generate and add the translation of the new
Hello.
Many of the quetions are on the code following my past suggestions.
At Wed, 4 Nov 2020 15:59:17 +0530, Amit Kapila wrote
in
> On Wed, Nov 4, 2020 at 8:28 AM k.jami...@fujitsu.com
> wrote:
> >
> > Hi,
> >
> > I've updated the patch 0004 (Truncate optimization) with the previous
> > com
On Thu, Nov 5, 2020 at 12:07 PM Tomas Vondra
wrote:
> It's been running for hours on both machines, without any crashes etc.
> While that's not a definitive proof the fix is correct, it certainly
> behaves differently.
Thanks! Embarrassed to have missed that. Pushed.
crake is showing xversion upgrade failures since 9e38c2bb50:
pg_restore: error: could not execute query: ERROR: function
array_cat(anyarray, anyarray) does not exist
Command was: CREATE AGGREGATE "public"."array_cat_accum"("anyarray") (
SFUNC = "array_cat",
STYPE = "anyarray",
INITCO
On Wed, Nov 04, 2020 at 10:47:43AM -0500, Tom Lane wrote:
> I do not think that that's a fatal objection. I doubt anyone has
> applications that are automatically issuing that sort of command and
> would be broken by a change. I think backwards compatibility is
> sufficiently met if the behavior
On Tue, Nov 3, 2020 at 4:42 PM Tomas Vondra
wrote:
>
> On Tue, Nov 03, 2020 at 03:53:53AM +0100, Tomas Vondra wrote:
> >Hi,
> >
> >I took another look at this, and 99% of the patch (the fixes to sort
> >debug messages) seems fine to me. Attached is the part I plan to get
> >committed, including c
On 11/4/20 2:50 PM, Tomas Vondra wrote:
On Wed, Nov 04, 2020 at 05:36:46PM +1300, Thomas Munro wrote:
On Wed, Nov 4, 2020 at 2:57 PM Tomas Vondra
wrote:
On Wed, Nov 04, 2020 at 02:49:24PM +1300, Thomas Munro wrote:
>On Wed, Nov 4, 2020 at 2:32 PM Tomas Vondra
> wrote:
>> After a while (~1h on
I've attached a patch with the corrections I mentioned upthread.
I've gone ahead and run pgindent, though, I can't say that I'm very
happy with the result.
I'm still not quite happy with the name
BarrierArriveAndDetachExceptLast(). It's so literal. As you said, there
probably isn't a nice name for
On 11/4/20 2:05 AM, Tomas Vondra wrote:
Hi,
As pointed out in [1], BRIN is not properly handling toasted data, which
may easily lead to index tuples referencing TOAST-ed values. Which is
clearly wrong - it's trivial to trigger failues after a DELETE.
Attached is a patch that aims to fix this -
On 11/4/20 10:58 PM, David Rowley wrote:
On Wed, 4 Nov 2020 at 10:42, Tomas Vondra wrote:
IMHO this should simply switch the current int64 variable to long, as it
was before. Not sure about about the hashagg uint64 variable.
IMO, we should just get rid of the use of "long" here. As far as
st 4. 11. 2020 v 22:12 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > út 22. 9. 2020 v 2:33 odesílatel Tom Lane napsal:
> >> Anyway, attached find
> >> 0001 - updates Vik's original patch to HEAD and tweaks the
> >> grammar in the docs a bit.
> >> 0002 - add-on patch to convert array_a
On Wed, 4 Nov 2020 at 10:42, Tomas Vondra wrote:
> IMHO this should simply switch the current int64 variable to long, as it
> was before. Not sure about about the hashagg uint64 variable.
IMO, we should just get rid of the use of "long" here. As far as I'm
concerned, using long in the core code
Em ter., 3 de nov. de 2020 às 22:09, Kyotaro Horiguchi <
horikyota@gmail.com> escreveu:
> At Tue, 3 Nov 2020 20:44:23 +1300, Thomas Munro
> wrote in
> > On Tue, Nov 3, 2020 at 12:50 AM Kyotaro Horiguchi
> > wrote:
> > > With the fix patch, it changes to:
> > >
> > > [16632] LOG: FALSE LATCH
Pavel Stehule writes:
> út 22. 9. 2020 v 2:33 odesílatel Tom Lane napsal:
>> Anyway, attached find
>> 0001 - updates Vik's original patch to HEAD and tweaks the
>> grammar in the docs a bit.
>> 0002 - add-on patch to convert array_append, array_prepend,
>> array_cat, array_position, array_positio
Hi,
On 11/4/20 5:02 PM, Stephen Frost wrote:
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
If you highlight "738754560" in the output it appears to duplicate the
syscalls issued until it preads() - in case of "738754560" offset it was
asked for 3 times. Also I wouldn't imagi
Hi,
Am Mittwoch, den 04.11.2020, 17:48 +0900 schrieb Michael Paquier:
> On Fri, Oct 30, 2020 at 11:30:28AM +0900, Michael Paquier wrote:
> > Playing with dd and generating random pages, this detects random
> > corruptions, making use of a wait/retry loop if a failure is detected.
> > As mentioned
I wrote:
> Heikki Linnakangas writes:
>> On 01/11/2020 22:47, Tom Lane wrote:
>>> With that, we don't actually need aggregate_dummy() to exist at
>>> all, because it's never referenced. Having "aggregate_dummy"
>>> as the prosrc value for an aggregate function is now just a
>>> random convention;
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> >If you highlight "738754560" in the output it appears to duplicate the
> >syscalls issued until it preads() - in case of "738754560" offset it was
> >asked for 3 times. Also I wouldn't imagine in wildest dreams that
> >posix_fadvi
Hi all.
Back in 2016 I started a thread about making cancellations safer[1], I'd
like to try to pick this up again. Here a summary of the previous
conversation:
The main ask here is to allow clients to specify which command to cancel,
to avoid various race conditions where the wrong command is ac
Michael Paquier writes:
> Anyway, we have a compatibility problem once we use ALTER SYSTEM.
> Just take the following command:
> alter system set unix_socket_directories = '/tmp/sock1, /tmp/sock2';
> On HEAD, this would be treated and parsed as two items. However, with
> the patch, this becomes
On Wed, Nov 4, 2020 at 2:36 PM Fujii Masao wrote:
>
> Regarding other two patches, I think that it's better to use MyLatch
> rather than MyProc->procLatch or walrcv->latch in WaitLatch() and
> ResetLatch(), like other code does. Attached are the updated versions
> of the patches. Thought?
>
+1 fo
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Wed, Nov 04, 2020 at 09:07:59AM +, Jakub Wartak wrote:
> >I saw up 410MB/s for a few seconds with this patch on NVMe, and that's
> >huge ~5.2x improvement which is amazing for a such simple patch.
Nice!
> >The system and da
On Wed, Nov 04, 2020 at 09:07:59AM +, Jakub Wartak wrote:
Greetings Stephen,
I saw up 410MB/s for a few seconds with this patch on NVMe, and that's
huge ~5.2x improvement which is amazing for a such simple patch.
The system and data was identical like last time, so results are directly
co
On Wed, Nov 04, 2020 at 05:36:46PM +1300, Thomas Munro wrote:
On Wed, Nov 4, 2020 at 2:57 PM Tomas Vondra
wrote:
On Wed, Nov 04, 2020 at 02:49:24PM +1300, Thomas Munro wrote:
>On Wed, Nov 4, 2020 at 2:32 PM Tomas Vondra
> wrote:
>> After a while (~1h on my machine) the pg_multixact gets over 10
On Wed, Nov 4, 2020 at 6:49 PM Amit Kapila wrote:
>
> On Wed, Nov 4, 2020 at 2:25 PM Kyotaro Horiguchi
> wrote:
> >
> > Hello.
> >
> > While updating a patch, I noticed that the replication slot stats
> > patch (9868167500) put some somewhat doubious codes.
> >
> > In pgstat_recv_replslot, an ass
> On 2 Nov 2020, at 15:17, Andrew Dunstan wrote:
> We could generalize that saving mechanism and do it if any module
> required it. But instead of testing against a different branch, we'd
> test against a different animal. So we'd have two animals, one building
> with openssl and one with nss, an
On 2020-11-03 11:48, Michael Paquier wrote:
On Mon, Nov 02, 2020 at 10:01:53AM -0500, Tom Lane wrote:
Peter Eisentraut writes:
I noticed that hash_array_extended() does not pass down the collation to
the element's collation function, unlike hash_array(). As a
consequence, hash partitioning us
On Wed, Nov 4, 2020 at 3:46 PM Ajin Cherian wrote:
>
> On Wed, Nov 4, 2020 at 9:02 PM Amit Kapila wrote:
> >
> > On Wed, Nov 4, 2020 at 3:01 PM Ajin Cherian wrote:
> > >
> > > On Mon, Nov 2, 2020 at 9:40 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Wed, Oct 28, 2020 at 10:50 AM Peter Smith
On Wed, Nov 4, 2020 at 8:28 AM k.jami...@fujitsu.com
wrote:
>
> Hi,
>
> I've updated the patch 0004 (Truncate optimization) with the previous
> comments of
> Tsunakawa-san already addressed in the patch. (Thank you very much for the
> review.)
> The change here compared to the previous version i
On Wed, Nov 4, 2020 at 9:02 PM Amit Kapila wrote:
>
> On Wed, Nov 4, 2020 at 3:01 PM Ajin Cherian wrote:
> >
> > On Mon, Nov 2, 2020 at 9:40 PM Amit Kapila wrote:
> > >
> > > On Wed, Oct 28, 2020 at 10:50 AM Peter Smith
> > > wrote:
> > > 2.
> > > +DecodePrepare(LogicalDecodingContext *ctx, XL
On Wed, Nov 4, 2020 at 3:01 PM Ajin Cherian wrote:
>
> On Mon, Nov 2, 2020 at 9:40 PM Amit Kapila wrote:
> >
> > On Wed, Oct 28, 2020 at 10:50 AM Peter Smith wrote:
> > 2.
> > +DecodePrepare(LogicalDecodingContext *ctx, XLogRecordBuffer *buf,
> > + xl_xact_parsed_prepare * parsed)
> > +{
> > .
On Wed, Nov 4, 2020 at 2:25 PM Kyotaro Horiguchi
wrote:
>
> Hello.
>
> While updating a patch, I noticed that the replication slot stats
> patch (9868167500) put some somewhat doubious codes.
>
> In pgstat_recv_replslot, an assertion like the following exists:
>
> > idx = pgstat_replslot_ind
>
> > I have only one thing to note: as this patch doesn't disable <^ and >^
> operator for boxes the existing state of documentation seem consistent to
> me:
> >
> > select '((0,0),(1,1))'::box <<| '((0,1),(1,2))'::box;
> > --
> > f
> >
> > select '((0,0),(1,1))'::box <^ '((0,1),(1,2))'::
> I've rebased and tested your proposed patch. It seems fine and sensible to me.
Thanks
> I have only one thing to note: as this patch doesn't disable <^ and >^
> operator for boxes the existing state of documentation seem consistent to me:
>
> select '((0,0),(1,1))'::box <<| '((0,1),(1,2))'::bo
On Mon, Nov 2, 2020 at 9:40 PM Amit Kapila wrote:
>
> On Wed, Oct 28, 2020 at 10:50 AM Peter Smith wrote:
> >
> > Hi Ajin.
> >
> > I have re-checked the v13 patches for how my remaining review comments
> > have been addressed.
> >
> > On Tue, Oct 27, 2020 at 8:55 PM Ajin Cherian wrote:
> > >
> >
On Fri, Oct 30, 2020 at 9:51 PM Amit Kapila wrote:
>
> On Fri, Oct 30, 2020 at 2:46 PM Ajin Cherian wrote:
> >
> > On Thu, Oct 29, 2020 at 11:19 PM Amit Kapila
> > wrote:
> > >
> > >
> > > 6.
> > > +pg_decode_stream_prepare(LogicalDecodingContext *ctx,
> > > + ReorderBufferTXN *txn,
> > > + XLo
On 25/09/2020 02:56, Soumyadeep Chakraborty wrote:
On Thu, Sep 24, 2020 at 10:27 AM Heikki Linnakangas wrote:
7. Please address the FIXME for the symlink case:
/* FIXME: Check if it points to the same target? */
It's not a new issue. Would be nice to fix, of course. I'm not sure what
the righ
Greetings Stephen,
I saw up 410MB/s for a few seconds with this patch on NVMe, and that's
huge ~5.2x improvement which is amazing for a such simple patch.
The system and data was identical like last time, so results are directly
comparable
to the previous post. The only change is that I've ap
On Wed, Nov 4, 2020 at 2:01 AM Michael Paquier wrote:
>
> On Tue, Nov 03, 2020 at 01:46:38PM +0100, Magnus Hagander wrote:
> > On Tue, Nov 3, 2020 at 1:00 PM Daniel Gustafsson wrote:
> >> I kind of like the idea of continuing to abstract this functionality, not
> >> pulling in OpenSSL headers in
On 2020/10/29 15:21, Fujii Masao wrote:
On 2020/10/07 11:30, Bharath Rupireddy wrote:
On Tue, Oct 6, 2020 at 11:41 AM Bharath Rupireddy
wrote:
On Tue, Oct 6, 2020 at 11:20 AM Fujii Masao wrote:
+1 Or it's also ok to make each patch separately.
Anyway, thanks!
Thanks. +1 to have sepa
Emre,
I've rebased and tested your proposed patch. It seems fine and sensible to
me.
I have only one thing to note: as this patch doesn't disable <^ and >^
operator for boxes the existing state of documentation seem consistent to
me:
select '((0,0),(1,1))'::box <<| '((0,1),(1,2))'::box;
-
Hello.
While updating a patch, I noticed that the replication slot stats
patch (9868167500) put some somewhat doubious codes.
In pgstat_recv_replslot, an assertion like the following exists:
> idx = pgstat_replslot_index(msg->m_slotname, !msg->m_drop);
..
> Assert(idx >= 0 && idx < m
On Tue, 2020-11-03 at 23:14 +0100, Christoph Berg wrote:
> Re: Thomas Munro
> > for all I know, "en" variants might change
> > independently (I doubt it in practice, but in theory it's wrong).
>
> Long before the glibc 2.28 incident, the same collation change
> had already happened twice, namely b
On Fri, Oct 30, 2020 at 11:30:28AM +0900, Michael Paquier wrote:
> Playing with dd and generating random pages, this detects random
> corruptions, making use of a wait/retry loop if a failure is detected.
> As mentioned upthread, this is a double-edged sword, increasing the
> number of retries redu
On Wed, Nov 4, 2020 at 4:11 PM Michael Paquier wrote:
>
> On Wed, Nov 04, 2020 at 08:44:15AM +0100, Juan José Santamaría Flecha wrote:
> > We could create a static table with the conversion based on what was
> > discussed for commit a169155, please find attached a spreadsheet with the
> > compari
On Wed, Nov 04, 2020 at 08:44:15AM +0100, Juan José Santamaría Flecha wrote:
> We could create a static table with the conversion based on what was
> discussed for commit a169155, please find attached a spreadsheet with the
> comparison. This would require maintenance as new LCIDs are released [1]
65 matches
Mail list logo
