On Wed, 16 Sep 2020 at 13:20, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> > > If so, can't we stipulate that the FDW implementor should ensure that the
> > commit function always returns control to the caller?
> >
> > How can the FDW impl
On Tue, 22 Sep 2020 at 10:17, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> > Yes, but it still seems hard to me that we require for all FDW
> > implementations to commit/rollback prepared transactions without the
> > possibility of ERROR.
>
> Of
On Thu, 24 Sep 2020 at 17:23, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> > So with your idea, I think we require FDW developers to not call
> > ereport(ERROR) as much as possible. If they need to use a function
> > including palloc, lappend etc that
On Fri, 25 Sep 2020 at 18:21, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> > I don't think it's always possible to avoid raising errors in advance.
> > Considering how postgres_fdw can implement your idea, I think
> > postgres_fdw would ne
On Mon, 28 Sep 2020 at 13:58, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> > On Fri, 25 Sep 2020 at 18:21, tsunakawa.ta...@fujitsu.com
> > wrote:
> > > Why does the client backend have to create a new connection cache entry
> > during PREPAR
in this command if there are
> children. This is new in PG13, so this change would have very limited
> impact in practice.
>
> Proposed patch attached.
+1
If we have ALTER TABLE ONLY / DROP EXPRESSION update the attlocal
column of children to true to fix the issue you raised, my proposed
On Tue, 29 Sep 2020 at 11:37, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> > No. Please imagine a case where a user executes PREPARE TRANSACTION on
> > the transaction that modified data on foreign servers. The backend
> > process prepares both the local
On Tue, 29 Sep 2020 at 15:03, Masahiko Sawada
wrote:
>
> On Tue, 29 Sep 2020 at 11:37, tsunakawa.ta...@fujitsu.com
> wrote:
> >
> > From: Masahiko Sawada
> > > No. Please imagine a case where a user executes PREPARE TRANSACTION on
> > > the transaction tha
On Wed, 30 Sep 2020 at 16:02, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> > To avoid misunderstanding, I didn't mean to disregard the performance.
> > I mean especially for the transaction management feature it's
> > essential to work fine e
if (OidIsValid(slot->data.database))
+ pgstat_report_replslot(NameStr(slot->data.name), 0, 0, 0);
I think we can use SlotIsLogical() for this purpose. The same is true
when dropping a slot.
Regards,
--
Masahiko Sawadahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
y max_parallel_workers and the number of
indexes that support parallel vacuum and are bigger than
min_parallel_index_scan_size.
That way the default behavior and the behavior of PARALLEL option
without an integer is similar to parallel CREATE INDEX. In addition to
it, VACUUM command has an additional way to control the parallel
degree beyond max_parallel_maintenance_workers limit by using the
command option.
Regards,
--
Masahiko Sawadahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, 5 Oct 2020 at 11:21, Robert Haas wrote:
>
> On Sat, Oct 3, 2020 at 9:25 AM Masahiko Sawada
> wrote:
> > To make the behavior of parallel vacuum more consistent with other
> > parallel maintenance commands (i.g., only parallel INDEX CREATE for
> > now), as a s
On Sat, 3 Oct 2020 at 16:55, Amit Kapila wrote:
>
> On Sat, Oct 3, 2020 at 9:26 AM Masahiko Sawada
> wrote:
> >
> > When we discussed this before, I was thinking that we could have other
> > statistics for physical slots in the same statistics view in the
> >
On Mon, 5 Oct 2020 at 17:50, Amit Kapila wrote:
>
> On Mon, Oct 5, 2020 at 1:26 PM Masahiko Sawada
> wrote:
> >
> > On Sat, 3 Oct 2020 at 16:55, Amit Kapila wrote:
> > >
> > > On Sat, Oct 3, 2020 at 9:26 AM Masahiko Sawada
> > > wrote:
>
On Fri, 2 Oct 2020 at 18:20, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> > You proposed the first idea
> > to avoid such a situation that FDW implementor can write the code
> > while trying to reduce the possibility of errors happening as much as
>
On Tue, 6 Oct 2020 at 17:56, Amit Kapila wrote:
>
> On Tue, Oct 6, 2020 at 9:34 AM Masahiko Sawada
> wrote:
> >
> > Looking at pgstat_reset_replslot_counter() in the v8 patch, even if we
> > pass a physical slot name to pg_stat_reset_replication_slot() a
> >
On Thu, Mar 10, 2022 at 2:10 PM osumi.takami...@fujitsu.com
wrote:
>
> On Wednesday, March 2, 2022 12:01 AM Masahiko Sawada
> wrote:
> > I've attached an updated patch along with two patches for cfbot tests since
> > the
> > main patch (0003) depends on the othe
On Thu, Mar 10, 2022 at 9:02 PM Amit Kapila wrote:
>
> On Tue, Mar 1, 2022 at 8:31 PM Masahiko Sawada wrote:
> >
> > I've attached an updated patch along with two patches for cfbot tests
> > since the main patch (0003) depends on the other two patches. Both
> >
allocate shared memory for vacuum
worker progress");
Since we raise an error in case of out of memory, I think we can use
HASH_ENTER instead of HASH_ENTER_NULL. Or do we want to emit a
detailed error message here?
---
+ VacuumWorkerProgressHash = NULL;
This line is not necessary.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
d be to send the message for creating the
subscription at the end of CRAETE SUBSCRIPTION which basically
resolves them. A caveat is that if CREATE SUBSCRIPTION (that doesn't
involve replication slot creation) is rolled back, the first problem
still occurs. But it should not practically matter as
On Mon, Mar 14, 2022 at 6:50 PM shiy.f...@fujitsu.com
wrote:
>
> On Fri, Mar 11, 2022 4:20 PM Masahiko Sawada wrote:
> >
> > I've attached an updated version patch. This patch can be applied on
> > top of the latest disable_on_error patch[1].
> >
>
> Than
On Tue, Mar 15, 2022 at 3:34 AM Melanie Plageman
wrote:
>
> On Mon, Mar 14, 2022 at 4:02 AM Masahiko Sawada wrote:
> >
> > On Mon, Mar 14, 2022 at 2:05 AM Melanie Plageman
> > wrote:
> > >
> > > On Sat, Mar 12, 2022 at 3:15 PM Andres Freund wrote:
>
Hi,
On Fri, Mar 11, 2022 at 8:37 PM osumi.takami...@fujitsu.com
wrote:
>
> On Friday, March 11, 2022 5:20 PM Masahiko Sawada
> wrote:
> > I've attached an updated version patch. This patch can be applied on top of
> > the
> > latest disable_on_error patch[1
On Tue, Mar 15, 2022 at 7:18 PM Amit Kapila wrote:
>
> On Tue, Mar 15, 2022 at 11:43 AM Masahiko Sawada
> wrote:
> >
>
> 6.
> @@ -1583,7 +1649,8 @@ apply_handle_insert(StringInfo s)
> TupleTableSlot *remoteslot;
> MemoryContext oldctx;
>
&g
On Tue, Mar 15, 2022 at 7:18 PM Amit Kapila wrote:
>
> On Tue, Mar 15, 2022 at 11:43 AM Masahiko Sawada
> wrote:
> >
> > I've attached an updated version patch.
> >
>
> Review:
> ===
Thank you for the comments.
> 1.
> +++ b/doc/src/sgm
On Wed, Mar 16, 2022 at 11:28 AM Amit Kapila wrote:
>
> On Wed, Mar 16, 2022 at 6:03 AM Masahiko Sawada wrote:
> >
> > On Tue, Mar 15, 2022 at 7:18 PM Amit Kapila wrote:
> > >
> > > On Tue, Mar 15, 2022 at 11:43 AM Masahiko Sawada
> > > wrote:
&g
On Wed, Mar 16, 2022 at 1:20 PM Amit Kapila wrote:
>
> On Wed, Mar 16, 2022 at 7:58 AM Amit Kapila wrote:
> >
> > On Wed, Mar 16, 2022 at 6:03 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Mar 15, 2022 at 7:18 PM Amit Kapila
> > > wrot
On Wed, Mar 16, 2022 at 11:57 AM wangw.f...@fujitsu.com
wrote:
>
> On Wed, Mar 9, 2022 at 2:45 PM Masahiko Sawada wrote:
> >
> Thanks for your comments.
>
> > On Wed, Mar 9, 2022 at 10:26 AM I wrote:
> > > On Tue, Mar 8, 2022 at 3:52 PM Masahiko Sawada
>
On Wed, Mar 16, 2022 at 8:51 PM Amit Kapila wrote:
>
> On Tue, Mar 15, 2022 at 10:09 AM Masahiko Sawada
> wrote:
> >
> > On Tue, Mar 15, 2022 at 3:34 AM Melanie Plageman
> > wrote:
> > >
> > > On Mon, Mar 14, 2022 at 4:02 AM Masahiko Sawada
>
On Thu, Mar 17, 2022 at 5:52 PM Amit Kapila wrote:
>
> On Thu, Mar 17, 2022 at 12:39 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Thursday, March 17, 2022 3:04 PM Amit Kapila
> > wrote:
> > > On Wed, Mar 16, 2022 at 1:53 PM Masahiko Sawada
> >
On Thu, Mar 17, 2022 at 7:14 PM Amit Kapila wrote:
>
> On Thu, Mar 17, 2022 at 12:27 PM Amit Kapila wrote:
> >
> > On Wed, Mar 16, 2022 at 7:38 PM Masahiko Sawada
> > wrote:
> > >
> > > After more thought, can we check only wal_sender_tim
On Thu, Mar 17, 2022 at 3:03 PM Amit Kapila wrote:
>
> On Wed, Mar 16, 2022 at 1:53 PM Masahiko Sawada wrote:
> >
> > I've attached an updated version patch.
> >
>
> The patch LGTM. I have made minor changes in comments and docs in the
> attached patch. Ki
llel worker exiting and the leader
deallocating the hash table entry.
BTW have we discussed another idea I mentioned before that we have the
leader process periodically check the number of completed indexes and
advertise it in its progress information? I'm not sure which one is
better but this idea would require only changes of vacuum code and
probably simpler than the current idea.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
ecovery/tmp_check/results/vacuum.out
2022-03-22 03:28:09.813377179 +0100
@@ -181,7 +181,7 @@
SELECT pg_relation_size('vac_truncate_test') = 0;
?column?
--
- t
+ f
(1 row)
VACUUM (TRUNCATE FALSE, FULL TRUE) vac_truncate_test;
=== EOF ===
not ok 2 - regression tests pass
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
parallel vacuums.
>
Can the leader pass a callback that checks PVIndStats to ambulkdelete
an amvacuumcleanup callbacks? I think that in the passed callback, the
leader checks if the number of processed indexes and updates its
progress information if the current progress needs to be updated.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
e see more demand for this.
Marking as Returned with feedback makes sense to me.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
t; changed/added comments in the code.
> >
> > Do let me know what you think of the attached?
> It looks good to me. Just rebase it because the change in header(75b1521).
> I tested it and the result looks good to me.
Since commit 75b1521 added decoding of sequence to logical
replica
uences_option_given = true;
+
+data->sequences = defGetBoolean(defel);
+}
But as far as I read changes, there is no use of this option, and this
code is not tested. Can we remove it or is it for upcoming changes?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
tab_completion.patch
Description: Binary data
than the above concerns you mentioned such as introducing
additional complexity and a possible lag of progress updates. So if we
go with the current approach, I think we need to make sure enough (and
not too many) hash table entries.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
in the case of pg_stat_get_subscription_stats(NULL) I found to
> also be wrong upthread.
Right. But it seems like we cannot simply add PG_ARGISNULL () to
PG_GETARG_DATUM(). There are some codes such as array_remove() and
array_replace() that call PG_GETARG_DATUM() and PG_ARGISNULL() and
pass
On Fri, Mar 25, 2022 at 5:33 PM Amit Kapila wrote:
>
> On Fri, Mar 25, 2022 at 11:49 AM Masahiko Sawada
> wrote:
> >
> > On Fri, Mar 25, 2022 at 2:23 PM wangw.f...@fujitsu.com
> > wrote:
> >
> > Since commit 75b1521 added decoding of sequence to logical
&
sure that the reloading has taken effect.
+$log_location = -s $node_subscriber->logfile;
+
+$node_publisher->safe_psql('postgres', "INSERT INTO tab_notrep VALUES (11)");
+
+$node_publisher->wait_for_catchup('tap_sub');
+
+$logfile = slurp_file($node_publisher->logfile, $log_location);
I think we should get the log location of the publisher node, not
subscriber node.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
t.
> Attach the new version patch with this change.
>
Thank you for updating the patch. Looks good to me.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
it’s a good design, and adding a new callback introduces complexity.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
EFRESH PUBLICATION gets executed,
> >> and we can't do that until the transaction commits.
> >>
> >> So I guess that's correct, and the current behavior is a bug.
> >>
> >
> > Yes, I also think that is a bug.
> >
>
> OK
I also think that this is a bug. Given this behavior is a bug and
newly-added sequence data should be replicated only after ALTER
SUBSCRIPTION ... REFRESH PUBLICATION, is there any case where the
sequence message applied on the subscriber is transactional?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
sed) here:
> https://drive.google.com/file/d/16NkyNIV07o0o8WM7GwcaAYFQDPTkULkR/view?usp=sharing
Thank you for the report. I'm investigating this issue.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Fri, Apr 1, 2022 at 5:10 PM Masahiko Sawada wrote:
>
> On Fri, Apr 1, 2022 at 4:44 PM Noah Misch wrote:
> >
> > On Tue, Mar 29, 2022 at 10:43:00AM +0530, Amit Kapila wrote:
> > > On Mon, Mar 21, 2022 at 5:51 PM Euler Taveira wrote:
> > > > On Mon, Mar 2
scription.sql passes, something is wrong when we read the
subskiplsn value by like "sub->skiplsn = subform->subskiplsn;".
Is it possible to run the test again with the attached patch?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
add_logs_v2.patch
Description: Binary data
On Sat, Apr 2, 2022 at 7:04 PM Amit Kapila wrote:
>
> On Sat, Apr 2, 2022 at 1:43 PM Noah Misch wrote:
> >
> > On Sat, Apr 02, 2022 at 04:33:44PM +0900, Masahiko Sawada wrote:
> > > It seems that 0/B0706F72 is not a random value. Two subscriber logs
> > >
On Sun, Apr 3, 2022 at 9:45 AM Noah Misch wrote:
>
> On Sat, Apr 02, 2022 at 08:44:45PM +0900, Masahiko Sawada wrote:
> > On Sat, Apr 2, 2022 at 7:04 PM Amit Kapila wrote:
> > > On Sat, Apr 2, 2022 at 1:43 PM Noah Misch wrote:
> > > > Some options:
> >
On Mon, Apr 4, 2022 at 11:50 AM Amit Kapila wrote:
>
> On Mon, Apr 4, 2022 at 8:01 AM Noah Misch wrote:
> >
> > On Mon, Apr 04, 2022 at 10:28:30AM +0900, Masahiko Sawada wrote:
> > > On Sun, Apr 3, 2022 at 9:45 AM Noah Misch wrote:
> > > > On Sat, Apr
ly?
> >>
> >> Also, there's the bug with decoding changes in transactions that create
> >> the sequence and add it to a publication. I think the agreement was that
> >> this behavior was incorrect, we should not decode changes until the
> >> subscription is refreshed. Doesn't that mean can't be any CREATE case,
> >> just ALTER?
> >>
> >
> > Yeah, but how will we distinguish them. Aren't they using the same
> > kind of WAL record?
> >
>
> Same WAL record, but the "created" flag which should distinguish these
> two cases, IIRC.
Since the "created" flag indicates that we created a new relfilenode
so it's true when both CREATE and ALTER.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Mon, Apr 4, 2022 at 3:26 PM Noah Misch wrote:
>
> On Mon, Apr 04, 2022 at 08:20:08AM +0530, Amit Kapila wrote:
> > On Mon, Apr 4, 2022 at 8:01 AM Noah Misch wrote:
> > > On Mon, Apr 04, 2022 at 10:28:30AM +0900, Masahiko Sawada wrote:
> > > > On Sun, Apr 3,
On Mon, Apr 4, 2022 at 1:30 PM Julien Rouhaud wrote:
>
> Hi,
>
> On Tue, Mar 01, 2022 at 11:35:32AM +0900, Masahiko Sawada wrote:
> > On Wed, Jan 19, 2022 at 5:52 PM Julien Rouhaud wrote:
> > >
> > > It seems that the regression tests aren't entirel
On Tue, Apr 5, 2022 at 9:21 AM Noah Misch wrote:
>
> On Mon, Apr 04, 2022 at 06:55:45PM +0900, Masahiko Sawada wrote:
> > On Mon, Apr 4, 2022 at 3:26 PM Noah Misch wrote:
> > > On Mon, Apr 04, 2022 at 08:20:08AM +0530, Amit Kapila wrote:
> > > > How about a comm
On Tue, Apr 5, 2022 at 1:31 AM Julien Rouhaud wrote:
>
> On Tue, Apr 05, 2022 at 12:51:12AM +0900, Masahiko Sawada wrote:
> > On Mon, Apr 4, 2022 at 1:30 PM Julien Rouhaud wrote:
> > >
> > > Hmm, but AFAICS the json format would be stable as the counters are always
On Tue, Apr 5, 2022 at 10:46 AM Noah Misch wrote:
>
> On Tue, Apr 05, 2022 at 10:13:06AM +0900, Masahiko Sawada wrote:
> > On Tue, Apr 5, 2022 at 9:21 AM Noah Misch wrote:
> > > On Mon, Apr 04, 2022 at 06:55:45PM +0900, Masahiko Sawada wrote:
> > > > On Mon,
On Tue, Apr 5, 2022 at 12:38 PM Masahiko Sawada wrote:
>
> On Tue, Apr 5, 2022 at 10:46 AM Noah Misch wrote:
> >
> > On Tue, Apr 05, 2022 at 10:13:06AM +0900, Masahiko Sawada wrote:
> > > On Tue, Apr 5, 2022 at 9:21 AM Noah Misch wrote:
> > > > On Mon, Apr
On Tue, Apr 5, 2022 at 4:08 PM Noah Misch wrote:
>
> On Tue, Apr 05, 2022 at 03:05:10PM +0900, Masahiko Sawada wrote:
> > I've attached an updated patch. The patch includes a regression test
> > to detect the new violation as we discussed. I've confirmed that
>
On Wed, Apr 6, 2022 at 12:21 PM Noah Misch wrote:
>
> On Tue, Apr 05, 2022 at 04:41:28PM +0900, Masahiko Sawada wrote:
> > On Tue, Apr 5, 2022 at 4:08 PM Noah Misch wrote:
> > > On Tue, Apr 05, 2022 at 03:05:10PM +0900, Masahiko Sawada wrote:
> > > > I'v
atch.
>
> I ran that with pgbench, 4 clients (I have 4 cores) for 30 seconds, 3 times.
>
> Comparing master and this patch with track_io_timing activated, I see a 0.95%
> overhead, with a 2.6% noise level.
I've done the same test with a larger data set (10M tuples) on my
machine (MacOS):
HEAD: 5418.869 ms
Patched: 5367.234 ms
I can see about 1% overhead.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
>
>
> Pushed.
Thanks!
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Thu, Apr 7, 2022 at 5:52 PM Masahiko Sawada wrote:
>
> On Thu, Apr 7, 2022 at 4:55 PM Julien Rouhaud wrote:
> >
> > On Thu, Apr 07, 2022 at 04:24:54PM +0900, Michael Paquier wrote:
> > > On Thu, Apr 07, 2022 at 03:14:01PM +0800, Julien Rouhaud wrote:
> > >
ck function to ambulkdelete and amvacuumcleanup so that the
leader can do that periodically, e.g., every 1000 blocks, while
vacuuming an index.
Regards,
[1]
https://www.postgresql.org/message-id/CAD21AoBW6SMJ96CNoMeu%2Bf_BR4jmatPcfVA016FdD2hkLDsaTA%40mail.gmail.com
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
On Wed, Mar 1, 2023 at 3:37 PM John Naylor wrote:
>
> On Tue, Feb 28, 2023 at 10:09 PM Masahiko Sawada
> wrote:
> >
> > On Tue, Feb 28, 2023 at 10:20 PM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Feb 28, 2023 at 3:42 PM John Naylor
> &g
compare
> min_send_delay and max_slot_wal_keep_size when publisher receives the
> parameter.
Since max_slot_wal_keep_size can be changed by reloading the config
file, each walsender warns it also at that time? Not sure it's
helpful. I think it's a legitimate use case t
,
s.vacuum_count
FROM pg_stat_all_tables s
LEFT JOIN pg_class c ON s.relid = c.reltoastrelid
WHERE c.relname = 'vactst' OR s.relname = 'vactst'
We will get like:
SELECT * FROM vactst_vacuum_counts;
relname | vacuum_count
--+--
toast for vactst |0
vactst |1
(2 rows)
The rest looks good to me.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
On Thu, Mar 2, 2023 at 2:26 PM Nathan Bossart wrote:
>
> On Thu, Mar 02, 2023 at 02:21:08PM +0900, Michael Paquier wrote:
> > On Thu, Mar 02, 2023 at 12:58:32PM +0900, Masahiko Sawada wrote:
> >> Cutting the toast relation name to 'pg_toast' is a bit confusing to
On Thu, Mar 2, 2023 at 10:41 AM Melanie Plageman
wrote:
>
> On Mon, Feb 27, 2023 at 9:12 AM Masahiko Sawada wrote:
> > On Fri, Feb 24, 2023 at 7:08 AM Melanie Plageman
> > wrote:
> > > Users may wish to speed up long-running vacuum of a larg
On Thu, Mar 2, 2023 at 1:07 PM Amit Kapila wrote:
>
> On Thu, Mar 2, 2023 at 7:38 AM Masahiko Sawada wrote:
> >
> > On Wed, Mar 1, 2023 at 6:21 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > >
> > > >
> > > > Apart from a bad-use case example
On Fri, Mar 3, 2023 at 8:04 PM John Naylor wrote:
>
> On Wed, Mar 1, 2023 at 6:59 PM Masahiko Sawada wrote:
> >
> > On Wed, Mar 1, 2023 at 3:37 PM John Naylor
> > wrote:
> > >
> > > I think we're trying to solve the wrong problem here. I need to
On Tue, Mar 7, 2023 at 1:01 AM John Naylor wrote:
>
> On Mon, Mar 6, 2023 at 1:28 PM Masahiko Sawada wrote:
>
> > > Since the block-level measurement is likely overestimating quite a bit, I
> > > propose to simply reverse the order of the actions here, effectively
&
On Mon, Mar 6, 2023 at 5:26 AM Melanie Plageman
wrote:
>
> On Thu, Mar 2, 2023 at 6:37 PM Melanie Plageman
> wrote:
> >
> > On Thu, Mar 2, 2023 at 2:36 AM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Mar 2, 2023 at 10:41 AM Melanie Plageman
>
r perspective. I also think it would be worth exploring it if we've
not yet.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
vacuum_min_duration reloption for the
test tables instead of globally enabling it
The 001 test uses the 2PC transaction that holds locks on tables but
since we can consume xids while the server running, we don't need
that. Instead I think we can keep a transaction open in the background
like 002 test does.
I'll try these ideas.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
than
> the current state of affairs.
And I think that the tidstore makes it easy to react to
maintenance_work_mem changes. We don't need to enlarge it and just
update its memory limit at an appropriate time.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
On Fri, Mar 10, 2023 at 11:23 AM Melanie Plageman
wrote:
>
> On Tue, Mar 7, 2023 at 12:10 AM Masahiko Sawada wrote:
> >
> > On Mon, Mar 6, 2023 at 5:26 AM Melanie Plageman
> > wrote:
> > >
> > > On Thu, Mar 2, 2023 at 6:37 PM Melanie Plageman
> &
On Fri, Mar 10, 2023 at 3:42 PM John Naylor
wrote:
>
> On Thu, Mar 9, 2023 at 1:51 PM Masahiko Sawada wrote:
>
> > I've attached the new version patches. I merged improvements and fixes
> > I did in the v29 patch.
>
> I haven't yet had a chance to look at th
On Sun, Mar 12, 2023 at 12:54 AM John Naylor
wrote:
>
> On Fri, Mar 10, 2023 at 9:30 PM Masahiko Sawada wrote:
> >
> > On Fri, Mar 10, 2023 at 3:42 PM John Naylor
> > wrote:
>
> > > I'd suggest sharing your todo list in the meanwhile, it'd be good
On Mon, Mar 13, 2023 at 10:28 PM John Naylor
wrote:
>
> On Mon, Mar 13, 2023 at 8:41 AM Masahiko Sawada wrote:
> >
> > On Sun, Mar 12, 2023 at 12:54 AM John Naylor
> > wrote:
> > >
> > > On Fri, Mar 10, 2023 at 9:30 PM Masahiko Sawada
> > &g
On Wed, Mar 8, 2023 at 1:52 PM Masahiko Sawada wrote:
>
> On Fri, Mar 3, 2023 at 8:34 PM Heikki Linnakangas wrote:
> >
> > On 16/11/2022 06:38, Ian Lawrence Barwick wrote:
> > > Thanks for the patch. While reviewing the patch backlog, we have
> > > determi
what invokes a page fault.
---
IIUC you suggested measuring memory usage by tracking how much memory
chunks are allocated within a block. If your idea at the top of the
page follows this method, it still doesn't deal with the point Andres
mentioned.
> I'll put this item and a couple other things together in a separate email
> tomorrow.
Thanks!
Regards,
[1]
https://www.postgresql.org/message-id/CAFBsxsEnzivaJ13iCGdDoUMsXJVGOaahuBe_y%3Dq6ow%3DLTzyDvA%40mail.gmail.com
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
On Sat, Mar 11, 2023 at 8:11 AM Melanie Plageman
wrote:
>
> Quotes below are combined from two of Sawada-san's emails.
>
> I've also attached a patch with my suggested current version.
>
> On Thu, Mar 9, 2023 at 10:27 PM Masahiko Sawada wrote:
> >
> >
(txn->nentries_mem != 0)))
txn->txn_flags |= RBTXN_IS_STREAMED;
Probably the following comment of the above lines also needs to be updated?
* The toplevel transaction, identified by (toptxn==NULL), is marked as
* streamed always,
---
+/* Is this a top-level transaction? */
+#d
unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: 2023-03-15
17:10:59.404 JST [471159] LOG: server process (PID 471180) was
terminated by signal 11: Segmentation fault
Finally, when I used a more lower value, 16777100, I got a memory
allocation error:
postgres(1:471361)=# vacuum (buffer_usage_limit 16777100) ;
2023-03-15 17:12:17.853 JST [471361] ERROR: invalid memory alloc
request size 18446744073709551572
Probably vacuum_buffer_usage_limit also has the same issue.
Also, should we support a table option for vacuum_buffer_usage_limit as well?
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
a for replication origin "pg_16390"
during message type "BEGIN" in transaction 734, finished at 0/1751698
If I create the sequence s2 in advance on the subscriber, the sequence
change is applied on the subscriber.
If the subscriber doesn't need to apply transactional sequence changes
in the first place, this problem will disappear.
---
There are two typos in 0001 patch:
In the commit message:
ensure the sequence record has a valid XID - until now the the increment
s/the the/ the/
And,
+ /* Only ever called from ReorderBufferApplySequence, so transational. */
s/transational/transactional/
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
On Fri, Mar 17, 2023 at 4:03 PM John Naylor
wrote:
>
> On Wed, Mar 15, 2023 at 9:32 AM Masahiko Sawada wrote:
> >
> > On Tue, Mar 14, 2023 at 8:27 PM John Naylor
> > wrote:
> > >
> > > I wrote:
> > >
> > > > > > Since the bloc
On Fri, Mar 17, 2023 at 4:49 PM Masahiko Sawada wrote:
>
> On Fri, Mar 17, 2023 at 4:03 PM John Naylor
> wrote:
> >
> > On Wed, Mar 15, 2023 at 9:32 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Mar 14, 2023 at 8:27 PM John
On Mon, Mar 20, 2023 at 9:34 PM John Naylor
wrote:
>
>
> On Mon, Mar 20, 2023 at 12:25 PM Masahiko Sawada
> wrote:
> >
> > On Fri, Mar 17, 2023 at 4:49 PM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, Mar 17, 2023 at 4:03 PM John Naylor
> &g
On Tue, Mar 21, 2023 at 2:41 PM John Naylor
wrote:
>
>
> On Mon, Mar 20, 2023 at 9:34 PM Masahiko Sawada wrote:
> >
> > On Mon, Mar 20, 2023 at 9:34 PM John Naylor
> > wrote:
> > > That's an interesting idea, and the analogous behavior to aset could b
tgresql.org/message-id/CAD21AoDKr%3D4YHphy6cRojE5eyT6E2ao8xb44E309eTrUEOC6xw%40mail.gmail.com
[3] from dsm.c, the total number of DSM segments available on the
system is calculated by:
#define PG_DYNSHMEM_FIXED_SLOTS 64
#define PG_DYNSHMEM_SLOTS_PER_BACKEND 5
maxitems = PG_DYNSHMEM_FIXED_SLOTS
+ PG_DYNSHMEM_SLOTS_PER_BA
inconsistent dump. The subscriber will easily be not in
> sync due to that.
>
> Now, how do we avoid these problems even if we have our own version of
> functionality similar to pg_dump for selected objects? I guess we will
> face similar problems.
Right. I think that such functionality needs to return DDL commands
that can be executed on the requested version.
> If so, we may need to deny schema sync in any such case.
Yes. Do we have any concrete use case where the subscriber is an older
version, in the first place?
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
On Wed, Mar 22, 2023 at 2:16 PM Amit Kapila wrote:
>
> On Wed, Mar 22, 2023 at 8:29 AM Masahiko Sawada wrote:
> >
> > On Tue, Mar 21, 2023 at 8:18 PM Amit Kapila wrote:
> > >
> > > On Tue, Mar 21, 2023 at 7:32 AM Euler Taveira wrote:
> > >
> >
On Sun, Mar 19, 2023 at 7:47 AM Melanie Plageman
wrote:
>
> On Wed, Mar 15, 2023 at 1:14 AM Masahiko Sawada wrote:
> > On Sat, Mar 11, 2023 at 8:11 AM Melanie Plageman
> > wrote:
> > > I've implemented the atomic cost limit in the attached patch. Though,
>
would have validated that your application is compatible with that new
> version before this point)
I might be missing something but is there any reason why you created a
subscription before pg_upgrade?
Steps like doing pg_upgrade, then creating missing tables, and then
creating a subscription (with copy_data = false) could be an
alternative way to support upgrading the server from the physical
standby?
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
bug
was reported late in the discussion but it was the same issue as CF
item "Assertion failure in SnapBuildInitialSnapshot()".
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
On Fri, Mar 24, 2023 at 9:27 AM Melanie Plageman
wrote:
>
> On Thu, Mar 23, 2023 at 2:09 AM Masahiko Sawada wrote:
> > On Sun, Mar 19, 2023 at 7:47 AM Melanie Plageman
> > wrote:
> > Do we need to calculate the number of workers running with
> > nworkers_for
he publication includes that, or (2) not send sequence changes to
such subscribers.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
sh a
> > new snapshot using a technique proposed in email [1].
> >
>
> Thanks, I think option (b) will be perfect, since we don’t have to create a
> new slot.
Regarding (b), does it mean that apply worker stops streaming,
requests to create a snapshot, and then resumes the streaming?
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
ng another database such as template1), simply
replicating the CREATE DATABASE statement would not produce the same
results as the publisher. Also, since event triggers are not fired on
DDLs for global objects, always WAL-logging such DDL statements like
the proposed patch does is not a good idea.
Given that there seems to be some tricky problems and there is a
discussion for cutting the scope to make the initial patch small[1], I
think it's better to do this work after the first version.
Regards,
[1]
https://www.postgresql.org/message-id/CAA4eK1K3VXfTWXbLADcH81J%3D%3D7ussvNdqLFHN68sEokDPueu7w%40mail.gmail.com
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
601 - 700 of 1834 matches
Mail list logo
