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
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
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
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,
> >
> >
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
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
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
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
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:
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
13 matches
Mail list logo
