| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Peter Geoghegan <pg(at)heroku(dot)com>, Casey Wireman <cwire4(at)gmail(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #14126: INSERT ON CONFLICT DO NOTHING auto increments serial primary key when no insert happens. |
| Date: | 2016-05-07 15:07:11 |
| Message-ID: | 2186.1462633631@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Francisco Olarte <folarte(at)peoplecall(dot)com> writes:
> But I've read the docs and noticed the warning:
> "Important: To avoid blocking concurrent transactions that obtain
> numbers from the same sequence, a nextval operation is never rolled
> back; that is, once a value has been fetched it is considered used,
> even if the transaction that did the nextval later aborts. This means
> that aborted transactions might leave unused "holes" in the sequence
> of assigned values."
> Which may lead people to think only rollbacks 'burn' numbers.
Yeah, good point. I'll do some wordsmithing on that.
> 2.- IIRC using cache>1 can lead to obtain sequence numbers out of
> order is using the same sequence in two different sessions. I assumed
> this is normal and do not have a problem with it, but people may get
> surprised by it, so I think a note there could help.
I think that's explained already, no?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Francisco Olarte | 2016-05-07 16:43:17 | Re: BUG #14126: INSERT ON CONFLICT DO NOTHING auto increments serial primary key when no insert happens. |
| Previous Message | digoal | 2016-05-07 14:53:02 | BUG #14129: Why GIN index not use index scan? |