| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Sequence Access Methods, round two |
| Date: | 2024-02-26 08:10:45 |
| Message-ID: | ZdxHhRlgam-HWXYl@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 22, 2024 at 05:36:00PM +0100, Tomas Vondra wrote:
> 0002, 0003
> ------------
> seems fine, cosmetic changes
Thanks, I've applied these two for now. I'll reply to the rest
tomorrow or so.
By the way, I am really wondering if the update of elm->increment in
nextval_internal() should be treated as a bug? In the "fetch" cache
if a sequence does not use cycle, we may fail when reaching the upper
or lower bound for respectively an ascending or descending sequence,
while still keeping what could be an incorrect value if values are
cached on a follow-up nextval_internal call?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tender Wang | 2024-02-26 08:14:39 | Re: "type with xxxx does not exist" when doing ExecMemoize() |
| Previous Message | Julien Rouhaud | 2024-02-26 07:55:04 | Re: RFC: Logging plan of the running query |