From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Euler Taveira <euler(at)eulerto(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: improve performance of pg_dump with many sequences |
Date: | 2024-07-18 18:22:10 |
Message-ID: | ZpldUoP0XjHszExF@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 17, 2024 at 11:58:21PM -0400, Tom Lane wrote:
> ... okay, I lied, I looked at the patch. Why are you testing
>
> + if (pg_class_aclcheck(relid, GetUserId(), ACL_SELECT | ACL_USAGE) == ACLCHECK_OK &&
>
> ? This is a substitute for a SELECT from the sequence and it seems
> like it ought to demand exactly the same privilege as SELECT.
> (If you want to get more technical, USAGE allows nextval() which
> gives strictly less information than what this exposes; that's why
> we're here after all.) So there is a difference in the privilege
> levels, which is another reason for not combining this with
> pg_sequence_last_value.
Oh, that's a good point. I wrongly assumed the privilege checks would be
the same as pg_sequence_last_value(). I fixed this in v5.
I also polished the rest of the patches a bit. Among other things, I
created an enum for the sequence data types to avoid the hacky strncpy()
stuff, which was causing weird CI failures [0].
[0] https://cirrus-ci.com/task/4614801962303488
--
nathan
Attachment | Content-Type | Size |
---|---|---|
v5-0001-parse-sequence-information.patch | text/plain | 5.9 KB |
v5-0002-cache-sequence-information.patch | text/plain | 10.2 KB |
v5-0003-introduce-pg_sequence_read_tuple.patch | text/plain | 4.4 KB |
v5-0004-cache-sequence-data.patch | text/plain | 4.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-07-18 18:38:22 | Re: Seq scan instead of index scan querying single row from primary key on large table |
Previous Message | Tom Lane | 2024-07-18 18:21:30 | Re: Lock-free compaction. Why not? |