On 1/25/22 10:18, Peter Eisentraut wrote:
On 15.01.22 23:57, Tomas Vondra wrote:
This approach (and also my previous proposal) seems to assume that
the value returned from nextval() should not be used until the
transaction executing that nextval() has been committed successfully.
But I'm not
On 15.01.22 23:57, Tomas Vondra wrote:
This approach (and also my previous proposal) seems to assume that the
value returned from nextval() should not be used until the transaction
executing that nextval() has been committed successfully. But I'm not
sure how many applications follow this ass
On 1/15/22 06:12, Fujii Masao wrote:
On 2022/01/12 1:07, Tomas Vondra wrote:
I explored the idea of using page LSN a bit
Many thanks!
The patch from 22/12 simply checks if the change should/would wait for
sync replica, and if yes it WAL-logs the sequence increment. There's a
couple proble
On 2022/01/12 1:07, Tomas Vondra wrote:
I explored the idea of using page LSN a bit
Many thanks!
The patch from 22/12 simply checks if the change should/would wait for
sync replica, and if yes it WAL-logs the sequence increment. There's a
couple problems with this, unfortunately:
Yes, y
On 12/24/21 11:40, Tomas Vondra wrote:
>
> ...
>
> FWIW I plan to explore the idea of looking at sequence page LSN, and
> flushing up to that position.
>
So, I explored the page LSN idea, and it seems to be working pretty
nicely. There still is some impact on the workload doing just nextval
cal
On 12/22/21 18:50, Fujii Masao wrote:
>
>
> On 2021/12/22 21:11, Tomas Vondra wrote:
>> Interesting idea, but I think it has a couple of issues :-(
>
> Thanks for the review!
>
>> 1) We'd need to know the LSN of the last WAL record for any given
>> sequence, and we'd need to communicate that
út 28. 12. 2021 v 9:53 odesílatel Sascha Kuhl
napsal:
>
>
> Pavel Stehule schrieb am Di., 28. Dez. 2021,
> 09:51:
>
>> Hi
>>
>> út 28. 12. 2021 v 9:28 odesílatel Sascha Kuhl
>> napsal:
>>
>>> Sequence validation by step, in total is great. If the sequence is
>>> Familie or professional, does it
Pavel Stehule schrieb am Di., 28. Dez. 2021,
09:51:
> Hi
>
> út 28. 12. 2021 v 9:28 odesílatel Sascha Kuhl
> napsal:
>
>> Sequence validation by step, in total is great. If the sequence is
>> Familie or professional, does it make sense to a have a total validation by
>> an expert. I can only say
Hi
út 28. 12. 2021 v 9:28 odesílatel Sascha Kuhl
napsal:
> Sequence validation by step, in total is great. If the sequence is Familie
> or professional, does it make sense to a have a total validation by an
> expert. I can only say true by chi square Networks, but would a medical
> opinion be an
Sequence validation by step, in total is great. If the sequence is Familie
or professional, does it make sense to a have a total validation by an
expert. I can only say true by chi square Networks, but would a medical
opinion be an improvement?
Fujii Masao schrieb am Di., 28. Dez. 2021,
07:56:
>
On 2021/12/24 19:40, Tomas Vondra wrote:
Maybe, but what would such workload look like? Based on the tests I did, such
workload probably can't generate any WAL. The amount of WAL added by the change
is tiny, the regression is caused by having to flush WAL.
The only plausible workload I can
On 12/27/21 21:24, Peter Eisentraut wrote:
On 24.12.21 09:04, Kyotaro Horiguchi wrote:
Still, as Fujii-san concerns, I'm afraid that some people may suffer
the degradation the patch causes. I wonder it is acceptable to get
back the previous behavior by exposing SEQ_LOG_VALS itself or a
boolean
On 24.12.21 09:04, Kyotaro Horiguchi wrote:
Still, as Fujii-san concerns, I'm afraid that some people may suffer
the degradation the patch causes. I wonder it is acceptable to get
back the previous behavior by exposing SEQ_LOG_VALS itself or a
boolean to do that, as a 'not-recommended-to-use' va
On 12/24/21 09:04, Kyotaro Horiguchi wrote:
...
So, strictly speaking, that is a violation of the constraint I
mentioned regardless whether the transaction is committed or
not. However we have technical limitations as below.
I don't follow. What violates what?
If the transaction commits (a
At Fri, 24 Dec 2021 08:23:13 +0100, Tomas Vondra
wrote in
>
>
> On 12/24/21 06:37, Kyotaro Horiguchi wrote:
> > At Thu, 23 Dec 2021 19:50:22 +0100, Tomas Vondra
> > wrote in
> >> On 12/23/21 15:42, Fujii Masao wrote:
> >>> On 2021/12/23 3:49, Tomas Vondra wrote:
> Attached is a patch twe
On 12/24/21 06:37, Kyotaro Horiguchi wrote:
At Thu, 23 Dec 2021 19:50:22 +0100, Tomas Vondra
wrote in
On 12/23/21 15:42, Fujii Masao wrote:
On 2021/12/23 3:49, Tomas Vondra wrote:
Attached is a patch tweaking WAL logging - in wal_level=minimal we do
the same thing as now, in higher levels
At Thu, 23 Dec 2021 19:50:22 +0100, Tomas Vondra
wrote in
> On 12/23/21 15:42, Fujii Masao wrote:
> > On 2021/12/23 3:49, Tomas Vondra wrote:
> >> Attached is a patch tweaking WAL logging - in wal_level=minimal we do
> >> the same thing as now, in higher levels we log every sequence fetch.
> > T
On 12/23/21 15:42, Fujii Masao wrote:
On 2021/12/23 3:49, Tomas Vondra wrote:
Attached is a patch tweaking WAL logging - in wal_level=minimal we do
the same thing as now, in higher levels we log every sequence fetch.
Thanks for the patch!
With the patch, I found that the regression test for
On 2021/12/23 3:49, Tomas Vondra wrote:
Attached is a patch tweaking WAL logging - in wal_level=minimal we do the same
thing as now, in higher levels we log every sequence fetch.
Thanks for the patch!
With the patch, I found that the regression test for sequences failed.
+
On 12/22/21 18:50, Fujii Masao wrote:
On 2021/12/22 21:11, Tomas Vondra wrote:
Interesting idea, but I think it has a couple of issues :-(
Thanks for the review!
1) We'd need to know the LSN of the last WAL record for any given
sequence, and we'd need to communicate that between backends s
On 12/21/21 03:49, Tomas Vondra wrote:
On 12/21/21 02:01, Tom Lane wrote:
Tomas Vondra writes:
OK, I did a quick test with two very simple benchmarks - simple select
from a sequence, and 'pgbench -N' on scale 1. Benchmark was on current
master, patched means SEQ_LOG_VALS was set to 1.
But
On 2021/12/22 21:11, Tomas Vondra wrote:
Interesting idea, but I think it has a couple of issues :-(
Thanks for the review!
1) We'd need to know the LSN of the last WAL record for any given sequence, and
we'd need to communicate that between backends somehow. Which seems rather
tricky to
On 12/22/21 05:56, Fujii Masao wrote:
On 2021/12/22 10:57, Tomas Vondra wrote:
On 12/19/21 04:03, Amit Kapila wrote:
On Sat, Dec 18, 2021 at 7:24 AM Tomas Vondra
wrote:
while working on logical decoding of sequences, I ran into an issue
with
nextval() in a transaction that rolls bac
On 2021/12/22 10:57, Tomas Vondra wrote:
On 12/19/21 04:03, Amit Kapila wrote:
On Sat, Dec 18, 2021 at 7:24 AM Tomas Vondra
wrote:
while working on logical decoding of sequences, I ran into an issue with
nextval() in a transaction that rolls back, described in [1]. But after
thinking abo
On 12/19/21 04:03, Amit Kapila wrote:
On Sat, Dec 18, 2021 at 7:24 AM Tomas Vondra
wrote:
while working on logical decoding of sequences, I ran into an issue with
nextval() in a transaction that rolls back, described in [1]. But after
thinking about it a bit more (and chatting with Petr Jel
On 12/21/21 02:01, Tom Lane wrote:
Tomas Vondra writes:
OK, I did a quick test with two very simple benchmarks - simple select
from a sequence, and 'pgbench -N' on scale 1. Benchmark was on current
master, patched means SEQ_LOG_VALS was set to 1.
But ... pgbench -N doesn't use sequences at al
Tomas Vondra writes:
> OK, I did a quick test with two very simple benchmarks - simple select
> from a sequence, and 'pgbench -N' on scale 1. Benchmark was on current
> master, patched means SEQ_LOG_VALS was set to 1.
But ... pgbench -N doesn't use sequences at all, does it?
Probably inserts i
On 12/20/21 17:40, Tomas Vondra wrote:
On 12/20/21 15:31, Peter Eisentraut wrote:
On 18.12.21 22:48, Tomas Vondra wrote:
What do you mean by "not caching unused sequence numbers"? Reducing
SEQ_LOG_VALS to 1, i.e. WAL-logging every sequence increment?
That'd work, but I wonder how significant
On 12/20/21 15:31, Peter Eisentraut wrote:
On 18.12.21 22:48, Tomas Vondra wrote:
What do you mean by "not caching unused sequence numbers"? Reducing
SEQ_LOG_VALS to 1, i.e. WAL-logging every sequence increment?
That'd work, but I wonder how significant the impact will be. It'd bet
it hurts t
On 18.12.21 22:48, Tomas Vondra wrote:
What do you mean by "not caching unused sequence numbers"? Reducing
SEQ_LOG_VALS to 1, i.e. WAL-logging every sequence increment?
That'd work, but I wonder how significant the impact will be. It'd bet
it hurts the patch adding logical decoding of sequence
On Sat, Dec 18, 2021 at 7:24 AM Tomas Vondra
wrote:
>
> while working on logical decoding of sequences, I ran into an issue with
> nextval() in a transaction that rolls back, described in [1]. But after
> thinking about it a bit more (and chatting with Petr Jelinek), I think
> this issue affects p
Tomas Vondra writes:
> What do you mean by "not caching unused sequence numbers"? Reducing
> SEQ_LOG_VALS to 1, i.e. WAL-logging every sequence increment?
Right.
> That'd work, but I wonder how significant the impact will be.
As I said, we've accepted worse in order to have stable replication
On 12/18/21 22:27, Tom Lane wrote:
Tomas Vondra writes:
Here's a PoC demonstrating this idea. I'm not convinced it's the right
way to deal with this - it surely seems more like a duct tape fix than a
clean solution. But it does the trick.
I was imagining something a whole lot simpler, like
Tomas Vondra writes:
> Here's a PoC demonstrating this idea. I'm not convinced it's the right
> way to deal with this - it surely seems more like a duct tape fix than a
> clean solution. But it does the trick.
I was imagining something a whole lot simpler, like "don't try to
cache unused sequen
On 12/18/21 07:00, Tomas Vondra wrote:
On 12/18/21 05:52, Tom Lane wrote:
Tomas Vondra writes:
The problem is exactly the same as in [1] - the aborted transaction
generated WAL, but RecordTransactionAbort() ignores that and does not
update LogwrtResult.Write, with the reasoning that aborte
On 12/18/21 05:52, Tom Lane wrote:
Tomas Vondra writes:
The problem is exactly the same as in [1] - the aborted transaction
generated WAL, but RecordTransactionAbort() ignores that and does not
update LogwrtResult.Write, with the reasoning that aborted transactions
do not matter. But sequenc
Tomas Vondra writes:
> The problem is exactly the same as in [1] - the aborted transaction
> generated WAL, but RecordTransactionAbort() ignores that and does not
> update LogwrtResult.Write, with the reasoning that aborted transactions
> do not matter. But sequences violate that, because we on
Hi,
while working on logical decoding of sequences, I ran into an issue with
nextval() in a transaction that rolls back, described in [1]. But after
thinking about it a bit more (and chatting with Petr Jelinek), I think
this issue affects physical sync replication too.
Imagine you have a pri
38 matches
Mail list logo
