> I think this LSN is simply LSN where crash recovery ends...
Yes, you are right and we come back to :
> 1. Allow checking standby sync before making data visible after crash recovery
Best regards,
Mikhail.
> On 14 May 2025, at 05:33, Amit Kapila wrote:
>
>> It might not necessarily be a flag—it could be some LSN value instead.
>> Also, it's not just about a "new transaction," but about any new
>> snapshot that could see data not yet replicated to the synchronous
>> standby.
>>
>
> Sounds reaso
On Wed, May 14, 2025 at 2:15 AM Mihail Nikalayeu
wrote:
>
> > One idea to solve this problem could be that whenever we cancel
> > sync_rep_wait, we set some system-wide flag that indicates that any
> > new transaction must ensure that all the current data is replicated to
> > the synchronous stand
Hello, everyone!
> On Mon, 12 May 2025 at 18:42, Andrey Borodin wrote:
>> >> Problem: user might try to cancel locally committed transaction and if we
>> >> do so we will show non-replicated data as committed. This leads to
>> >> loosing data with UPSERTs.
>> > >
>> > > Could you explain why sp
Hi, dropping in my 2 cents here.
On Mon, 12 May 2025 at 18:42, Andrey Borodin wrote:
> >> Problem: user might try to cancel locally committed transaction and if we
> >> do so we will show non-replicated data as committed. This leads to loosing
> >> data with UPSERTs.
> >
> > Could you explain w
> On 6 May 2025, at 12:00, Matthias van de Meent
> wrote:
>
> On Fri, 2 May 2025 at 15:00, Andrey Borodin wrote:
>>
>> Hi hackers!
>>
>> I want to revive attempts to fix some old edge cases of physical quorum
>> replication.
>>
>> Please find attached draft patches that demonstrate ideas.
On Fri, May 2, 2025 at 6:30 PM Andrey Borodin wrote:
>
>
> I want to revive attempts to fix some old edge cases of physical quorum
> replication.
>
> Please find attached draft patches that demonstrate ideas. These patches are
> not actually proposed code changes, I rather want to have a design
On Fri, May 2, 2025 at 6:30 PM Andrey Borodin wrote:
>
> 3. Allow reading LSN written by walreciever, but not flushed yet
>
> Problem: if we have synchronous_standby_names = ANY(node1,node2), node2 might
> be ahead of node1 by flush LSN, but before by written LSN. If we do a
> failover we choose
On Fri, 2 May 2025 at 15:00, Andrey Borodin wrote:
>
> Hi hackers!
>
> I want to revive attempts to fix some old edge cases of physical quorum
> replication.
>
> Please find attached draft patches that demonstrate ideas. These patches are
> not actually proposed code changes, I rather want to ha
Hi hackers!
I want to revive attempts to fix some old edge cases of physical quorum
replication.
Please find attached draft patches that demonstrate ideas. These patches are
not actually proposed code changes, I rather want to have a design consensus
first.
1. Allow checking standby sync befo
10 matches
Mail list logo
