Laurenz Albe writes:
> On Tue, 2021-11-23 at 16:41 -0500, Tom Lane wrote:
>> A bit of polishing later, maybe like the attached.
> That looks good to me.
Pushed, thanks.
regards, tom lane
On Tue, 2021-11-23 at 16:41 -0500, Tom Lane wrote:
> I wrote:
> > I wonder though if we shouldn't try to improve the existing text.
> > The phrasing "never rolled back" seems like it's too easily
> > misinterpreted. Maybe rewrite the block like
> > ...
>
> A bit of polishing later, maybe like th
>
>
> You could say that that's the same rookie error as relying on the
> persistence of any other uncommitted DML ...
>
IIUC, This is not the same as uncommitted DML exactly. For any
uncommitted
DML, it is a rollback for sure. But as for sequence, The xmax is not
changed
during sequence's valu
On 11/23/21, 1:41 PM, "Tom Lane" wrote:
> I wrote:
>> I wonder though if we shouldn't try to improve the existing text.
>> The phrasing "never rolled back" seems like it's too easily
>> misinterpreted. Maybe rewrite the block like
>> ...
>
> A bit of polishing later, maybe like the attached.
Th
I wrote:
> I wonder though if we shouldn't try to improve the existing text.
> The phrasing "never rolled back" seems like it's too easily
> misinterpreted. Maybe rewrite the block like
> ...
A bit of polishing later, maybe like the attached.
regards, tom lane
diff --gi
Tomas Vondra writes:
> I see Tom speculated we may not flush WAL if a transaction only does
> nextval() in that other thread, but I don't think that's true. AFAICS if
> the nextval() call writes stuff to WAL, the RecordTransactionCommit will
> have wrote_xlog=true and valid XID. And so it'll do th
On 11/23/21 05:49, Andy Fan wrote:
>
> > I think at this thread[1], which claimed to get this issue even after
> > commit, I haven't tried it myself though.
> >
> > [1]
>
> https://www.postgresql.org/message-id/flat/ea6485e3-98d0-24a7-094c-87f9d5f9b18f%40amazon.com#4cfe7217c82
>
>
> > I think at this thread[1], which claimed to get this issue even after
> > commit, I haven't tried it myself though.
> >
> > [1]
> https://www.postgresql.org/message-id/flat/ea6485e3-98d0-24a7-094c-87f9d5f9b18f%40amazon.com#4cfe7217c829419b769339465e8c2915
> >
>
> I did try, and I haven't be
On 11/23/21 5:22 AM, Dilip Kumar wrote:
> On Tue, Nov 23, 2021 at 9:30 AM Tomas Vondra
> wrote:
>
>> On 11/22/21 9:42 PM, Jeremy Schneider wrote:
>>> On 11/22/21 12:31, Tom Lane wrote:
"Bossart, Nathan" writes:
> I periodically hear rumblings about this behavior as well. At the
> v
On Tue, Nov 23, 2021 at 9:30 AM Tomas Vondra
wrote:
> On 11/22/21 9:42 PM, Jeremy Schneider wrote:
> > On 11/22/21 12:31, Tom Lane wrote:
> >> "Bossart, Nathan" writes:
> >>> I periodically hear rumblings about this behavior as well. At the
> >>> very least, it certainly ought to be documented
On 11/22/21 9:42 PM, Jeremy Schneider wrote:
> On 11/22/21 12:31, Tom Lane wrote:
>> "Bossart, Nathan" writes:
>>> I periodically hear rumblings about this behavior as well. At the
>>> very least, it certainly ought to be documented if it isn't yet. I
>>> wouldn't mind trying my hand at that.
On Tue, Nov 23, 2021 at 4:31 AM Tom Lane wrote:
> "Bossart, Nathan" writes:
> > I periodically hear rumblings about this behavior as well. At the
> > very least, it certainly ought to be documented if it isn't yet. I
> > wouldn't mind trying my hand at that. Perhaps we could also add a new
>
On 11/22/21 12:31, Tom Lane wrote:
> "Bossart, Nathan" writes:
>> I periodically hear rumblings about this behavior as well. At the
>> very least, it certainly ought to be documented if it isn't yet. I
>> wouldn't mind trying my hand at that. Perhaps we could also add a new
>> configuration par
"Bossart, Nathan" writes:
> I periodically hear rumblings about this behavior as well. At the
> very least, it certainly ought to be documented if it isn't yet. I
> wouldn't mind trying my hand at that. Perhaps we could also add a new
> configuration parameter if users really want to take the p
On 11/22/21, 5:10 AM, "Laurenz Albe" wrote:
> On Mon, 2021-11-22 at 15:43 +0800, Andy Fan wrote:
>> The performance argument was expected before this writing. If we look at the
>> nextval_interval more carefully, we can find it would not flush the xlog
>> every
>> time even the sequence's cachesi
On Mon, 2021-11-22 at 15:43 +0800, Andy Fan wrote:
> > > The reason is because we never flush the xlog for the nextval_internal
> > > for the above case. So if
> > > the system crashes, there is nothing to redo from. It can be fixed
> > > with the following online change
> > > code.
> > >
> > > @
> > The reason is because we never flush the xlog for the nextval_internal
> > for the above case. So if
> > the system crashes, there is nothing to redo from. It can be fixed
> > with the following online change
> > code.
> >
> > @@ -810,6 +810,8 @@ nextval_internal(Oid relid, bool check_permissi
On Mon, 2021-11-22 at 14:57 +0800, Andy Fan wrote:
> Should we guarantee the sequence's nextval should never be rolled back
> even in a crashed recovery case?
> I can produce the rollback in the following case:
>
> Session 1:
> CREATE SEQUENCE s;
> BEGIN;
> SELECT nextval('s'); \watch 0.01
>
> Se
On Sunday, November 21, 2021, Andy Fan wrote:
>
> Should we guarantee the sequence's nextval should never be rolled back
> even in a crashed recovery case?
> I can produce the rollback in the following case:
>
This seems to be the same observation that was made a little over a year
ago.
https://
Hi:
Should we guarantee the sequence's nextval should never be rolled back
even in a crashed recovery case?
I can produce the rollback in the following case:
Session 1:
CREATE SEQUENCE s;
BEGIN;
SELECT nextval('s'); \watch 0.01
Session 2:
kill -9 {sess1.pid}
After the restart, the nextval('s')
20 matches
Mail list logo
