Hi!
Yes, I've checked that. What would be desirable behavior in the case above?
Anyway, waiting for table unlock seems to be not quite right.
On Sat, Jan 21, 2023 at 4:12 AM Nathan Bossart
wrote:
> On Mon, Jan 16, 2023 at 11:18:08AM +0300, Alexander Pyhalov wrote:
> > Is it intended? Why don't
On Mon, Jan 16, 2023 at 11:18:08AM +0300, Alexander Pyhalov wrote:
> Is it intended? Why don't we perform vacuum_is_permitted_for_relation()
> check for inheritors in expand_vacuum_rel()?
Since no lock is held on the partition, the calls to functions like
object_ownercheck() and pg_class_aclcheck(
Hi!
For the test Alexander described in the beginning of the discussion - the
results are
postgres@postgres=# set role regress_vacuum_conflict;
SET
Time: 0.324 ms
postgres@postgres=> vacuum vacuum_tab;
WARNING: permission denied to vacuum "vacuum_tab", skipping it
WARNING: permission denied to v
Justin Pryzby писал 2023-01-19 04:49:
On Mon, Jan 16, 2023 at 08:12:18PM +0300, Nikita Malakhov wrote:
Hi,
Currently there is no error in this case, so additional thrown error
would
require a new test.
Besides, throwing an error here does not make sense - it is just a
check
for a vacuum
per
Hi!
I've found the discussion you'd mentioned before, checking now.
On Thu, Jan 19, 2023 at 4:49 AM Justin Pryzby wrote:
> On Mon, Jan 16, 2023 at 08:12:18PM +0300, Nikita Malakhov wrote:
> > Hi,
> >
> > Currently there is no error in this case, so additional thrown error
> would
> > require a
On Mon, Jan 16, 2023 at 08:12:18PM +0300, Nikita Malakhov wrote:
> Hi,
>
> Currently there is no error in this case, so additional thrown error would
> require a new test.
> Besides, throwing an error here does not make sense - it is just a check
> for a vacuum
> permission, I think the right way
Hi hackers!
Alexander found a very good issue.
Please check the solution above. Any objections? It's a production case,
please review,
any thoughts and objections are welcome.
On Mon, Jan 16, 2023 at 8:15 PM Alexander Pyhalov
wrote:
> Nikita Malakhov писал 2023-01-16 20:12:
> > Hi,
> >
> > Curr
Nikita Malakhov писал 2023-01-16 20:12:
Hi,
Currently there is no error in this case, so additional thrown error
would require a new test.
Besides, throwing an error here does not make sense - it is just a
check for a vacuum
permission, I think the right way is to just skip a relation that is
no
Hi,
Currently there is no error in this case, so additional thrown error would
require a new test.
Besides, throwing an error here does not make sense - it is just a check
for a vacuum
permission, I think the right way is to just skip a relation that is not
suitable for vacuum.
Any thoughts or obj
Nikita Malakhov писал 2023-01-16 17:26:
Hi!
Here's the patch that fixes this case, please check it out.
The patch adds vacuum_is_permitted_for_relation() check before adding
partition relation to the vacuum list, and if permission is denied the
relation
is not added, so it is not passed to vacuu
Hi!
Here's the patch that fixes this case, please check it out.
The patch adds vacuum_is_permitted_for_relation() check before adding
partition relation to the vacuum list, and if permission is denied the
relation
is not added, so it is not passed to vacuum_rel() and there are no try to
acquire th
Hi!
I've checked this expand_vacuum_rel() and made a quick fix for this.Here's
the result of the test:
postgres@postgres=# set role regress_vacuum_conflict;
SET
Time: 0.369 ms
postgres@postgres=> vacuum vacuum_tab;
WARNING: permission denied to vacuum "vacuum_tab", skipping it
WARNING: permissi
Hi.
We've run regress isolation tests on partitioned tables and found
interesting VACUUM behavior. I'm not sure, if it's intended.
In the following example, partitioned tables and regular tables behave
differently:
CREATE TABLE vacuum_tab (a int) PARTITION BY HASH (a);
CREATE TABLE vacuum_t
13 matches
Mail list logo
