e old cache state. I am missing your
point about the race condition mentioned in the thread you quoted with
snapbuild.c. Can you please elaborate a bit more?
--
With Regards,
Amit Kapila.
instead of AE.
>
> Since I don't see how it'd be correct otherwise, it's kind of a moot question.
>
We lost track of this thread and the bug is still open. IIUC, the
conclusion is to use SRE in OpenTableList() to fix the reported issue.
Andres, Tomas, please let me know if my understanding is wrong,
otherwise, let's proceed and fix this issue.
--
With Regards,
Amit Kapila.
s? If so, the documentation should say that, and the tool likely
> should warn on startup if max_prepared_transactions != 0.
>
The other point to note in this regard is that if we don't support
two_phase in the beginning during subscription/slot setup, users won't
be able to change it as we don't yet support changing it via alter
subscription (though the patch to alter two_pc is proposed for PG18).
--
With Regards,
Amit Kapila.
veta Malik)
> >
> > it seems like the name ought to have some connection to
> > synchronization. Perhaps something like "synchronized_standby_slots"?
>
> IMHO that might be a bit too close to synchronous_standby_names.
>
Right, but better than the current one.
gical WAL senders such that they will send decoded changes to
plugins only after the specified replication slots confirm receiving
WAL. So, combining them doesn't sound advisable.
--
With Regards,
Amit Kapila.
skipping
> generated columns is the same for all of them.
>
> Note that CREATE PUBLICATION column lists did not exist until PG15, so
> a modified patch is needed for the versions before that.
>
Pushed.
--
With Regards,
Amit Kapila.
seems not sufficient. We have to point out the exact the end of the
> record.
>
You have a point but if this theory is correct why we are not able to
reproduce the issue after this patch? Also, how to get the WAL
location up to which we need to flush? Is XLogCtlData->logInsertResult
the one we are looking for?
--
With Regards,
Amit Kapila.
On Wed, Jun 19, 2024 at 8:33 PM vignesh C wrote:
>
> On Tue, 18 Jun 2024 at 16:10, Amit Kapila wrote:
> >
> >
> > Agreed and I am not sure which is better because there is a value in
> > keeping the state name the same for both sequences and tables. We
> >
On Thu, Jun 20, 2024 at 5:06 PM Ashutosh Bapat
wrote:
>
> On Thu, Jun 20, 2024 at 3:21 PM Amit Kapila wrote:
>>
>> On Wed, Jun 19, 2024 at 2:51 PM Ashutosh Bapat
>> wrote:
>> >
>> > On Wed, Jun 19, 2024 at 12:03 PM Amit Kapila
>> > wrote:
etected). There could
be multiple ways to provide these parameters, one is providing them as
GUCs, and another at the subscription or the table level. I am
thinking whether users would only like to care about a table or set of
tables or they would like to set such variables at the system level.
We already have an SKIP option (that allows us to skip the
transactions till a particular LSN) at the subscription level, so I am
wondering if there is a sense to provide these new parameters related
to conflict resolution also at the same level?
--
With Regards,
Amit Kapila.
On Wed, Jun 19, 2024 at 2:51 PM Ashutosh Bapat
wrote:
>
> On Wed, Jun 19, 2024 at 12:03 PM Amit Kapila wrote:
>>
>> > I doubt that it would be that simple. The application will have to
>> > intervene and tell one of the employees that their reservation has
On Thu, Jun 20, 2024 at 2:35 AM Euler Taveira wrote:
>
> I will open new threads soon if you don't.
>
Okay, thanks. I'll wait for you to start new threads and then we can
discuss the respective problems in those threads.
--
With Regards,
Amit Kapila.
On Tue, Jun 11, 2024 at 3:12 PM Ashutosh Bapat
wrote:
>
> On Sat, Jun 8, 2024 at 3:52 PM Amit Kapila wrote:
>>
>> On Fri, Jun 7, 2024 at 5:39 PM Ashutosh Bapat
>> wrote:
>> >
>> > On Thu, Jun 6, 2024 at 5:16 PM Nisha Moond
>> > wrote
; same key is reported as "duplicate key value violates unique constraint
> > "%s"",
> > which could confuse users.
>
> Do you mean it's ok to add a pre-check before applying the INSERT, which will
> verify if the remote tuple violates any unique constraints, and if it violates
> then we log a conflict message ? I thought about this but was slightly
> worried about the extra cost it would bring. OTOH, if we think it's
> acceptable,
> we could do that since the cost is there only when detect_conflict is enabled.
>
> I also thought of logging such a conflict message in pg_catch(), but I think
> we
> lack some necessary info(relation, index name, column name) at the catch
> block.
>
Can't we use/extend existing 'apply_error_callback_arg' for this purpose?
--
With Regards,
Amit Kapila.
value
in setting the 'failover' option for a slot without specifying
'standby_slot_names', so was wondering if we can additionally tie it
to 'synchronous_standby_names'. Any better ideas?
--
With Regards,
Amit Kapila.
On Wed, Jun 19, 2024 at 6:46 AM Peter Smith wrote:
>
> On Tue, Jun 18, 2024 at 9:40 PM Amit Kapila wrote:
> >
> > On Tue, Jun 18, 2024 at 12:11 PM Peter Smith wrote:
> > >
> > > While reviewing another thread that proposes to include "generated
> >
On Tue, Jun 18, 2024 at 12:13 PM Peter Eisentraut wrote:
>
> On 18.06.24 05:59, Amit Kapila wrote:
> >> 1. After promotion, the pre-existing replication objects should be
> >> removed (either optionally or always), otherwise, it can lead to a new
> >> sub
On Tue, Jun 18, 2024 at 12:41 PM Euler Taveira wrote:
>
> On Tue, Jun 18, 2024, at 12:59 AM, Amit Kapila wrote:
>
> On Mon, May 20, 2024 at 12:12 PM Amit Kapila wrote:
> >
> > On Sun, May 19, 2024 at 11:20 PM Euler Taveira wrote:
> > >
> > > On Sun
tion 29.7)
> * e.g.4 in the "CREATE PUBLICATION" reference page
>
> For now, I have provided just a simple patch for the "Generated
> Columns" section [3]. Perhaps it is enough.
>
Can we try to clarify if their corresponding values are replicated?
--
With Regards,
Amit Kapila.
On Tue, Jun 18, 2024 at 7:30 AM Masahiko Sawada wrote:
>
> On Fri, Jun 14, 2024 at 4:04 PM Amit Kapila wrote:
> >
> > On Thu, Jun 13, 2024 at 6:14 PM Masahiko Sawada
> > wrote:
> > >
> >
> > > >
> > > > Now, say we don't want to
On Tue, Jun 18, 2024 at 1:18 PM Dilip Kumar wrote:
>
> On Tue, Jun 18, 2024 at 12:11 PM Amit Kapila wrote:
> >
> > On Tue, Jun 18, 2024 at 11:54 AM Dilip Kumar wrote:
> > >
> > > On Mon, Jun 17, 2024 at 8:51 PM Robert Haas wrote:
> > > >
>
On Tue, Jun 18, 2024 at 11:54 AM Dilip Kumar wrote:
>
> On Mon, Jun 17, 2024 at 8:51 PM Robert Haas wrote:
> >
> > On Mon, Jun 17, 2024 at 1:42 AM Amit Kapila wrote:
> > > The difference w.r.t the existing mechanisms for holding deleted data
> > > is that w
On Mon, May 20, 2024 at 12:12 PM Amit Kapila wrote:
>
> On Sun, May 19, 2024 at 11:20 PM Euler Taveira wrote:
> >
> > On Sun, May 19, 2024, at 2:30 PM, Tom Lane wrote:
> >
> > I'm fairly disturbed about the readiness of pg_createsubscriber.
> > The
is worth especially when other
systems providing CDR feature (like Ora or BDR) for decades have not
done anything like vector clocks. It is possible that this is less of
a problem w.r.t CDR and just detecting the anomaly in clock skew is
good enough.
[1] -
https://www.postgresql.org/message-id/flat/CAEepm%3D1iiEzCVLD%3DRoBgtZSyEY1CR-Et7fRc9prCZ9MuTz3pWg%40mail.gmail.com
--
With Regards,
Amit Kapila.
On Mon, Jun 17, 2024 at 4:18 AM Tomas Vondra
wrote:
>
> On 6/14/24 13:29, Amit Kapila wrote:
> > On Fri, Jun 14, 2024 at 12:10 AM Robert Haas wrote:
> >>
> >> On Thu, May 23, 2024 at 2:37 AM shveta malik
> >> wrote:
> >>> c) update_de
CAJpy0uCov4JfZJeOvY0O21_gk9bcgNUDp4jf8%2BBbMp%2BEAv8cVQ%40mail.gmail.com
--
With Regards,
Amit Kapila.
On Thu, Jun 13, 2024 at 11:18 PM Jonathan S. Katz wrote:
>
> On 6/13/24 7:28 AM, Amit Kapila wrote:
> >>
> >> I feel that we should log all types of conflict in an uniform way. For
> >> example, with detect_conflict being true, the update_differ conflict
> >
On Thu, Jun 13, 2024 at 7:00 PM Alvaro Herrera wrote:
>
> On 2024-Jun-07, Tomas Vondra wrote:
>
> > On 6/3/24 09:30, Amit Kapila wrote:
> > > On Sat, May 25, 2024 at 2:39 AM Tomas Vondra
> > > wrote:
>
> > >> How is this going to deal with th
On Fri, Jun 14, 2024 at 5:16 AM Michael Paquier wrote:
>
> On Thu, Jun 13, 2024 at 03:36:05PM +0530, Amit Kapila wrote:
> > Fair enough. However, this raises the question Dilip and Vignesh are
> > discussing whether we need a new relfilenode for sequence update even
>
On Thu, Jun 13, 2024 at 6:14 PM Masahiko Sawada wrote:
>
> On Thu, Jun 13, 2024 at 7:06 PM Amit Kapila wrote:
> >
> > On Thu, Jun 13, 2024 at 1:09 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Jun 12, 2024 at 6:59 PM Amit Kapila
> >
On Thu, Jun 13, 2024 at 1:09 PM Masahiko Sawada wrote:
>
> On Wed, Jun 12, 2024 at 6:59 PM Amit Kapila wrote:
> >
> >
> > Yeah, starting with a single worker sounds good for now. Do you think
> > we should sync all the sequences in a single transaction or have
nique constraint "%s"", which could confuse users.
> Ideally, I think that we log such conflict detection details (table
> name, column name, conflict type, etc) to somewhere (e.g. a table or
> server logs) so that the users can resolve them manually.
>
It is good to think if there is a v
On Wed, Jun 12, 2024 at 6:43 AM Kyotaro Horiguchi
wrote:
>
> At Tue, 11 Jun 2024 14:27:28 +0530, Amit Kapila
> wrote in
> > On Tue, Jun 11, 2024 at 12:34 PM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Tue, 11 Jun 2024 11:32:12 +0530, Amit Kapila
> &
el and sequence values can be
rolled back together. However, it is unclear whether we need to create
a new relfilenode while copying existing sequences (say during ALTER
SUBSCRIPTION .. REFRESH PUBLICATION SEQUENCES, or whatever command we
decide)? Probably the answer lies in how we want to implement this
command. If we want to copy all sequence values during the command
itself then it is probably okay but if we want to handover this task
to the sequence-sync worker then we need some state management and a
new relfilenode so that on error both state and sequence values are
rolled back.
--
With Regards,
Amit Kapila.
On Mon, Jun 10, 2024 at 5:12 PM Tomas Vondra
wrote:
>
> On 6/10/24 10:54, Amit Kapila wrote:
> > On Fri, Jun 7, 2024 at 6:08 PM Tomas Vondra
> > wrote:
> >>
> >> On 5/27/24 07:48, shveta malik wrote:
> >>> On Sat, May 25, 2024 at 2:39 A
eful assert, protecting us against certain type of bugs. And now we'll
> just happily ignore them. Is that a good idea?
>
The assert was added in this release. I was also having the same
understanding as yours which is why I added it. However, the case
presented by Vignesh has revealed that I was wrong.
--
With Regards,
Amit Kapila.
On Tue, Jun 11, 2024 at 12:34 PM Kyotaro Horiguchi
wrote:
>
> At Tue, 11 Jun 2024 11:32:12 +0530, Amit Kapila
> wrote in
> > Sorry, it is not clear to me why we failed to flush the last
> > continuation record in logical walsender? I see that we try to flush
> &
t;
Thanks, I have pushed the fix.
--
With Regards,
Amit Kapila.
, it is not clear to me why we failed to flush the last
continuation record in logical walsender? I see that we try to flush
the WAL after receiving got_STOPPING in WalSndWaitForWal(), why is
that not sufficient?
--
With Regards,
Amit Kapila.
On Tue, Feb 20, 2024 at 12:35 PM vignesh C wrote:
>
> On Sat, 17 Feb 2024 at 12:03, Amit Kapila wrote:
> >
> >
> > @@ -1839,7 +1839,8 @@ LogicalConfirmReceivedLocation(XLogRecPtr lsn)
> >
> > SpinLockAcquire(>mutex);
> >
> > - MyReplica
On Mon, Jun 10, 2024 at 12:43 PM Masahiko Sawada wrote:
>
> On Mon, Jun 10, 2024 at 3:14 PM Masahiko Sawada wrote:
> >
> > On Fri, Jun 7, 2024 at 7:30 PM Amit Kapila wrote:
> > >
> > >
> > > Are you imagining the behavior for sequences associate
that there still are problems, but the examples are likely more complex
> (changes to multiple tables, etc.).
>
Fair enough, I think we need to analyze this more to find actual
problems or in some way try to prove that there is no problem.
> I vaguely remember there were more issues with timestamp inversion, but
> those might have been related to parallel apply etc.
>
Okay, so considering there are problems due to timestamp inversion, I
think the solution to that problem would probably be somehow
generating commit LSN and timestamp in order. I don't have a solution
at this stage but will think more both on the actual problem and
solution. In the meantime, if you get a chance to refer to the place
where you have seen such a problem please try to share the same with
us. It would be helpful.
--
With Regards,
Amit Kapila.
n inconsistency between r1 and r2?
>
As per my understanding, this shouldn't be an inconsistency. Won't it
be true even when the transactions are performed on a single node with
the same timing?
--
With Regards,
Amit Kapila.
On Fri, Jun 7, 2024 at 7:55 AM Masahiko Sawada wrote:
>
> On Thu, Jun 6, 2024 at 6:40 PM Amit Kapila wrote:
> >
> > On Thu, Jun 6, 2024 at 11:10 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Jun 5, 2024 at 9:30 PM Amit Kapila
> > > w
lying it to all subscribers. It makes more sense for the
> subscriber to control this, especially when we are planning to
> compress the data sent downstream.
>
Yes, that makes sense. However, we then need to provide this option
via SQL APIs as well for other plugins.
--
With Regards,
Amit Kapila.
On Thu, Jun 6, 2024 at 7:54 PM Alvaro Herrera wrote:
>
> On 2024-Jun-06, Amit Kapila wrote:
>
> > On Thu, Jun 6, 2024 at 4:28 PM Julien Tachoires wrote:
> > >
> > > When the content of a large transaction (size exceeding
> > > logical_decod
me
values.
--
With Regards,
Amit Kapila.
On Thu, Jun 6, 2024 at 6:22 PM Julien Tachoires wrote:
>
> Le jeu. 6 juin 2024 à 04:13, Amit Kapila a écrit :
> >
> > On Thu, Jun 6, 2024 at 4:28 PM Julien Tachoires wrote:
> > >
> > > When the content of a large transaction (size exceeding
> >
>
> 2. Do we want a GUC to switch compression on/off?
>
It depends on the overhead of decoding. Did you try to measure the
decoding overhead of decompression when reading compressed files?
--
With Regards,
Amit Kapila.
On Thu, Jun 6, 2024 at 3:44 PM Ashutosh Bapat
wrote:
>
> On Thu, Jun 6, 2024 at 9:22 AM Amit Kapila wrote:
>>
>> On Wed, Jun 5, 2024 at 6:01 PM Ashutosh Bapat
>> wrote:
>> >
>> > On Wed, Jun 5, 2024 at 8:45 AM Amit Kapila wrote:
>> >>
On Wed, Jun 5, 2024 at 7:29 PM Dilip Kumar wrote:
>
> On Tue, Jun 4, 2024 at 9:37 AM Amit Kapila wrote:
> >
> > Can you share the use case of "earliest_timestamp_wins" resolution
> > method? It seems after the initial update on the local node, it will
> &
On Thu, Jun 6, 2024 at 11:10 AM Masahiko Sawada wrote:
>
> On Wed, Jun 5, 2024 at 9:30 PM Amit Kapila wrote:
> >
>
> > To achieve this, we can allow sequences to be copied during
> > the initial CREATE SUBSCRIPTION command similar to what we do for
> > table
On Thu, Jun 6, 2024 at 9:32 AM Masahiko Sawada wrote:
>
> On Wed, Jun 5, 2024 at 12:43 PM Amit Kapila wrote:
> >
> > On Tue, Jun 4, 2024 at 8:56 PM Yogesh Sharma
> > wrote:
> > >
> > > On 6/4/24 06:57, Amit Kapila wrote:
> > >
> > >
On Wed, Jun 5, 2024 at 3:17 PM Bharath Rupireddy
wrote:
>
> On Tue, Jun 4, 2024 at 5:40 PM Amit Kapila wrote:
> >
> > Even if we decode it periodically (say each time we decode the
> > checkpoint record) then also we need to send the entire set of
> > sequence
On Wed, Jun 5, 2024 at 6:01 PM Ashutosh Bapat
wrote:
>
> On Wed, Jun 5, 2024 at 8:45 AM Amit Kapila wrote:
>>
>> How about periodically sending this information?
>> >
>>
>> Now, if we want to support some sort of failover then probably this
>>
On Wed, Jun 5, 2024 at 12:51 PM Peter Eisentraut wrote:
>
> On 04.06.24 12:57, Amit Kapila wrote:
> > 2. Provide a command say Alter Subscription ... Replicate Sequences
> > (or something like that) which users can perform before shutdown of
> > the publisher node during
On Wed, Jun 5, 2024 at 9:13 AM Amit Kapila wrote:
>
> On Tue, Jun 4, 2024 at 8:56 PM Yogesh Sharma
> wrote:
> >
> > On 6/4/24 06:57, Amit Kapila wrote:
> >
> > > 2. Provide a command say Alter Subscription ... Replicate Sequences
> > > (or someth
to ensure the same. If at all we get
such use cases and or requirements then we can add such additional
steps after understanding the user's requirements. For now, we should
remove these additional steps.
--
With Regards,
Amit Kapila.
On Tue, Jun 4, 2024 at 8:56 PM Yogesh Sharma
wrote:
>
> On 6/4/24 06:57, Amit Kapila wrote:
>
> > 2. Provide a command say Alter Subscription ... Replicate Sequences
> > (or something like that) which users can perform before shutdown of
> > the publisher node duri
On Tue, Jun 4, 2024 at 7:40 PM Ashutosh Bapat
wrote:
>
> On Tue, Jun 4, 2024 at 4:27 PM Amit Kapila wrote:
>>
>>
>> 3. Replicate published sequences via walsender at the time of shutdown
>> or incrementally while decoding checkpoint record. The two ways to
&g
On Tue, Jun 4, 2024 at 4:53 PM Bharath Rupireddy
wrote:
>
> On Tue, Jun 4, 2024 at 4:27 PM Amit Kapila wrote:
> >
> > 3. Replicate published sequences via walsender at the time of shutdown
> > or incrementally while decoding checkpoint record. The two ways to
> >
%3DEwZTF5z9_xO9Ms4wsqD88Q%40mail.gmail.com
[3] -
https://www.postgresql.org/message-id/CAA4eK1KR4%3DyALKP0pOdVkqUwoUqD_v7oU3HzY-w0R_EBvgHL2w%40mail.gmail.com
[4] -
https://www.postgresql.org/message-id/12822961-b7de-9d59-dd27-2e3dc3980c7e%40enterprisedb.com
--
With Regards,
Amit Kapila.
> > publishers? Isn't this problematic considering the commit timestamps may
> > go backwards (for a given publisher), which means the conflict
> > resolution is not deterministic (as it depends on how exactly it
> > interleaves)?
> >
I am not able to imagine the cases you are worried about. Can you
please be specific? Is it similar to the case I described in
yesterday's email [1]?
[1] -
https://www.postgresql.org/message-id/CAA4eK1JTMiBOoGqkt%3DaLPLU8Rs45ihbLhXaGHsz8XC76%2BOG3%2BQ%40mail.gmail.com
--
With Regards,
Amit Kapila.
er the resolution method
(last_update_wins) we need to retain Update-1.
On further thinking, the operations on node-1 PN-1 as defined above
seem impossible because one of the Updates needs to wait for the other
to write a commit record. So the commits may happen with LSN1 < LSN2
but with T1 > T2 but they can't be on the same row due to locks. So,
the order of apply should still be consistent. Am, I missing
something?
--
With Regards,
Amit Kapila.
to add WAL read I/O stats also to
> pg_stat_wal. Then, we can also add WALReadFromBuffers stats
> hits/misses there. With this approach, pg_stat_wal can be a one-stop
> view for all the WAL related stats.
>
If possible, let's have all the I/O stats (even for WAL) in
pg_stat_io. Can't we show the WAL data we get from buffers in the hits
column and then have read_bytes or something like that to know the
amount of data read?
--
With Regards,
Amit Kapila.
g about this. It makes sense to
start with something simple and see how it works. I think this can
also help us whether we need to chase a particular BF failure
immediately after committing.
--
With Regards,
Amit Kapila.
On Thu, May 23, 2024 at 8:43 PM Euler Taveira wrote:
>
> On Thu, May 23, 2024, at 5:54 AM, Amit Kapila wrote:
>
>
> Why in the first place do we need to ensure that primary_slot_name is
> active on the primary? You mentioned something related to WAL
> retention
On Wed, May 22, 2024 at 8:46 PM Euler Taveira wrote:
>
> On Wed, May 22, 2024, at 8:19 AM, Amit Kapila wrote:
>
> > v2-0002: not changed
> >
>
> We have added more tries to see if the primary_slot_name becomes
> active but I think it is still fragile because it
On Wed, May 22, 2024 at 8:02 PM Robert Haas wrote:
>
> On Mon, May 20, 2024 at 2:42 AM Amit Kapila wrote:
> > Just to summarize, apart from BF failures for which we had some
> > discussion, I could recall the following open points:
> >
> > 1. After promotion, the pr
e where it can be
helpful for her. For example, retaining publications can help in
creating a bi-directional setup.
--
With Regards,
Amit Kapila.
tion in this tool was to avoid
specifying slots, pubs, etc. for each database. See [1]. We can
probably leave if the same is not important but we never reached the
conclusion of same.
[1] -
https://www.postgresql.org/message-id/CAA4eK1%2Br96SyHYHx7BaTtGX0eviqpbbkSu01MEzwV5b2VFXP6g%40mail.gmail.com
--
With Regards,
Amit Kapila.
.org/message-id/CAA4eK1JJq_ER6Kq_H%3DjKHR75QPRd8y9_D%3DRtYw%3DaPYKMfqLi9A%40mail.gmail.com
[2] -
https://www.postgresql.org/message-id/CAA4eK1LT3Z13Dg6p4Z%2B4adO_EY-ow5CmWfikEmBfL%3DeVrm8CPw%40mail.gmail.com
--
With Regards,
Amit Kapila.
On Fri, May 17, 2024 at 5:25 AM Michael Paquier wrote:
>
> On Thu, May 16, 2024 at 09:00:47AM +0530, Amit Kapila wrote:
> > This can only be a problem if the apply worker generates more LOG
> > entries with the required context but it won't do that unless there i
like that on my own local Linux + EXEC_BACKEND test run
> (sorry I didn't keep the details around). Coincidence?
>
AFAICS, this is the same as one of the two BF failures being discussed
in this thread.
--
With Regards,
Amit Kapila.
-b277-4c13-850a-8ccc04de1406%40eisentraut.org#152dacecfc8f0cf08cbd8ecb79d6d38f
[3] -
https://www.postgresql.org/message-id/CAA4eK1KdCb%2B5sjYu6qCMXXdCX1y_ihr8kFzMozq0%3DP%3DauYxgog%40mail.gmail.com
[4] -
https://www.postgresql.org/message-id/flat/3fa9ef0f-b277-4c13-850a-8ccc04de1406%40eisentraut.org#152dacecfc8f0cf08cbd8ecb79d6d38f
--
With Regards,
Amit Kapila.
On Thu, May 16, 2024 at 3:43 AM Michael Paquier wrote:
>
> On Wed, May 15, 2024 at 05:58:18PM +0530, Amit Kapila wrote:
> > I guess it could be more work if we want to enhance the test for
> > ERRORs other than the primary key violation.
>
> And? You could pass t
n chunks up to io_combine_limit".
>
> Yes, my point is that it is not the number of system calls or system
> call overhead that is the advantage of this patch, but the ability to
> request more of the I/O system in one call, which is not the same as
> system calls.
>
> I can use your wording, but how much prefetching to we enable now?
>
Shouldn't we need to include commit
b5a9b18cd0bc6f0124664999b31a00a264d16913 with this item?
--
With Regards,
Amit Kapila.
below line in the test:
# Check replicated data
my $res =
$node_subscriber->safe_psql('postgres', "SELECT
count(*) FROM tbl");
is($res, $expected, $msg);
--
With Regards,
Amit Kapila.
it, they are transferred to topmost transaction's RB.
>
I don't think they are transferred to topmost transaction's RB. We
perform a k-way merge between transactions/subtransactions to retrieve
the changes. See comments: "Support for efficiently iterating over a
transaction's and its subtransactions' changes..." in reorderbuffer.c
--
With Regards,
Amit Kapila.
d a mitigation.
>
In PG-14, we have added a feature in logical replication to stream
long in-progress transactions which should reduce spilling to a good
extent. You might want to try that.
--
With Regards,
Amit Kapila.
> to bgworkers whether or not they set proc->roleId.
>
Agreed.
--
With Regards,
Amit Kapila.
On Tue, Apr 30, 2024 at 12:04 PM Amit Kapila wrote:
>
> On Mon, Apr 29, 2024 at 5:28 PM Amit Kapila wrote:
> >
> > On Mon, Apr 29, 2024 at 5:23 PM Euler Taveira wrote:
> >
>
> I was trying to test this utility when 'sync_replication_slots' is on
> and it ge
On Mon, Apr 29, 2024 at 5:28 PM Amit Kapila wrote:
>
> On Mon, Apr 29, 2024 at 5:23 PM Euler Taveira wrote:
>
I was trying to test this utility when 'sync_replication_slots' is on
and it gets in an ERROR loop [1] and never finishes. Please find the
postgresql.auto used on the standby
On Tue, Apr 30, 2024 at 2:58 AM Noah Misch wrote:
>
> On Mon, Apr 29, 2024 at 10:18:35AM +0530, Amit Kapila wrote:
> > On Mon, Apr 22, 2024 at 9:56 PM Noah Misch wrote:
>
> > 3a9b18b309 didn't change the docs of pg_terminate_backend and whatever
> > is mentioned w
On Mon, Apr 29, 2024 at 5:23 PM Euler Taveira wrote:
>
> On Mon, Apr 29, 2024, at 6:56 AM, Amit Kapila wrote:
>
> On Wed, Mar 27, 2024 at 1:47 AM Euler Taveira wrote:
> >
> > On Tue, Mar 26, 2024, at 4:12 PM, Tomas Vondra wrote:
> >
> > Perhaps I'm missing som
MPTS (that was renamed to
> NUM_ATTEMPTS in the first patch). See second patch.
>
How can we guarantee that the slot can become active after these many
attempts? It still could be possible that on some slow machines it
didn't get activated even after NUM_ATTEMPTS. BTW, in the first place,
why
ther than
indirectly verifying the same (by checking pg_stat_wal_receiver) as we
are doing currently.
--
With Regards,
Amit Kapila.
On Mon, Apr 22, 2024 at 9:56 PM Noah Misch wrote:
>
> On Mon, Apr 15, 2024 at 11:17:54AM +0530, Amit Kapila wrote:
> > On Thu, Apr 11, 2024 at 6:58 PM Kirill Reshke
> > wrote:
> > >
> > > While working on [0] i have noticed this comment in
>
as active,
> > which could confuse users. Do we want to somehow deal with it?
>
> Yes. As long as the temporary slot is lying unused holding up
> resources for more than the specified
> replication_slot_inactive_timeout, it is bound to get invalidated.
> This keeps behaviour consistent and less-confusing to the users.
>
Agreed. We may want to add something in the docs for this to avoid
confusion with the active flag.
--
With Regards,
Amit Kapila.
On Wed, Apr 24, 2024 at 10:28 AM shveta malik wrote:
>
> Modified the logic to remove only synced temporary slots during
> SQL-function exit.
>
> Please find v11 with above changes.
>
LGTM, so pushed!
--
With Regards,
Amit Kapila.
h,
> > v7-0001-Table-sync-missed-due-to-race-condition-in-subscr_PG15.patch
> > applies for PG15 branch.
>
> Thanks, I have verified that the patches can be applied cleanly and fix the
> issue on each branch. The regression test can also pass after applying the
> patch
> on my machine.
>
Pushed.
--
With Regards,
Amit Kapila.
On Tue, Apr 23, 2024 at 4:53 PM Amit Kapila wrote:
>
> On Wed, Mar 13, 2024 at 11:59 AM vignesh C wrote:
> >
> > On Wed, 13 Mar 2024 at 10:12, Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > >
> > > For 0002, instead of avoid resetting the latch,
doesn't fit
> > well.
>
> Thanks for reviewing the patch, the attached v6 patch has the changes
> for the same.
>
v6_0001* looks good to me. This should be backpatched unless you or
others think otherwise.
--
With Regards,
Amit Kapila.
> > > comments.
>
> Thanks!
>
> > Tested the patch, works well.
>
> Same here.
>
Pushed!
--
With Regards,
Amit Kapila.
the issues reported in the thread you referred to has the same
symptoms [1]. I'll review and analyze your proposal.
[1] -
https://www.postgresql.org/message-id/858a7622-2c81-1687-d1df-1322dfcb2e72%40gmail.com
--
With Regards,
Amit Kapila.
to wake up
WaitForReplicationWorkerAttach() say condition variable? The current
proposal can fix the issue but looks bit adhoc.
--
With Regards,
Amit Kapila.
main as-is after
promotion and we need to document for users to remove such slots. Now,
we can do that if we want but I think it is better to clean up such
slots rather than putting the onus on users to remove them after
promotion.
--
With Regards,
Amit Kapila.
On Fri, Apr 19, 2024 at 1:52 PM shveta malik wrote:
>
> Please find v9 with the above comments addressed.
>
I have made minor modifications in the comments and a function name.
Please see the attached top-up patch. Apart from this, the patch looks
good to me.
--
With Regards,
Amit Kap
ounds logical to me and consistent with ALTER
SUBSCRIPTION. BTW, IIUC, you are referring to: "When altering the
slot_name, the failover and two_phase property values of the named
slot may differ from the counterpart failover and two_phase parameters
specified in the subscription. When creating the slot, ensure the slot
properties failover and two_phase match their counterpart parameters
of the subscription." in docs [1], right?
--
With Regards,
Amit Kapila.
On Tue, Apr 16, 2024 at 12:03 PM Bertrand Drouvot
wrote:
>
> On Tue, Apr 16, 2024 at 08:21:04AM +0530, Amit Kapila wrote:
>
> > There is no clear use case for allowing them in parallel and I feel it
> > would add more confusion when it can work sometimes but not other
>
1 - 100 of 5982 matches
Mail list logo
