On Thu, Jan 18, 2024 at 5:18 AM Andrey Borodin <x4...@yandex-team.ru> wrote:
> Current patch version attached. I've addressed all other requests: > function renames, aliases, multiple functions instead of optional params, > cleaner catalog definitions, not throwing error when [var,ver,time] value > is unknown. > What is left: deal with timezones, improve documentation. > I've done a test of the v10 patch, and ran into an interesting behavior when passing in a timestamp to the function (which, as a side note, is actually very useful to have as a feature, to support creating time-based range partitions on UUIDv7 fields): postgres=# SELECT uuid_extract_time(uuidv7()); uuid_extract_time --------------------------- 2024-01-18 18:49:00.01-08 (1 row) postgres=# SELECT uuid_extract_time(uuidv7('2024-04-01')); uuid_extract_time ------------------------ 2024-04-01 00:00:00-07 (1 row) postgres=# SELECT uuid_extract_time(uuidv7()); uuid_extract_time ------------------------ 2024-04-01 00:00:00-07 (1 row) Note how calling the uuidv7 function again after having called it with a fixed future timestamp, returns the future timestamp, even though it should return the current time. I believe this is caused by incorrectly re-using the cached previous_timestamp. In the second call here (with a fixed future timestamp), we end up setting ts and tms to 2024-04-01, with increment_counter = false, which leads us to set previous_timestamp to the passed in timestamp (else branch of the second if in uuidv7). When we then call the function again without an argument, we end up getting a new timestamp from gettimeofday, but because we try to detect backwards leaps, we set increment_counter to true, and thus end up reusing the previous (future) timestamp here: /* protection from leap backward */ tms = previous_timestamp; Not sure how to fix this, but clearly something is amiss here. Thanks, Lukas -- Lukas Fittl