From: | Marc Cousin <cousinmarc(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Steve Singer <ssinger(at)ca(dot)afilias(dot)info>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Review: rollback sequence reset for TRUNCATE ... RESTART IDENTITY |
Date: | 2010-11-17 20:00:50 |
Message-ID: | 201011172100.50909.cousinmarc@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
The Wednesday 17 November 2010 19:41:19, Tom Lane wrote :
> Marc Cousin <cousinmarc(at)gmail(dot)com> writes:
> >>> - Does the feature work as advertised?
> >>>
> >>> Yes. It works consistently, isn't fooled by savepoints or multiple
> >>> serials in a table, or concurrent transactions
>
> I think there's a rather nasty problem here, which is what to do with
> the cached nextval/currval state. As submitted, the patch does the same
> thing as ALTER SEQUENCE RESTART (to wit, clear any cached unissued
> nextval values, but don't touch currval) at the time of resetting the
> sequence. That's fine, but what if the transaction later rolls back?
> The cached state is untouched by rollback, so if the transaction had
> done any nextval()s meanwhile, the cache will be out of step with the
> rolled-back sequence contents.
Yes, I completely missed testing with non default cache value. And it fails,
of course, some values are generated a second time twice after a rollback
>
> We never had to worry about this before because sequence operations
> didn't roll back, by definition. If we're going to add a situation
> where they do roll back, we need to consider the case.
>
> I think we can arrange to clear cached unissued values on the next
> attempt to nextval() the sequence, by dint of adding the relfilenode
> to SeqTable entries and clearing cached state whenever we note that
> it doesn't match the current relfilenode of the sequence. However,
> I'm unsure what ought to happen to currval. It doesn't seem too
> practical to try to roll it back to its pre-transaction value.
> Should we leave it alone (ie, possibly reflecting a value that was
> assigned inside the failed transaction)? The other alternative would
> be to clear it as though nextval had never been issued at all in the
> session.
Should currval really be used after a failed transaction ? Right now, we can
have a value that has been generated inside a rollbacked transaction too. I'd
vote for leave it alone.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-11-17 20:03:04 | Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running |
Previous Message | Tom Lane | 2010-11-17 19:55:33 | Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running |