It seems that a concurrent UPDATE can restart heap_lock_tuple() even if it's
not necessary. Is the attached proposal correct and worth applying?
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 6ac07
On Wed, May 26, 2021 at 12:18 PM tsunakawa.ta...@fujitsu.com
wrote:
>
> Hello Paul-san,
>
> From: Daniel Gustafsson
> > In an off-list discussion with Paul, we decided to withdraw this patch for
> > now
> > and instead create a new entry when there is a re-worked patch. This has
> > now
> > bee
From: Bharath Rupireddy
> I think the "New Table Access Methods for Multi and Single Inserts"
> patches at [1] make multi insert usage easy for COPY, CTAS/Create Mat
> View, Refresh Mat View and so on. It also has a patch for multi
> inserts in CTAS and Refresh Mat View
> (v6-0002-CTAS-and-REFRESH
On Wed, May 26, 2021 at 12:49 PM tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Bharath Rupireddy
> > I think the "New Table Access Methods for Multi and Single Inserts"
> > patches at [1] make multi insert usage easy for COPY, CTAS/Create Mat
> > View, Refresh Mat View and so on. It also has a pat
Hi,
I found a possible typo in the code comments of heap_multi_insert.
- * heap_multi_insert - insert multiple tuple into a heap
+ * heap_multi_insert - insert multiple tuples into a heap
Attaching a patch to fix it.
Best regards,
houzj
0001-fix-typo.patch
Description: 000
On Thu, Apr 22, 2021 at 01:36:03PM -0700, Andres Freund wrote:
> The sequence in StartupXLOG() leading to the issue is the following:
>
> 1) RecoverPreparedTransactions();
> 2) ShutdownRecoveryTransactionEnvironment();
> 3) XLogCtl->SharedRecoveryState = RECOVERY_STATE_DONE;
>
> Because 2) resets
On Wed, Apr 14, 2021 at 11:17 PM Mead, Scott wrote:
>
>
>
> > On Mar 1, 2021, at 8:43 PM, Masahiko Sawada wrote:
> >
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you can confirm the sender and know
> > the content is safe
On Wed, May 26, 2021 at 11:53 AM Dilip Kumar wrote:
>
> On Wed, May 26, 2021 at 11:19 AM Amit Kapila wrote:
> >
>
> > I searched and didn't find any similar existing tests. Can we think of
> > any other way to test this code path? We already have one copy test in
> > toast.sql, isn't it possible
On 26 May 2021, at 05:04, Amit Kapila wrote:
>
> On Tue, May 25, 2021 at 12:40 PM Michael Paquier wrote:
>>
>> On Mon, May 24, 2021 at 10:03:01AM +0530, Amit Kapila wrote:
>>> So, this appears to be an existing caveat of synchronous replication.
>>> If that is the case, I am not sure if it is a
On Tue, May 25, 2021 at 8:54 AM Ajin Cherian wrote:
>
> On Fri, May 21, 2021 at 6:43 PM Peter Smith wrote:
>
> > Fixed in v77-0001, v77-0002
>
> Attaching a new patch-set that rebases the patch, addresses review
> comments from Peter as well as a test failure reported by Tang. I've
> also added s
On Tue, May 25, 2021 at 12:40 PM Michael Paquier wrote:
>
> On Mon, May 24, 2021 at 10:03:01AM +0530, Amit Kapila wrote:
> > So, this appears to be an existing caveat of synchronous replication.
> > If that is the case, I am not sure if it is a good idea to just block
> > such ops for the prepared
On Tue, May 25, 2021 at 6:12 PM Masahiko Sawada wrote:
>
> On Tue, May 25, 2021 at 7:21 PM Bharath Rupireddy
> wrote:
> >
> > If there's no way to get the "correct LSN", then why can't we just
> > print that LSN in the error context and/or in the new statistics view
> > for logical replication wo
On Wed, May 26, 2021 at 1:53 PM Petr Jelinek
wrote:
>
> On 26 May 2021, at 05:04, Amit Kapila wrote:
> >
> > On Tue, May 25, 2021 at 12:40 PM Michael Paquier
> > wrote:
> >>
> >> It seems to me that the 2PC issues on catalog tables and the issues
> >> related to logical replication in synchonou
Hi hackers,
Many thanks for your feedback, I very much appreciate it!
> If the extension is mature enough, why make it an extension in
> contrib, and not instead either enhance the existing jsonb type with
> it or make it a built-in type?
> IMO we have too d*mn many JSON types already. If we ca
On Wed, May 26, 2021 at 07:37:15AM +, houzj.f...@fujitsu.com wrote:
> I found a possible typo in the code comments of heap_multi_insert.
>
> - * heap_multi_insert - insert multiple tuple into a heap
> + * heap_multi_insert - insert multiple tuples into a heap
>
> Attaching a p
On Tue, May 25, 2021 at 12:05 PM houzj.f...@fujitsu.com
wrote:
>
> I noticed one place which could be one of the reasons that cause the
> performance degradation.
>
> + /*
> +* We don't need to skip contacting FSM while inserting
> tuples for
> +* pa
On Tue, May 25, 2021 at 1:10 PM tsunakawa.ta...@fujitsu.com
wrote:
>
> Although this should be a controversial and may be crazy idea, the following
> change brought 4-11% speedup. This is because I thought parallel workers
> might contend for WAL flush as a result of them using the limited ring
On Tue, May 25, 2021 at 1:50 PM tsunakawa.ta...@fujitsu.com
wrote:
>
> From: houzj.f...@fujitsu.com
> > + /*
> > + * We don't need to skip contacting FSM while inserting tuples
> > for
> > + * parallel mode, while extending the relations, workers
> > instead
On Wed, May 26, 2021 at 1:47 PM Dilip Kumar wrote:
>
> On Wed, May 26, 2021 at 11:53 AM Dilip Kumar wrote:
> >
> > On Wed, May 26, 2021 at 11:19 AM Amit Kapila
> > wrote:
> > >
>
> >
> > > I searched and didn't find any similar existing tests. Can we think of
> > > any other way to test this co
On Fri, May 21, 2021 at 3:46 PM Amit Kapila wrote:
>
> On Fri, Mar 19, 2021 at 11:02 AM Bharath Rupireddy
> wrote:
> >
> > On Wed, Jan 27, 2021 at 1:47 PM Bharath Rupireddy
> > wrote:
> > >
> >
> > I analyzed performance of parallel inserts in CTAS for different cases
> > with tuple size 32bytes
On Wed, May 26, 2021 at 5:28 PM Bharath Rupireddy
wrote:
>
> On Fri, May 21, 2021 at 3:46 PM Amit Kapila wrote:
> >
> > On Fri, Mar 19, 2021 at 11:02 AM Bharath Rupireddy
> > wrote:
> > >
>
> > The other possibility could
> > be that the free pages added to FSM by one worker are not being used
>
On Wed, May 26, 2021 at 5:28 PM Amit Kapila wrote:
>
> On Wed, May 26, 2021 at 1:47 PM Dilip Kumar wrote:
> >
> > On Wed, May 26, 2021 at 11:53 AM Dilip Kumar wrote:
> > >
> > > On Wed, May 26, 2021 at 11:19 AM Amit Kapila
> > > wrote:
> > > >
> >
> > >
> > > > I searched and didn't find any s
On 5/26/21 8:57 AM, Bharath Rupireddy wrote:
On Tue, May 25, 2021 at 2:47 PM Bharath Rupireddy
wrote:
On Tue, May 25, 2021 at 1:08 PM houzj.f...@fujitsu.com
wrote:
Thanks for the comments. I have addressed all comments to the v3 patch.
Thanks! The patch basically looks good to me except th
On Wed, May 26, 2021 at 6:36 PM Tomas Vondra
wrote:
>
> On 5/26/21 8:57 AM, Bharath Rupireddy wrote:
> > On Tue, May 25, 2021 at 2:47 PM Bharath Rupireddy
> > wrote:
> >>
> >> On Tue, May 25, 2021 at 1:08 PM houzj.f...@fujitsu.com
> >> wrote:
> >>> Thanks for the comments. I have addressed all c
On Tue, Apr 27, 2021 at 3:21 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> While reviewing [1], I found that the CREATE COLLATION doesn't throw an error
> if duplicate options are specified, see [2] for testing a few cases on HEAD.
> This may end up accepting some of the weird cases, see [2]. It's aga
On Mon, Apr 5, 2021 at 7:19 PM Bharath Rupireddy
wrote:
>
> On Mon, Apr 5, 2021 at 6:41 PM Euler Taveira wrote:
> > Here's the v4 patch reabsed on the latest master, please review it further.
> >
> > /* UNLOGGED and TEMP relations cannot be part of publication. */
> > if (!RelationIsPermanent(tar
On Wed, May 26, 2021 at 7:18 PM vignesh C wrote:
> +1 for fixing this issue, we have handled this error in other places.
> The patch does not apply on head, could you rebase the patch on head
> and post a new patch.
Thanks. I thought of rebasing once the other patch (which reorganizes
"...specifi
On Wed, May 26, 2021 at 7:38 PM vignesh C wrote:
> > Attaching v5 patch, please have a look.
>
> We get the following error while adding an index:
> create publication mypub for table idx_t1;
> ERROR: "idx_t1" is an index
>
> This error occurs internally from table_openrv function call, if we
> c
On 5/26/21 2:43 AM, Laurenz Albe wrote:
> On Wed, 2021-05-26 at 08:57 +0900, Michael Paquier wrote:
>> On Tue, May 25, 2021 at 03:17:37PM -0400, Andrew Dunstan wrote:
>>> If we do decide to do something the question arises what should it do?
>>> If we're to allow for it I'm wondering if the best
On Thu, Feb 4, 2021 at 1:13 AM Stephen Frost wrote:
> Greetings,
>
> * Ibrar Ahmed (ibrar.ah...@gmail.com) wrote:
> > Anyone else already volunteers that? It is my first time so need some
> > access, if all agree.
>
> Thanks for volunteering!
>
> That said, our last commitfest tends to be the mos
On Wed, May 12, 2021 at 6:21 PM Tom Lane wrote:
> Here's a v2 that does things that way (and is rebased up to HEAD).
> I did some more documentation cleanup, too.
The first hunk of the patch seems to back away from the idea that the
cutoff is 13000, but the second half of the patch says 13000 sti
On 25.05.2021 13:55, Aleksander Alekseev wrote:
Hi hackers,
Back in 2016 while being at PostgresPro I developed the ZSON extension
[1]. The extension introduces the new ZSON type, which is 100%
compatible with JSONB but uses a shared dictionary of strings most
frequently used in given JSON
Michael Paquier writes:
> Ah, the parallel with reltablespace and default_tablespace at database
> level is a very good point. It is true that currently the code would
> assign attcompression to a non-zero value once the relation is defined
> depending on default_toast_compression set for the dat
On Wed, May 26, 2021 at 11:13 AM Tom Lane wrote:
> * As things stand here, once you've applied ALTER ... SET COMPRESSION
> to select a specific method, there is no way to undo that and go
> back to the use-the-default setting. All you can do is change to
> explicitly select the other method. Sho
Robert Haas writes:
> The first hunk of the patch seems to back away from the idea that the
> cutoff is 13000, but the second half of the patch says 13000 still
> matters. Not sure I understand what's going on there exactly.
Not sure exactly what you're looking at, but IIRC there is a place
where
On Wed, May 26, 2021 at 2:44 AM Dilip Kumar wrote:
> I think we need to create some content on promoted standby and check
> whether the cascade standby is able to get that or not, that will
> guarantee that it is actually following the promoted standby, I have
> added the test for that so that it
On Wed, May 26, 2021 at 9:40 PM Robert Haas wrote:
>
> On Wed, May 26, 2021 at 2:44 AM Dilip Kumar wrote:
> > I think we need to create some content on promoted standby and check
> > whether the cascade standby is able to get that or not, that will
> > guarantee that it is actually following the
On Wed, May 26, 2021 at 11:37 AM Tom Lane wrote:
> In any case it doesn't seem like the issue is entirely pressing
> yet. Although ... maybe we should do that last bit now, so
> that we can revert FirstBootstrapObjectId to 12K before v14
> ships? I've felt a little bit of worry that that change
On Wed, May 26, 2021 at 12:26 PM Dilip Kumar wrote:
> I will check if there is any timing dependency in the test case.
There is. I explained it in the second part of my email, which you may
have failed to notice.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, 26 May 2021 at 10:06 PM, Robert Haas wrote:
> On Wed, May 26, 2021 at 12:26 PM Dilip Kumar
> wrote:
> > I will check if there is any timing dependency in the test case.
>
> There is. I explained it in the second part of my email, which you may
> have failed to notice.
Sorry, my bad. I
On 25.05.21 22:21, Tom Lane wrote:
Yeah, the odd behavior of CALL is where I started from, but now I think
the main problem is with the signature (ie, allowing procedures with
signatures that differ only in OUT parameter positions). If we got
rid of that choice then it'd be possible to document
On Wed, 26 May 2021 at 12:49, Aleksander Alekseev
wrote:
>
> Hi hackers,
>
> Many thanks for your feedback, I very much appreciate it!
>
> > If the extension is mature enough, why make it an extension in
> > contrib, and not instead either enhance the existing jsonb type with
> > it or make it a b
Robert Haas writes:
> So I think your proposal of allowing genbki-assigned OIDs to be reused
> in different catalogs is probably a pretty good one, but I wonder if
> we could just rejigger things so that collations just get normal OIDs
> > 16384.
Hm. I can't readily think of a non-hack way of ma
Peter Eisentraut writes:
> AFAICT, your patch does not main the property that
> CREATE PROCEDURE p1(OUT int, OUT int)
> corresponds to
> DROP PROCEDURE p1(int, int)
> which would be bad.
Why? If it actually works that way right now, I'd maintain
strenously that it's broken. The latter
>
> Hi, Amit:
>
For ConvertTupleToPartition() in
0001-ExecFindPartition-cache-last-used-partition-v3.patch:
+ if (tempslot != NULL)
+ ExecClearTuple(tempslot);
If tempslot and parent_slot point to the same slot, should ExecClearTuple()
still be called ?
Cheers
On Tue, May 25, 2021 at 7:58 PM Stephen Frost wrote:
> The simple thought I had was masking them out, yes. No, you can't
> re-encrypt a different page with the same nonce. (Re-encrypting the
> exact same page with the same nonce, however, just yields the same
> cryptotext and therefore is fine).
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, May 25, 2021 at 7:58 PM Stephen Frost wrote:
> > The simple thought I had was masking them out, yes. No, you can't
> > re-encrypt a different page with the same nonce. (Re-encrypting the
> > exact same page with the same nonce, h
Robert Haas writes:
> On Wed, May 26, 2021 at 11:13 AM Tom Lane wrote:
>> * As things stand here, once you've applied ALTER ... SET COMPRESSION
>> to select a specific method, there is no way to undo that and go
>> back to the use-the-default setting. All you can do is change to
>> explicitly se
On Wed, May 26, 2021 at 11:13:46AM -0400, Tom Lane wrote:
> Michael Paquier writes:
> > Ah, the parallel with reltablespace and default_tablespace at database
> > level is a very good point. It is true that currently the code would
> > assign attcompression to a non-zero value once the relation i
On Wed, May 26, 2021 at 07:14:47AM +0200, Antonin Houska wrote:
> Bruce Momjian wrote:
>
> > On Tue, May 25, 2021 at 04:48:21PM -0700, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2021-05-25 17:29:03 -0400, Bruce Momjian wrote:
> > > > So, let me ask --- I thought CTR basically took an encrypte
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > Another idea might be - instead of doing nonce++ every time we write
> > the page, do nonce=random(). That's eventually going to repeat a
> > value, but it's extremely likely to take a *super*
On Wed, May 26, 2021 at 2:37 PM Stephen Frost wrote:
> > Anybody got a better idea?
>
> If we stipulate (and document) that all replicas need their own keys
> then we no longer need to worry about nonce re-use between the primary
> and the replica. Not sure that's *better*, per se, but I do think
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> OK, that's what I thought. We already expose the clog and fsm, so
> exposing the hint bits seems acceptable. If everyone agrees, I will
> adjust my patch to not WAL log hint bit changes.
Robert pointed out that it's not just hint bits where
I wrote:
> I think this is about ready to commit now (though I didn't yet nuke
> GetDefaultToastCompression).
Here's a bundled-up final version, in case anybody would prefer
to review it that way.
regards, tom lane
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/ca
On Mon, May 24, 2021 at 7:21 PM Julien Rouhaud wrote:
>
> On Mon, May 24, 2021 at 11:03 PM Andrew Dunstan wrote:
> >
> > On 5/24/21 10:55 AM, Magnus Hagander wrote:
> > > On Mon, May 24, 2021 at 4:18 PM Andrew Dunstan
> > > wrote:
> > >>
> > >> On 5/24/21 8:42 AM, Daniel Gustafsson wrote:
> > >
On Wed, May 26, 2021 at 01:56:38PM -0400, Robert Haas wrote:
> However, I believe that if we store the nonce in the page explicitly,
> as proposed here, rather trying to derive it from the LSN, then we
> don't need to worry about this kind of masking, which I think is
> better from both a security
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, May 26, 2021 at 2:37 PM Stephen Frost wrote:
> > > Anybody got a better idea?
> >
> > If we stipulate (and document) that all replicas need their own keys
> > then we no longer need to worry about nonce re-use between the primary
>
On Wed, May 26, 2021 at 03:49:43PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > OK, that's what I thought. We already expose the clog and fsm, so
> > exposing the hint bits seems acceptable. If everyone agrees, I will
> > adjust my patch to not WAL l
On Wed, May 26, 2021 at 04:40:48PM -0400, Bruce Momjian wrote:
> On Wed, May 26, 2021 at 01:56:38PM -0400, Robert Haas wrote:
> > However, I believe that if we store the nonce in the page explicitly,
> > as proposed here, rather trying to derive it from the LSN, then we
> > don't need to worry abou
On 2021-May-25, Yura Sokolov wrote:
> Tom Lane писал 2021-05-21 21:23:
> > Yura Sokolov writes:
> > > I propose to add PortalDrop at the 'if (completed)' branch of
> > > exec_execute_message.
> >
> > This violates our wire protocol specification, which
> > specifically says
> >
> > If succe
On Wed, May 26, 2021 at 01:56:38PM -0400, Robert Haas wrote:
> In the interest of not being viewed as too much of a naysayer, let me
> first reiterate that I am generally in favor of TDE going forward and
> am not looking to throw up unnecessary obstacles in the way of making
> that happen.
Rather
Alvaro Herrera writes:
> (I didn't add a Close Portal message to PQsendQueryInternal in pipeline
> mode precisely because there is no such message in PQsendQueryGuts.
> I think it would be wrong to unconditionally add a Close Portal message
> to any of those places.)
Yeah, I'm not very comfortabl
The attached patch makes an optimization to pg_checksums which prevents
rewriting the block if the checksum is already what we expect. This can
lead to much faster runs in cases where it is already set (e.g. enabled ->
disabled -> enable, external helper process, interrupted runs, future
parallel p
On Tue, May 25, 2021 at 01:55:13PM +0300, Aleksander Alekseev wrote:
> Hi hackers,
>
> Back in 2016 while being at PostgresPro I developed the ZSON extension [1].
> The
> extension introduces the new ZSON type, which is 100% compatible with JSONB
> but
> uses a shared dictionary of strings most
On 2021-May-19, Bharath Rupireddy wrote:
> While working on [1], I found that some parts of the code is using
> strtol and atoi without checking for non-numeric junk input strings. I
> found this strange. Most of the time users provide proper numeric
> strings but there can be some scenarios where
The attached patch stems from the conversation at [1];
I'm starting a new thread to avoid confusing the cfbot.
Briefly, the idea is to allow reverting the change made in
commit ab596105b to increase FirstBootstrapObjectId from
12000 to 13000, by teaching genbki.pl to assign OIDs
independently in e
On 2021-May-26, Tom Lane wrote:
> I wrote:
> > I think this is about ready to commit now (though I didn't yet nuke
> > GetDefaultToastCompression).
>
> Here's a bundled-up final version, in case anybody would prefer
> to review it that way.
Looks good to me.
I tested the behavior with partition
Alvaro Herrera writes:
> Looks good to me.
> I tested the behavior with partitioned tables and it seems OK.
Thanks for reviewing/testing!
> It would be good to have a test case in src/bin/pg_dump/t/002_pg_dump.pl
> for the case
Personally I won't touch 002_pg_dump.pl with a 10-foot pole, but if
Hi,
On 2021-05-26 07:14:47 +0200, Antonin Houska wrote:
> Bruce Momjian wrote:
> > On Tue, May 25, 2021 at 04:48:21PM -0700, Andres Freund wrote:
> > My point was about whether we need to change the nonce, and hence
> > WAL-log full page images if we change hint bits. If we don't and
> > reencry
On 2021-May-26, Tom Lane wrote:
> Alvaro Herrera writes:
> > It would be good to have a test case in src/bin/pg_dump/t/002_pg_dump.pl
> > for the case
>
> Personally I won't touch 002_pg_dump.pl with a 10-foot pole, but if
> somebody else wants to, have at it.
Nod.
> > ... and I find it odd t
Hi,
On 2021-05-25 22:23:46 -0400, Stephen Frost wrote:
> Andres mentioned other possible cases where the LSN doesn’t change even
> though we change the page and, as he’s probably right, we would have to
> figure out a solution in those cases too (potentially including cases like
> crash recovery o
Hi,
On 2021-05-25 17:12:05 -0400, Bruce Momjian wrote:
> If we used a block cipher instead of a streaming one (CTR), this might
> not work because the earlier blocks can be based in the output of
> later blocks.
What made us choose CTR for WAL & data file encryption? I checked the
README in the p
On Wed, May 26, 2021 at 07:44:03PM -0400, Alvaro Herrera wrote:
> On 2021-May-26, Tom Lane wrote:
>> Personally I won't touch 002_pg_dump.pl with a 10-foot pole, but if
>> somebody else wants to, have at it.
>
> Nod.
Yeah, having an extra test for partitioned tables would be a good
idea.
>> Hm,
Michael Paquier writes:
> Yeah, having an extra test for partitioned tables would be a good
> idea.
We do have some coverage already via the pg_upgrade test.
> Could it be possible to have some tests for COMPRESSION DEFAULT? It
> seems to me that this should be documented as a supported keyword
Hi,
On 2021-05-25 14:46:27 +0900, Michael Paquier wrote:
> That would work. Your suggestion, as I understood it first, makes the
> code simpler by not using tup_values at all as the set of values[] is
> filled when the values and nulls are extracted. So I have gone with
> this simplification, an
Andres Freund writes:
> The efficiency bit is probably going to be swamped by the addition of
> the compression handling, given the amount of additional work we're now
> doing in in reform_and_rewrite_tuple().
Only if the user has explicitly requested a change of compression, no?
At Wed, 26 May 2021 22:08:32 +0530, Dilip Kumar wrote
in
> On Wed, 26 May 2021 at 10:06 PM, Robert Haas wrote:
>
> > On Wed, May 26, 2021 at 12:26 PM Dilip Kumar
> > wrote:
> > > I will check if there is any timing dependency in the test case.
> >
> > There is. I explained it in the second pa
On Wed, May 26, 2021 at 08:35:46PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > The efficiency bit is probably going to be swamped by the addition of
> > the compression handling, given the amount of additional work we're now
> > doing in in reform_and_rewrite_tuple().
>
> Only if the user
On Wed, May 26, 2021 10:13 PM Ajin Cherian wrote:
>
> I've attached a patch that fixes this issue. Do test and confirm.
>
Thanks for your patch.
I have tested and confirmed that the issue I reported has been fixed.
Regards
Tang
On Thu, May 27, 2021 at 5:24 AM Greg Sabino Mullane wrote:
>
> The attached patch makes an optimization to pg_checksums which prevents
> rewriting the block if the checksum is already what we expect. This can lead
> to much faster runs in cases where it is already set (e.g. enabled ->
> disable
From: Bharath Rupireddy
Sent: Wednesday, May 26, 2021 7:22 PM
> Thanks for trying that out.
>
> Please see the code around the use_fsm flag in RelationGetBufferForTuple for
> more understanding of the points below.
>
> What happens if FSM is skipped i.e. myState->ti_options =
> TABLE_INSERT_SKIP
Hi,
On 2021-05-26 20:35:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The efficiency bit is probably going to be swamped by the addition of
> > the compression handling, given the amount of additional work we're now
> > doing in in reform_and_rewrite_tuple().
>
> Only if the user has exp
On Wed, May 26, 2021 at 06:54:15PM -0700, Andres Freund wrote:
> Oh, it'll definitely be more expensive in that case - but that seems
> fair game. What I was wondering about was whether VACUUM FULL would be
> measurably slower, because we'll now call toast_get_compression_id() on
> each varlena dat
Hi,
On 2021-05-26 18:54:15 -0700, Andres Freund wrote:
> On 2021-05-26 20:35:46 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > The efficiency bit is probably going to be swamped by the addition of
> > > the compression handling, given the amount of additional work we're now
> > > doing in
On 5/26/21 5:29 PM, Bruce Momjian wrote:
> On Tue, May 25, 2021 at 01:55:13PM +0300, Aleksander Alekseev wrote:
>> Hi hackers,
>>
>> Back in 2016 while being at PostgresPro I developed the ZSON extension [1].
>> The
>> extension introduces the new ZSON type, which is 100% compatible with JSONB
On Wed, May 26, 2021 at 05:23:55PM -0400, Greg Sabino Mullane wrote:
> The attached patch makes an optimization to pg_checksums which prevents
> rewriting the block if the checksum is already what we expect. This can
> lead to much faster runs in cases where it is already set (e.g. enabled ->
> dis
Thank you for the detailed analysis, I'll look into it too. (The times have
changed...)
From: Bharath Rupireddy
> Well, one might think to add more blocks at a time, say
> Min(1024, lockWaiters * 128/256/512) than currently extraBlocks =
> Min(512, lockWaiters * 20);. This will work (i.e. we do
Hi,
On 2021-05-27 11:07:53 +0900, Michael Paquier wrote:
> This depends on the number of attributes, but I do see an extra 0.5%
> __memmove_avx_unaligned_erms in reform_and_rewrite_tuple() for a
> normal VACUUM FULL with a 1-int-column relation on a perf profile,
> with rewrite_heap_tuple eating m
In one of the checksum patches, there was an understanding that the pages
should be written even if the checksum is correct, to handle replicas.
>From the v19 patch:
https://www.postgresql.org/message-id/F7AFCFCD-8F77-4546-8D42-C7F675A4B680%40yesql.se
+* Mark the buffer as dirty an
Hi,
On 2021-05-24 15:47:48 +0900, Michael Paquier wrote:
> dc7420c2 has removed RecentGlobalXmin, but there are still references
> to it in the code, and a set of FIXME references, like this one in
> autovacuum.c (three in total):
> /*
> * Start a transaction so we can access pg_database, and get
On Thu, May 27, 2021 at 11:20 AM tanghy.f...@fujitsu.com
wrote:
>
> On Wed, May 26, 2021 10:13 PM Ajin Cherian wrote:
> >
> > I've attached a patch that fixes this issue. Do test and confirm.
> >
>
> Thanks for your patch.
> I have tested and confirmed that the issue I reported has been fixed.
T
Andres Freund writes:
> That's not *too* bad, but also not nothing
The memsets seem to be easy to get rid of. memset the array
to zeroes *once* before entering the per-tuple loop. Then,
in the loop that looks for stuff to pfree, reset any entries
that are found to be set, thereby returning
Hi amit-san
From: Amit Langote
Sent: Wednesday, May 26, 2021 9:38 AM
>
> Hou-san,
>
> On Wed, May 26, 2021 at 10:05 AM houzj.f...@fujitsu.com
> wrote:
> >
> > Thanks for the explanation !
> > Yeah, we can get all the parent table info from PartitionTupleRouting when
> INSERT into a partitioned
On Wed, Mar 24, 2021 at 10:34 PM Ashutosh Bapat
wrote:
> Hi All,
> We saw OOM in a system where WAL sender consumed Gigabttes of memory
> which was never released. Upon investigation, we found out that there
> were many ReorderBufferToastHash memory contexts linked to
> ReorderBuffer context, toge
From: Bharath Rupireddy
Sent: Wednesday, May 26, 2021 9:56 PM
> On Wed, May 26, 2021 at 6:36 PM Tomas Vondra
> wrote:
> >
> > On 5/26/21 8:57 AM, Bharath Rupireddy wrote:
> > > On Tue, May 25, 2021 at 2:47 PM Bharath Rupireddy
> > > wrote:
> > >>
> > >> On Tue, May 25, 2021 at 1:08 PM houzj.f...
Hi,
On 2021-05-26 22:43:42 -0400, Tom Lane wrote:
> The memsets seem to be easy to get rid of. memset the array
> to zeroes *once* before entering the per-tuple loop. Then,
> in the loop that looks for stuff to pfree, reset any entries
> that are found to be set, thereby returning the array to a
On Thu, Mar 25, 2021 at 11:04 AM Ashutosh Bapat
wrote:
>
> Hi All,
> We saw OOM in a system where WAL sender consumed Gigabttes of memory
> which was never released. Upon investigation, we found out that there
> were many ReorderBufferToastHash memory contexts linked to
> ReorderBuffer context, to
On Thu, May 27, 2021 at 8:27 AM Peter Geoghegan wrote:
>
> On Wed, Mar 24, 2021 at 10:34 PM Ashutosh Bapat
> wrote:
> > Hi All,
> > We saw OOM in a system where WAL sender consumed Gigabttes of memory
> > which was never released. Upon investigation, we found out that there
> > were many ReorderB
Andres Freund writes:
> Yea, I tested that - it does help in the integer case. But the bigger
> contributors are the loop over the attributes, and especially the access
> to the datum's compression method. Particularly the latter seems hard to
> avoid.
So maybe we should just dump the promise tha
On Thu, May 27, 2021 at 7:12 AM houzj.f...@fujitsu.com
wrote:
> I followed your above test steps and the below configuration, but my test
> results are a little different from yours.
> I am not sure the exact reason, maybe because of the hardware..
>
> Test INSERT 1000 rows((2 bigint(of 8 byt
1 - 100 of 132 matches
Mail list logo
