On Wed, May 19, 2021 at 3:08 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-05-18 11:20:07 +0900, Masahiko Sawada wrote:
> > Yes. It depends on how much the matview refresh gets slower but I
> > think the problem here is that users always are forced to pay the cost
>
On Tue, May 18, 2021 at 11:07 PM Bruce Momjian wrote:
>
> On Tue, May 18, 2021 at 06:28:49PM +0900, Masahiko Sawada wrote:
> > On Mon, May 10, 2021 at 3:03 PM Bruce Momjian wrote:
> > >
> > > I have committed the first draft of the PG 14 release notes. You can
>
h we will need a way for index
AMs to consider and tell the vacuum strategy. But I guess this works
well in most cases so having an on/off switch suffice.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
n the release note that
vacuum_cleanup_index_scale_factor GUC parameter has been removed and
vacuum_cleanup_index_scale_factor storage parameter has been
deprecated (please refer to commit 9f3665fb and effdd3f3b63).
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Tue, May 18, 2021 at 2:46 PM Masahiko Sawada wrote:
>
> On Tue, May 18, 2021 at 2:42 PM Peter Geoghegan wrote:
> >
> > On Mon, May 17, 2021 at 10:29 PM Masahiko Sawada
> > wrote:
> > > +1 to fix this. Are you already working on fixing this? If not, I'll
>
On Tue, May 18, 2021 at 2:42 PM Peter Geoghegan wrote:
>
> On Mon, May 17, 2021 at 10:29 PM Masahiko Sawada
> wrote:
> > +1 to fix this. Are you already working on fixing this? If not, I'll
> > post a patch.
>
> I posted a patch recently (last Thursday my time). Per
bout this question some more, though.
FWIW, I intentionally ignored the reloption there since they're
interpreted as lower than the GUC as you mentioned and the situation
where we need to enter the failsafe mode is not the table-specific
problem but a system-wide problem.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Wed, May 12, 2021 at 2:32 AM Tomas Vondra
wrote:
>
>
>
> On 5/11/21 5:56 PM, Masahiko Sawada wrote:
> > On Tue, May 11, 2021 at 11:07 PM Tomas Vondra
> > wrote:
> >>
> >> On 5/11/21 11:04 AM, Masahiko Sawada wrote:
> >>> On Tue,
have autovacuum work items ignore the work item
if the same work item with the same arguments is already registered.
In addition to that, I think we should avoid the work item for
cleaning the pending list from being executed if an autovacuum runs on
the gin index before executing the work item.
Re
nd if the user specifies an invalid number to the option we
say "parallel vacuum degree must be between 0 and %d”. We use the
message something like “AAA must be between X and Y” also in other
places if users input an invalid value. I'm not sure the consistency
is important here but another idea to improve the error message would
be to change "parallel vacuum degree must be between 0 and %d” to "the
number of parallel workers must be between 0 and %d” (or using
“parallel workers for vacuum” instead of “the number of parallel
workers”) while leaving another message as it is.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Wed, May 12, 2021 at 1:19 PM vignesh C wrote:
>
> On Wed, May 12, 2021 at 9:08 AM Amit Kapila wrote:
> >
> > On Wed, May 12, 2021 at 7:53 AM Amit Kapila wrote:
> > >
> > > On Wed, May 12, 2021 at 4:00 AM Masahiko Sawada
> > > wrote:
> >
and
stream_bytes/txns before reporting slot stats.
I've attached a patch to fix it.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
diff --git a/contrib/test_decoding/expected/stats.out b/contrib/test_decoding/expected/stats.out
index 7d174ee8d2..19bbd76c10 100644
--- a/contrib/t
On Tue, May 11, 2021 at 11:07 PM Tomas Vondra
wrote:
>
> On 5/11/21 11:04 AM, Masahiko Sawada wrote:
> > On Tue, May 11, 2021 at 4:37 PM Michael Paquier wrote:
> >>
> >> On Wed, May 05, 2021 at 03:04:53PM +0200, Tomas Vondra wrote:
> >>> Thanks, that l
so we might need to
consider another approach like having matview refresh use
heap_multi_insert() instead of heap_insert().
I think the changes for heap_multi_insert() are fine so we can revert
only heap_insert() part if we revert something from the v14 tree,
although we will end up not inserti
_stat_replication_slots view will contain one row
per logical replication slot, showing statistics about its usage.". So
we can say "... to report replication slot statistics about its
usage".
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
For (1), there is an idea of having OIDs for each slot to avoid the
accumulation of stats but that doesn't seem worth doing as in practice
this won't happen frequently. For (2), there are some ideas of
reporting slot stats at releasing slot (by keeping stats in
ReplicationSlot or by using callback) but we decided to go with
reporting slot stats after every stream/spill. Because it covers most
cases in practice and is much simpler than other approaches.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
;,
vacrel->relname, blkno);
visibilitymap_clear(vacrel->rel, blkno, vmbuffer,
VISIBILITYMAP_VALID_BITS);
}
I've attached a patch removing the assertion.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
diff -
On Thu, May 6, 2021 at 7:19 PM Robert Haas wrote:
>
> On Thu, May 6, 2021 at 5:02 AM Masahiko Sawada wrote:
> > Not sure we will need to hold buffer locks for both the TID fork and
> > the heap at the same time but I agree that we could need to lock on
> > multiple TI
On Thu, May 6, 2021 at 3:38 PM Dilip Kumar wrote:
>
> On Thu, May 6, 2021 at 8:27 AM Masahiko Sawada wrote:
> >
> > > I'm doubtful about skipping WAL logging entirely - I'd have to think
> > > harder about it, but I think that'd mean we'd restart from scratch a
On Thu, May 6, 2021 at 5:28 PM Amit Kapila wrote:
>
> On Thu, May 6, 2021 at 1:30 PM Masahiko Sawada wrote:
> >
> > All issues pointed out in this thread are resolved and we can remove
> > this item from the open items?
> >
>
> I think so. Do you think we sho
On Thu, May 6, 2021 at 4:03 PM Amit Kapila wrote:
>
> On Thu, May 6, 2021 at 10:55 AM Masahiko Sawada wrote:
> >
> > On Thu, May 6, 2021 at 1:09 PM Amit Kapila wrote:
> > >
> >
> > > In the attached, I have combined
> > > Vignesh's patch a
On Thu, May 6, 2021 at 1:09 PM Amit Kapila wrote:
>
> On Thu, May 6, 2021 at 6:15 AM Masahiko Sawada wrote:
> >
> > After more thought, I'm concerned that my patch's approach might be
> > invasive for PG14. Given that Vignesh’s patch would cover most cases,
> >
&
On Mon, May 3, 2021 at 9:18 PM Masahiko Sawada wrote:
>
> On Mon, May 3, 2021 at 2:27 PM Amit Kapila wrote:
>
> > Apart from this, I think you
> > have suggested somewhere in this thread to slightly update the
> > description of stream_bytes. I would lik
lication issues you mention.
Yeah, not having WAL would have a big negative impact on other various
aspects. Can we piggyback the WAL for the TID fork and
XLOG_HEAP2_PRUNE? That is, we add the buffer for the TID fork to
XLOG_HEAP2_PRUNE and record one 64-bit number of the first dead TID in
the list so that we can add dead TIDs to the TID fork during replaying
XLOG_HEAP2_PRUNE.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Tue, May 4, 2021 at 2:34 PM vignesh C wrote:
>
> On Tue, May 4, 2021 at 9:48 AM Masahiko Sawada wrote:
> >
> > On Mon, May 3, 2021 at 10:21 PM Amit Kapila wrote:
> > >
> > > On Mon, May 3, 2021 at 5:48 PM Masahiko Sawada
> > > wrote:
> &
On Mon, May 3, 2021 at 10:21 PM Amit Kapila wrote:
>
> On Mon, May 3, 2021 at 5:48 PM Masahiko Sawada wrote:
> >
> > On Mon, May 3, 2021 at 2:27 PM Amit Kapila wrote:
> > >
> > > On Thu, Apr 29, 2021 at 10:37 AM Amit Kapila
> > > wrote:
> > &
On Sun, May 2, 2021 at 1:23 AM Zhihong Yu wrote:
>
>
>
> On Fri, Apr 30, 2021 at 9:09 PM Masahiko Sawada wrote:
>>
>> On Wed, Mar 17, 2021 at 6:03 PM Zhihong Yu wrote:
>> >
>> > Hi,
>> > For v35-0007-Prepare-foreign-transactions-at-commit-t
On Mon, May 3, 2021 at 2:29 PM Amit Kapila wrote:
>
> On Fri, Apr 30, 2021 at 1:47 PM Amit Kapila wrote:
> >
> > LGTM. I have slightly edited the comments in the attached. I'll push
> > this early next week unless there are more comments.
> >
>
> Pushed.
On Mon, May 3, 2021 at 2:27 PM Amit Kapila wrote:
>
> On Thu, Apr 29, 2021 at 10:37 AM Amit Kapila wrote:
> >
> > On Wed, Apr 28, 2021 at 7:43 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Apr 28, 2021 at 3:25 PM Amit Kapila
> > >
I think If we process one 2pc-non-capable server first and then
process another one 2pc-capable server, we should raise an error but
cannot detect that.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Tue, Apr 27, 2021 at 10:03 AM Masahiro Ikeda
wrote:
>
>
>
> On 2021/03/17 12:03, Masahiko Sawada wrote:
> > I've attached the updated version patch set.
>
> Thanks for updating the patches! I'm now restarting to review of 2PC because
> I'd like to use this
On Thu, Apr 29, 2021 at 9:44 PM vignesh C wrote:
>
>
>
> On Thu, Apr 29, 2021 at 3:06 PM Amit Kapila wrote:
> >
> > On Wed, Apr 28, 2021 at 5:01 PM Amit Kapila wrote:
> > >
> > > On Wed, Apr 28, 2021 at 4:51 PM Masahiko Sawada
> > > wrote:
&
On Thu, Apr 29, 2021 at 11:55 AM Amit Kapila wrote:
>
> On Thu, Apr 29, 2021 at 4:58 AM Masahiko Sawada wrote:
> >
> > On Thu, Apr 29, 2021 at 5:41 AM Tom Lane wrote:
> > >
> > > It seems that the test case added by f5fc2f5b2 is still a bit
> > > u
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Wed, Apr 28, 2021 at 3:25 PM Amit Kapila wrote:
>
> On Wed, Apr 28, 2021 at 9:37 AM Masahiko Sawada wrote:
> >
> > On Wed, Apr 28, 2021 at 12:29 PM Amit Kapila
> > wrote:
> > >
> > > On Tue, Apr 27, 2021 at 11:02 AM vignesh C wrote:
> > >
On Wed, Apr 28, 2021 at 6:39 PM Amit Kapila wrote:
>
> On Wed, Apr 28, 2021 at 12:49 PM Masahiko Sawada
> wrote:
> >
> >
> > BTW regarding the commit f5fc2f5b23 that added total_txns and
> > total_bytes, we add the reorder buffer size (i.g., rb->size) to
>
On Fri, Apr 16, 2021 at 2:58 PM Amit Kapila wrote:
>
> On Thu, Apr 15, 2021 at 4:35 PM Masahiko Sawada wrote:
> >
> > Thank you for the update! The patch looks good to me.
> >
BTW regarding the commit f5fc2f5b23 that added total_txns and
total_bytes, we add the reord
;private_data points to LogicalDecodingContext. See
> StartupDecodingContext.
+1
With this approach, we could still miss the totalTxns and totalBytes
updates if the decoding a large but less than
logical_decoding_work_mem is interrupted, right?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Wed, Apr 28, 2021 at 12:26 AM Masahiko Sawada wrote:
>
> On Tue, Apr 27, 2021 at 10:43 PM Tomas Vondra
> wrote:
> >
> >
> >
> > On 4/27/21 7:34 AM, Masahiko Sawada wrote:
> > > On Tue, Apr 27, 2021 at 8:07 AM Andres Freund wrote:
> > >>
On Tue, Apr 27, 2021 at 10:43 PM Tomas Vondra
wrote:
>
>
>
> On 4/27/21 7:34 AM, Masahiko Sawada wrote:
> > On Tue, Apr 27, 2021 at 8:07 AM Andres Freund wrote:
> >>
> >> Hi,
> >>
> >> On 2021-04-26 23:59:17 +0200, Tomas Vondra wrote:
> &g
On Tue, Apr 27, 2021 at 11:29 PM Amit Kapila wrote:
>
> On Tue, Apr 27, 2021 at 5:40 PM Amit Kapila wrote:
> >
> > On Tue, Apr 27, 2021 at 8:58 AM Masahiko Sawada
> > wrote:
> >
> > I have pushed this patch and seeing one buildfarm failure:
> >
vely influence other (more)
> > common use cases, so I guess we can't just keep the current code ...
>
> I'd suggest prototyping the use of BulkInsertState in nodeModifyTable.c
> and see whether that fixes the regression.
Is this idea to have RelationGetBufferForTuple() skip re-pinning
vmbuffer? If so, is this essentially the same as the one in the v3
patch?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Tue, Apr 27, 2021 at 1:18 PM vignesh C wrote:
>
> On Tue, Apr 27, 2021 at 9:43 AM Amit Kapila wrote:
> >
> > On Tue, Apr 27, 2021 at 9:17 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Apr 27, 2021 at 11:31 AM vignesh C wrote:
> > >
On Tue, Apr 27, 2021 at 11:31 AM vignesh C wrote:
>
> On Mon, Apr 26, 2021 at 8:42 AM Amit Kapila wrote:
> >
> > On Mon, Apr 26, 2021 at 8:01 AM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, Apr 23, 2021 at 6:15 PM Amit Kapila
> > > wro
On Tue, Apr 27, 2021 at 11:45 AM Amit Kapila wrote:
>
> On Tue, Apr 27, 2021 at 8:01 AM vignesh C wrote:
> >
> > On Mon, Apr 26, 2021 at 8:42 AM Amit Kapila wrote:
> > >
> > > On Mon, Apr 26, 2021 at 8:01 AM Masahiko Sawada
> > > wrote:
> &g
uples depending on hardware. But it might
not be as fast as before commit 39b66a91b since we read vmbuffer at
least per insertion.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
ts there and make them
persistent without using the stats collector? And I think there is
also a risk to increase shared memory when we want to add other
statistics in the future.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Sat, Apr 24, 2021 at 12:22 AM Robert Haas wrote:
>
> On Fri, Apr 23, 2021 at 7:04 AM Masahiko Sawada wrote:
> > I think we can divide the TID fork into 16MB or 32MB chunks like WAL
> > segment files so that we can easily remove old chunks. Regarding the
> > efficient
On Fri, Apr 23, 2021 at 3:47 AM Robert Haas wrote:
>
> On Thu, Apr 22, 2021 at 10:28 AM Masahiko Sawada
> wrote:
> > The dead TID fork needs to also be efficiently searched. If the heap
> > scan runs twice, the collected dead TIDs on each heap pass could be
> &g
ome other things too like considering truncation that aren't relevant
> > to the point I want to make here. Now, the problem with this is that
> > every index has its own needs, which are separate from the needs of
> > the tables, as I think Peter Geoghegan and Masahiko Sawada were a
On Thu, Apr 22, 2021 at 3:03 PM Amit Kapila wrote:
>
> On Thu, Apr 22, 2021 at 10:39 AM Masahiko Sawada
> wrote:
> >
> > On Thu, Apr 22, 2021 at 1:50 PM Amit Kapila wrote:
> > >
> > > On Thu, Apr 22, 2021 at 8:26 AM Masahiko Sa
On Thu, Apr 22, 2021 at 1:50 PM Amit Kapila wrote:
>
> On Thu, Apr 22, 2021 at 8:26 AM Masahiko Sawada wrote:
> >
>
> Few comments:
> 1.
> I think we want stats collector to not use pgStatLocalContext unless
> it has read the stats file similar to other cases. So pro
On Wed, Apr 21, 2021 at 7:11 PM Amit Kapila wrote:
>
> On Wed, Apr 21, 2021 at 3:39 PM Masahiko Sawada wrote:
> >
> > >
> > > The test is not waiting for a new slot creation message to reach the
> > > stats collector. So, if the old slot data still exists
On Wed, Apr 21, 2021 at 4:44 PM Dilip Kumar wrote:
>
> On Tue, Apr 20, 2021 at 7:54 PM Masahiko Sawada wrote:
>
> >
> > I've attached the patch. In addition to the test Vignesh prepared, I
> > added one test for the message for creating a slot that checks if the
>
On Wed, Apr 21, 2021 at 6:36 PM Amit Kapila wrote:
>
> On Wed, Apr 21, 2021 at 2:46 PM Masahiko Sawada wrote:
> >
> > On Wed, Apr 21, 2021 at 3:09 PM Amit Kapila wrote:
> > >
> > > On Tue, Apr 20, 2021 at 7:54 PM Masahiko Sawada
> > > wrote:
&g
On Wed, Apr 21, 2021 at 6:20 PM Amit Kapila wrote:
>
> On Wed, Apr 21, 2021 at 2:37 PM Masahiko Sawada wrote:
> >
> > On Wed, Apr 21, 2021 at 12:50 PM Amit Kapila
> > wrote:
> > >
> > > On Tue, Apr 20, 2021 at 7:54 PM Masahiko Sawada
> >
On Wed, Apr 21, 2021 at 3:09 PM Amit Kapila wrote:
>
> On Tue, Apr 20, 2021 at 7:54 PM Masahiko Sawada wrote:
> >
> >
> > I've attached the patch. In addition to the test Vignesh prepared, I
> > added one test for the message for creating a slot that checks if the
On Wed, Apr 21, 2021 at 12:50 PM Amit Kapila wrote:
>
> On Tue, Apr 20, 2021 at 7:54 PM Masahiko Sawada wrote:
> >
>
> I have one question:
>
> + /*
> + * Create the replication slot stats hash table if we don't have
> + * it already.
> +
On Tue, Apr 20, 2021 at 7:22 PM vignesh C wrote:
>
> On Tue, Apr 20, 2021 at 9:08 AM Masahiko Sawada wrote:
> >
> > On Mon, Apr 19, 2021 at 4:48 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Apr 19, 2021 at 2:14 PM Amit Kapila
> > > wro
On Tue, Apr 20, 2021 at 6:59 PM Amit Kapila wrote:
>
> On Tue, Apr 20, 2021 at 9:08 AM Masahiko Sawada wrote:
> >
> > I've attached the new version patch that fixed the compilation error
> > reported off-line by Amit.
> >
>
> I was thinking about whether
On Tue, Apr 20, 2021 at 11:04 AM Bharath Rupireddy
wrote:
>
> On Mon, Apr 19, 2021 at 7:21 PM Masahiko Sawada wrote:
> > I’ve updated the patch including the above comment.
>
> Thanks for the patch.
>
> I was trying to understand below statements:
> +
On Mon, Apr 19, 2021 at 4:48 PM Masahiko Sawada wrote:
>
> On Mon, Apr 19, 2021 at 2:14 PM Amit Kapila wrote:
> >
> > On Mon, Apr 19, 2021 at 9:00 AM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, Apr 16, 2021 at 2:58 PM Amit Kapila
> > >
On Mon, Apr 19, 2021 at 8:04 PM Bharath Rupireddy
wrote:
>
> On Mon, Apr 19, 2021 at 1:57 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 19, 2021 at 5:04 PM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Mon, 19 Apr 2021 13:32:31 +0900, Masahiko Sawada
&g
On Mon, Apr 19, 2021 at 5:04 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 19 Apr 2021 13:32:31 +0900, Masahiko Sawada
> wrote in
> > On Fri, Apr 16, 2021 at 12:16 PM Kyotaro Horiguchi
> > wrote:
> > > AFAICS the page is always empty when RelationGetBufferForTuple
&
On Mon, Apr 19, 2021 at 2:14 PM Amit Kapila wrote:
>
> On Mon, Apr 19, 2021 at 9:00 AM Masahiko Sawada wrote:
> >
> > On Fri, Apr 16, 2021 at 2:58 PM Amit Kapila wrote:
> > >
> > >
> > > 4.
> > > +CREATE VIEW pg_stat_replication_slo
On Fri, Apr 16, 2021 at 12:16 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 12 Apr 2021 15:20:41 +0900, Masahiko Sawada
> wrote in
> > .
> >
> > On Thu, Mar 11, 2021 at 5:44 PM Masahiko Sawada
> > wrote:
> > >
> > > Hi,
> > >
>
On Fri, Apr 16, 2021 at 2:58 PM Amit Kapila wrote:
>
> On Thu, Apr 15, 2021 at 4:35 PM Masahiko Sawada wrote:
> >
> > Thank you for the update! The patch looks good to me.
> >
>
> I have pushed the first patch. Comments on the next patch
> v13-0001-Use-HTAB-for
= 0 AS
spill_count, total_txns > 0 AS total_txns, total_bytes > 0 AS
total_bytes FROM pg_stat_replication_slots;
slot_name| spill_txns | spill_count | total_txns | total_bytes
-++-+----+-
regression_slot | f | f | t | t
(1 row)
We should expect all values are 0. Please find attached the patch.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
fix_test_decoding_test.patch
Description: Binary data
On Thu, Apr 15, 2021 at 6:16 PM Amit Kapila wrote:
>
> On Thu, Apr 15, 2021 at 1:13 PM Masahiko Sawada wrote:
> >
> > On Thu, Apr 15, 2021 at 3:22 PM Amit Kapila wrote:
> > >
> > Thank you for updating the patch.
> >
> > I have one question on th
“streamed and spilled”? Even if it actually means “and or”,
using "and or” (i.g., connecting “and” to “or” by a space) is general?
I could not find we use it other places in the doc but found we're
using "and/or" instead.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
heapam_scan_analyze_next_tuple() not count LP_DEAD
line pointer as lazy_scan_prune() does. Attached the patch for that.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
not_count_lp_dead_by_analyze.patch
Description: Binary data
On Tue, Apr 13, 2021 at 5:07 PM vignesh C wrote:
>
> On Mon, Apr 12, 2021 at 7:03 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 12, 2021 at 9:36 PM Amit Kapila wrote:
> > >
> > > On Mon, Apr 12, 2021 at 5:29 PM Masahiko Sawada
> > > wrote:
> &g
On Wed, Apr 14, 2021 at 4:59 AM Peter Geoghegan wrote:
>
> On Mon, Apr 12, 2021 at 11:05 PM Masahiko Sawada
> wrote:
> > I realized that when the failsafe is triggered, we don't bypass heap
> > truncation that is performed before updating relfrozenxid. I think
> > i
track the oldest xid per page in a map like visiblity map
or integrate it with visibility map. We need to freeze only pages that
are all-visible and whose oldest xid is older than the cut-off xid. I
think we need to track both xid and multi xid.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Thu, Apr 8, 2021 at 11:42 AM Masahiko Sawada wrote:
>
> On Thu, Apr 8, 2021 at 8:41 AM Peter Geoghegan wrote:
> >
> > On Wed, Apr 7, 2021 at 8:52 AM Peter Geoghegan wrote:
> > > All of the changes from your fixup patch are clear improvements, and
> > &g
# Test to remove one of the replication slots and adjust max_replication_slots
+# accordingly to the number of slots and verify replication statistics data is
+# fine after restart.
I think it's better if we explain in detail what cases we're trying to
test. How about the following description?
Test to remove one of the replication slots and adjust
max_replication_slots accordingly to the number of slots. This leads
to a mismatch of the number of slots between in the stats file and on
shared memory, simulating the message for dropping a slot got lost. We
verify replication statistics data is fine after restart.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
safe is triggered, cost-based delay is no longer
be applied, and index vacuuming is bypassed in order to finish vacuum
work and advance relfrozenxid as quickly as possible.
Regards
[1]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=1e55e7d1755cefbb44982fbacc7da461fa8684e6
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Mon, Apr 12, 2021 at 9:36 PM Amit Kapila wrote:
>
> On Mon, Apr 12, 2021 at 5:29 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 12, 2021 at 8:08 PM Amit Kapila wrote:
> > >
> > > On Mon, Apr 12, 2021 at 4:34 PM Masahiko Sawada
> > > wrote:
&g
On Mon, Apr 12, 2021 at 8:08 PM Amit Kapila wrote:
>
> On Mon, Apr 12, 2021 at 4:34 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 12, 2021 at 6:19 PM Amit Kapila wrote:
> > >
> > > On Mon, Apr 12, 2021 at 10:27 AM Masahiko Sawada
> > > wrote:
&g
On Mon, Apr 12, 2021 at 6:19 PM Amit Kapila wrote:
>
> On Mon, Apr 12, 2021 at 10:27 AM Masahiko Sawada
> wrote:
> >
> > On Sat, Apr 10, 2021 at 9:53 PM Amit Kapila wrote:
> > >
> > >
> > > It seems Vignesh has changed patches based on th
.
On Thu, Mar 11, 2021 at 5:44 PM Masahiko Sawada wrote:
>
> Hi,
>
> While discussing freezing tuples during CTAS[1], we found that
> heap_insert() with HEAP_INSERT_FROZEN brings performance degradation.
> For instance, with Paul's patch that sets HEAP_INSERT_FROZEN to CTAS
On Sat, Apr 10, 2021 at 9:53 PM Amit Kapila wrote:
>
> On Sat, Apr 10, 2021 at 7:24 AM Masahiko Sawada wrote:
> >
> > IIUC there are two problems in the case where the drop message is lost:
> >
> > 1. Writing beyond the end of replSlotStats.
> > This can h
t. To deal with this problem
I think we would need to use something unique identifier for each slot
instead of slot name.
[1]
https://www.postgresql.org/message-id/CALDaNm195xL1bZq4VHKt%3D-wmXJ5kC4jxKh7LXK%2BpN7ESFjHO%2Bw%40mail.gmail.com
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
0001-POC-Use-HTAB-for-replication-slot-stats.patch
Description: Binary data
On Thu, Apr 8, 2021 at 12:17 PM Amit Kapila wrote:
>
> On Wed, Apr 7, 2021 at 5:11 PM Masahiko Sawada wrote:
> >
> > On Wed, Apr 7, 2021 at 7:00 PM Amit Kapila wrote:
> > >
> > > During recent developments in the vacuum, it has been noticed [1] that
> &g
the GUCs to 1.6 billion, though.
Okay.
>
> All patches in the patch series have been pushed. Hopefully I will not
> be the next person to break the buildfarm today.
>
> Thanks Masahiko, and everybody else involved!
Thank you, too!
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
ies or ring buffer sizes for the leader and worker processes,
the former approach would be better. But I think we're unlikely to
want to do that, especially in back branches.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
econd pass is
called only when we found/made LP_DEAD on the page. That is, if all
dead tuples have been marked as LP_UNUSED by HOT pruning, the page
would not be processed by the second pass, resulting in not removing
LP_UNUSED at the end of line pointer array. So think we can call it in
this case, i.g.,
aint expressions,
* indexes and triggers.
*
* This is based on similar code in copy.c
*/
static EState *
create_estate_for_relation(LogicalRepRelMapEntry *rel)
It seems like the comments meant the code around CopyFrom() and
DoCopy() but it would no longer be true since copy.c has been split
into some files and I don't find similar code in copy.c. I think it’s
better to remove the sentence rather than update the file name as this
comment doesn’t really informative and hard to track the updates. What
do you think?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
s_opened_result_relations. It might be better to do
that in create_estate_for_relation() though. Please find an attached
patch.
Since this issue happens on only HEAD and it seems an oversight of
commit 1375422c, I don't think regression tests for this are
essential.
Regards,
--
Masahiko Sawada
EDB: https:
res 13 as well? At least for the
> > EXEC_BACKEND case, I think.
>
> Uh ... *what* propagation of global state to parallel workers? Workers
> fork off from the postmaster, not from their leader process.
Right. I think we should apply that fix on PG13 as well.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
;
SELECT pg_relation_size('vac_truncate_test') > 0;
VACUUM vac_truncate_test;
SELECT pg_relation_size('vac_truncate_test') = 0;
VACUUM (TRUNCATE FALSE, FULL TRUE) vac_truncate_test;
DROP TABLE vac_truncate_test;
Should we add FREEZE to those tests as well?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
, can we do should_speedup_failsafe() check also after
parallel index vacuuming? And we can also check it at the beginning of
lazy vacuum.
Regards,
[1]
https://www.postgresql.org/message-id/CAD21AoDOWo4H6vmtLZoJ2SznMp_zOej2Kww%2BJBkVRPXs%2Bj48uw%40mail.gmail.com
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Fri, Apr 2, 2021 at 4:28 PM Fujii Masao wrote:
>
>
>
> On 2021/04/02 15:02, Masahiko Sawada wrote:
> > Hi all,
> >
> > I found typos in verify_heapam.c.
> >
> > s/comitted/committed/
> >
> > Please find an attached patch.
>
> T
Hi all,
I found typos in verify_heapam.c.
s/comitted/committed/
Please find an attached patch.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
fix_typo.patch
Description: Binary data
cal decoding and allow tuning
logical_decoding_work_mem.
+
+
+
As I mentioned in another reply, I think users should not gauge the
network I/O which occurred during logical decoding using by those
counters since the actual amount of network I/O is affected by table
filtering and row filtering discussed on another thread[1]. Also,
since this is total bytes I'm not sure how users can use this value to
tune logical_decoding_work_mem. I agree to track both the total bytes
and the total number of transactions passed to the decoding plugin but
I think the description needs to be updated. How about the following
description for example?
Amount of decoded transaction data sent to the decoding output plugin
while decoding changes from WAL for this slot. This and total_txn for
this slot can be used to gauge the total amount of data during logical
decoding.
---
I think we can merge 0001 and 0003 patches.
[1]
https://www.postgresql.org/message-id/CAHE3wggb715X%2BmK_DitLXF25B%3DjE6xyNCH4YOwM860JR7HarGQ%40mail.gmail.com
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Fri, Apr 2, 2021 at 9:46 AM Michael Paquier wrote:
>
> On Thu, Apr 01, 2021 at 10:54:29PM +0900, Masahiko Sawada wrote:
> > Looks good to me too.
>
> Okay, applied and back-patched down to 12 then.
Thank you!
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Thu, Apr 1, 2021 at 5:49 PM Michael Paquier wrote:
>
> On Thu, Apr 01, 2021 at 10:58:25AM +0300, Arseny Sher wrote:
> > How about the attached?
Thank you for updating the patch!
> Sounds fine to me. Sawada-san?
Looks good to me too.
Regards,
--
Masahiko Saw
ich occurred during
logical decoding.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Thu, Apr 1, 2021 at 12:08 PM Arseny Sher wrote:
>
>
> Masahiko Sawada writes:
>
> >> I don't think this matters much, as it tests the contrary and the
> >> probability of
> >> successful test passing (in case of theoretical bug making vacuum to
> &g
On Wed, Mar 31, 2021 at 10:39 PM Arseny Sher wrote:
>
>
> On 3/31/21 4:17 PM, Masahiko Sawada wrote:
>
> > Is it better to add FREEZE to the first "VACUUM reloptions_test;" as
> well?
>
> I don't think this matters much, as it tests the contrary and the
>
1401 - 1500 of 2811 matches
Mail list logo
