public inbox for [email protected]
help / color / mirror / Atom feedFrom: Japin Li <[email protected]>
To: Dean Rasheed <[email protected]>
Cc: Kirk Wolak <[email protected]>
Cc: Pavel Stehule <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Global temporary tables
Date: Tue, 07 Jul 2026 09:09:44 +0800
Message-ID: <SY7PR01MB10921B2B3A1AEAEAC706CA865B6F02@SY7PR01MB10921.ausprd01.prod.outlook.com> (raw)
In-Reply-To: <CAEZATCXYqx_aiDHWn9qUB8QGjE=dMzUEt_9WKjyHvDQFFf0U4w@mail.gmail.com>
References: <CAEZATCU_goy9GiN75Rhqwg8=AEHrujYdf+cF9ORMGg98Tc44YA@mail.gmail.com>
<[email protected]>
<CAFj8pRDbGis5SPwaoGjyeVd9K0ynabEXfe-C3RzOF+d46WLOyA@mail.gmail.com>
<CAEZATCU0fg2JTYCJoY1m3FGmUMoDUHzDsQ9JExujWRrHz68sUg@mail.gmail.com>
<CAEZATCUdg2tGj1OWbSWMCubrQdXpGirQkdXNgQBgGf-UQG2hGA@mail.gmail.com>
<CACLU5mTSDkxr7R9MpXqO8Fi-TL-V+JO_f4vQFMU92OhhDYTtww@mail.gmail.com>
<CAEZATCUqP6iu0QcuZ+718iz630hsfQLdqZdhW=B3+vz6iOuq9Q@mail.gmail.com>
<SY7PR01MB1092104CDB43530A408012EAFB6F62@SY7PR01MB10921.ausprd01.prod.outlook.com>
<CAEZATCX+WMWxxT-He2r24Y96ZBbx1Z2b6zFDGm9gHjjYWviZ=Q@mail.gmail.com>
<SY7PR01MB10921AF179BFC56D15C70894FB6F12@SY7PR01MB10921.ausprd01.prod.outlook.com>
<CAEZATCXYqx_aiDHWn9qUB8QGjE=dMzUEt_9WKjyHvDQFFf0U4w@mail.gmail.com>
On Mon, 06 Jul 2026 at 11:12, Dean Rasheed <[email protected]> wrote:
> On Mon, 6 Jul 2026 at 09:35, Japin Li <[email protected]> wrote:
>>
>> During testing of the v6 patch, I observed that sequences belonging to global
>> temporary tables defined with ON COMMIT DELETE ROWS are not reset after the
>> transaction commits.
>>
>> postgres=# BEGIN;
>> postgres=*# INSERT INTO gtt_delete (info) VALUES ('row 1');
>> postgres=*# SELECT * FROM gtt_delete;
>> postgres=*# SELECT currval('gtt_delete_id_seq');
>> postgres=*# END;
>> postgres=# SELECT currval('gtt_delete_id_seq'); -- The sequence still exists.
>> currval
>> ---------
>> 1
>> (1 row)
>> postgres=*# END;
>> COMMIT
>> postgres=# SELECT currval('gtt_delete_id_seq'); -- The sequence doesn't reset.
>> currval
>> ---------
>> 2
>> (1 row)
>>
>> The sequence doesn't reset after commit – is this intended?
>>
>
> I think that's what I would expect. This matches what happens with
> normal (local) temp tables -- sequences are not reset after commit (or
> rollback, for that matter).
>
Thanks for the explanation! I hadn't noticed this before.
> Regarding pg_class.reloncommit, 'p' (preserve) seems correct for a
> sequence attached to a GTT with ON COMMIT DELETE ROWS, because the
> sequence data is preserved. For indexes, not so much, because the
> index data is deleted on commit. I guess it could be NULL for anything
> that's not a table.
>
+1 for setting it to NULL for non‑table objects, since CREATE INDEX and
CREATE SEQUENCE do not support the ON COMMIT clause.
> Andrew's patch uses a reloption to store the table's on-commit state,
> but to me that doesn't seem quite right, and it requires special code
> to mark it as a "private" reloption that is non-user-editable. It does
> simplify the question of what to do for non-tables though. What do
> others think?
>
I'm on board with your approach to the on-commit state.
> Regards,
> Dean
--
Regards,
Japin Li
ChengDu WenWu Information Technology Co., Ltd.
view thread (492+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Global temporary tables
In-Reply-To: <SY7PR01MB10921B2B3A1AEAEAC706CA865B6F02@SY7PR01MB10921.ausprd01.prod.outlook.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox