On Thu, May 27, 2021 at 12:19 PM houzj.f...@fujitsu.com
wrote:
> BTW, I checked my test results, I was testing INSERT INTO unlogged table.
What do you mean by "testing INSERT INTO"? Is it that you are testing
the timings for parallel inserts in INSERT INTO ... SELECT command? If
so, why should we
From: Amit Langote
Sent: Thursday, May 27, 2021 1:54 PM
> On Thu, May 27, 2021 at 11:47 AM houzj.f...@fujitsu.com
> wrote:
> > About teaching relcache about caching the target partition.
> >
> > David-san suggested cache the partidx in PartitionDesc.
> > And it will need looping and checking the
On 5/8/21 2:00 AM, Hywel Carver wrote:
On Fri, May 7, 2021 at 8:23 AM Andrey Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
Here I didn't work on 'unnecessary IS NOT NULL filter'.
I've tested the new patch, and it is giving the same improved behaviour
as the old patch.
Thank you for t
From: Bharath Rupireddy
Sent: Thursday, May 27, 2021 12:46 PM
> On Thu, May 27, 2021 at 7:12 AM houzj.f...@fujitsu.com
> wrote:
> > I am afraid that the using the FSM seems not get a stable performance
> > gain(at least on my machine), I will take a deep look into this to
> > figure out the diffe
On Thu, 27 May 2021 at 11:32 AM, tsunakawa.ta...@fujitsu.com <
tsunakawa.ta...@fujitsu.com> wrote:
> From: Dilip Kumar
> > I think some other cause of contention on relation extension locks are
> > 1. CTAS is using a buffer strategy and due to that, it might need to
> > evict out the buffer frequ
At Thu, 27 May 2021 11:44:47 +0530, Dilip Kumar wrote
in
> Maybe we can somehow achieve that without a broken archive command,
> but I am not sure how it is enough to just delete WAL from pg_wal? I
> mean my original case was that
> 1. Got the new history file from the archive but did not get t
On Fri, May 21, 2021 at 1:12 PM Amit Langote wrote:
>
> Hmm, maybe get_rel_syn_entry() should explicitly set map to NULL when
> first initializing an entry. It's possible that without doing so, the
> map remains set to a garbage value, which causes the invalidation
> callback that runs into such
On Wed, May 26, 2021 at 6:11 PM Amit Kapila wrote:
>
> 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 cont
On Wed, May 26, 2021 at 9:40 PM Robert Haas wrote:
> ...which has a clear race condition.
> src/test/recovery/t/023_pitr_prepared_xact.pl has logic to wait for a
> WAL file to be archived, so maybe we can steal that logic and use it
> here.
Yeah, done that, I think we can use exact same logic fo
At Fri, 14 May 2021 10:04:57 -0400, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > I'm not sure how much we (or people) are strcit on the distinction
> > between the $SUBJECT, isn't '{' a brace generally?
>
> +1. I tend to write "square bracket" or "curly brace" when I want to
> be extra cl
On Thu, May 27, 2021 at 6:19 AM Kyotaro Horiguchi
wrote:
>
> 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 depend
From: Dilip Kumar
> I think some other cause of contention on relation extension locks are
> 1. CTAS is using a buffer strategy and due to that, it might need to
> evict out the buffer frequently for getting the new block in. Maybe
> we can identify by turning off the buffer strategy for CTAS and
On Wed, May 26, 2021 at 11:10:22AM +0900, Michael Paquier wrote:
> There is one point where you are right here: log_lock_waits has no
> need to be changed. Looks like I checked too many things at once.
Fixed that, did one extra round of review, and applied.
--
Michael
signature.asc
Description:
On Thu, May 27, 2021 at 11:47 AM houzj.f...@fujitsu.com
wrote:
> About teaching relcache about caching the target partition.
>
> David-san suggested cache the partidx in PartitionDesc.
> And it will need looping and checking the cached value at each level.
> I was thinking can we cache a partidx l
On Thu, May 27, 2021 at 9:56 AM Masahiko Sawada wrote:
>
> On Wed, May 26, 2021 at 3:43 PM Amit Kapila wrote:
> >
> > On Tue, May 25, 2021 at 12:26 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, May 24, 2021 at 7:51 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Mon, May 24, 2021 at 1:32 P
On Thu, May 27, 2021 at 1:55 PM Zhihong Yu wrote:
> For CanUseSavedPartitionForTuple, nit: you can check
> !dispatch->savedPartResultInfo at the beginning and return early.
> This would save some indentation.
Sure, see the attached.
--
Amit Langote
EDB: http://www.enterprisedb.com
v5-0002-Ex
On Thu, May 27, 2021 at 10:16 AM Bharath Rupireddy
wrote:
>
> On Thu, May 27, 2021 at 7:12 AM houzj.f...@fujitsu.com
> wrote:
> > I am afraid that the using the FSM seems not get a stable performance
> > gain(at least on my machine),
> > I will take a deep look into this to figure out the differ
On Wed, May 26, 2021 at 9:22 PM Amit Langote
wrote:
> Hi,
>
> On Thu, May 27, 2021 at 2:30 AM Zhihong Yu wrote:
> >>
> >> Hi, Amit:
> >
> >
> > For ConvertTupleToPartition() in
> 0001-ExecFindPartition-cache-last-used-partition-v3.patch:
> >
> > + if (tempslot != NULL)
> > + Exec
On Thu, May 27, 2021 at 7:12 AM houzj.f...@fujitsu.com
wrote:
> I am afraid that the using the FSM seems not get a stable performance gain(at
> least on my machine),
> I will take a deep look into this to figure out the difference. A naive idea
> it that the benefit that bulk extension
> bring i
On Thu, May 27, 2021 at 9:47 AM Amit Kapila wrote:
>
> On Thu, May 27, 2021 at 9:40 AM Dilip Kumar wrote:
>
> True, but if you do this clean-up in ReorderBufferCleanupTXN then you
> don't need to take care at separate places. Also, toast_hash is stored
> in txn so it appears natural to clean it u
Next version of the patch.
For searching any problems I forced this patch during 'make check'
tests. Some bugs were found and fixed.
--
regards,
Andrey Lepikhov
Postgres Professional
From 101614b504b0b17e201d2375c8af61cfc671e51d Mon Sep 17 00:00:00 2001
From: Andrey Lepikhov
Date: Fri, 2 Apr 2
On Wed, May 26, 2021 at 3:43 PM Amit Kapila wrote:
>
> On Tue, May 25, 2021 at 12:26 PM Masahiko Sawada
> wrote:
> >
> > On Mon, May 24, 2021 at 7:51 PM Amit Kapila wrote:
> > >
> > > On Mon, May 24, 2021 at 1:32 PM Masahiko Sawada
> > > wrote:
> > >
> > > I think you need to consider few mor
On Thu, May 27, 2021 at 9:43 AM Amit Kapila wrote:
> > I have read it but I think we should try to ensure practically what is
> > happening because it is possible that first time worker checked in FSM
> > without taking relation extension lock, it didn't find any free page,
> > and then when it tr
Hi,
On Thu, May 27, 2021 at 2:30 AM Zhihong Yu wrote:
>>
>> 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 sl
On Thu, May 27, 2021 at 9:40 AM Dilip Kumar wrote:
>
> On Thu, May 27, 2021 at 9:26 AM Amit Kapila wrote:
> >
> > >
> > > Can we consider the possibility to destroy the toast_hash in
> > > ReorderBufferCleanupTXN/ReorderBufferTruncateTXN? It will delay the
> > > clean up of memory till the end of
On Wed, May 26, 2021 at 09:29:43PM -0500, Justin Pryzby wrote:
> 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-8D4
On Wed, May 26, 2021 at 5:51 PM Amit Kapila wrote:
>
> 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
Michael Paquier writes:
> On Wed, May 26, 2021 at 11:34:53PM -0400, Tom Lane wrote:
>> So maybe we should just dump the promise that VACUUM FULL will recompress
>> everything? I'd be in favor of that actually, because it seems 100%
>> outside the charter of either VACUUM FULL or CLUSTER.
> Hmm.
On Thu, May 27, 2021 at 9:26 AM Amit Kapila wrote:
>
> On Thu, May 27, 2021 at 9:02 AM Amit Kapila wrote:
> >
> > 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 releas
On Thu, May 27, 2021 at 9:03 AM Amit Kapila wrote:
>
> 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 ReorderB
On Wed, May 26, 2021 at 11:34:53PM -0400, Tom Lane wrote:
> So maybe we should just dump the promise that VACUUM FULL will recompress
> everything? I'd be in favor of that actually, because it seems 100%
> outside the charter of either VACUUM FULL or CLUSTER.
Hmm. You are right that by default t
On Thu, May 27, 2021 at 9:02 AM Amit Kapila wrote:
>
> 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 ReorderB
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
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 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
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
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
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...
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
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
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
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
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
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-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
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
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
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
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 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 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
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
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
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 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
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
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?
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
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
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,
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
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
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-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
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
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
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-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
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
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
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
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
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 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 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
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 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
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:
> > >
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
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
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,
* 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 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
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
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
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
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).
>
> 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
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
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
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
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 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 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, 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 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 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
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 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
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
1 - 100 of 132 matches
Mail list logo
