Hi all,
Here is a summary of what has happened since this thread has been
created. Three problems reported on this thread have been solved and
resulted in different commits for early lock lookups:
- VACUUM FULL, patched on 12~:
Hi Nathan,
On Fri, Jul 27, 2018 at 02:40:42PM +, Bossart, Nathan wrote:
> I think I'm essentially suggesting what you have in 0002 but without
> the new RangeVarGetRelidExtended() callback. I've attached a modified
> version of 0002 that seems to fix the originally reported issue. (I
>
On Wed, Aug 01, 2018 at 10:55:11AM +, Ahsan Hadi wrote:
> Can you rebase the reindex-priv-93.patch, it is getting some hunk failures.
Patch reindex-priv-93.patch is for REL9_3_STABLE, where it applies
cleanly for me. reindex-priv-94.patch is for REL9_4_STABLE and
reindex-priv-95-master.patch
Hi Michael,
Can you rebase the reindex-priv-93.patch, it is getting some hunk failures.
patching file doc/src/sgml/ref/reindex.sgml
Hunk #1 succeeded at 227 (offset 13 lines).
patching file src/backend/commands/indexcmds.c
Hunk #1 FAILED at 1873.
1 out of 1 hunk FAILED -- saving rejects to file
On Tue, Jul 31, 2018 at 10:34:57AM -0400, Robert Haas wrote:
> Just as a general statement, I don't think we should, as part of a
> patch for the issue discussed on this thread, make any changes AT ALL
> to who has permission to perform which operations. We *certainly*
> should not back-patch
On 7/29/18, 7:35 PM, "Michael Paquier" wrote:
> Yeah, I was testing that yesterday night and bumped on this case when
> trying do a REINDEX SCHEMA pg_class. The point is that you can simplify
> the check and remove pg_database_ownercheck as there is already an ACL
> check on the
At Mon, 30 Jul 2018 09:34:22 +0900, Michael Paquier wrote
in <20180730003422.ga2...@paquier.xyz>
> On Sun, Jul 29, 2018 at 04:11:38PM +, Bossart, Nathan wrote:
> > On 7/27/18, 7:10 PM, "Michael Paquier" wrote:
> > This is added to ReindexMultipleTables(), which is used for REINDEX
> >
On Sun, Jul 29, 2018 at 04:11:38PM +, Bossart, Nathan wrote:
> On 7/27/18, 7:10 PM, "Michael Paquier" wrote:
> > No problem. If there are no objections, I am going to fix the REINDEX
> > issue first and back-patch. Its patch is the least invasive of the
> > set.
>
> This seems like a
On 7/27/18, 7:10 PM, "Michael Paquier" wrote:
> No problem. If there are no objections, I am going to fix the REINDEX
> issue first and back-patch. Its patch is the least invasive of the
> set.
This seems like a reasonable place to start. I took a closer look at
0003.
+ /*
+
On Fri, Jul 27, 2018 at 02:40:42PM +, Bossart, Nathan wrote:
> On 7/26/18, 11:16 PM, "Michael Paquier" wrote:
> I think I'm essentially suggesting what you have in 0002 but without
> the new RangeVarGetRelidExtended() callback. I've attached a modified
> version of 0002 that seems to fix the
On Fri, Jul 27, 2018 at 12:37:02PM +0900, Kyotaro HORIGUCHI wrote:
> I intended the same as Bossart said. It is not reasonable that
> VACUUM and VACUUM FULL behaves differently on rejection for the
> same reason. The objective of the first (or early) check is
> rejecting (non-superuser's)
Hello.
At Fri, 27 Jul 2018 11:31:23 +0900, Michael Paquier wrote
in <20180727023123.ge1...@paquier.xyz>
> On Thu, Jul 26, 2018 at 11:14:31PM +, Bossart, Nathan wrote:
> > On 7/26/18, 3:42 PM, "Michael Paquier" wrote:
> > Minus a possible documentation update, 0003 seems almost ready, too.
On Thu, Jul 26, 2018 at 11:14:31PM +, Bossart, Nathan wrote:
> On 7/26/18, 3:42 PM, "Michael Paquier" wrote:
> Minus a possible documentation update, 0003 seems almost ready, too.
The docs mentioned that shared catalogs are processed, so I did not
bother, but visibly your comment is that we
On 7/26/18, 3:42 PM, "Michael Paquier" wrote:
> Thanks for the lookup. 0003 is the most simple in the set by the way.
Minus a possible documentation update, 0003 seems almost ready, too.
For 0002, would adding vacuum_skip_rel() before and after
try_relation_open() in vacuum_rel() be enough?
On Thu, Jul 26, 2018 at 03:06:59PM +, Bossart, Nathan wrote:
> I took a look at 0001.
Thanks for the lookup. 0003 is the most simple in the set by the way.
> On 7/26/18, 12:24 AM, "Michael Paquier" wrote:
> - myrelid = RelationGetRelid(rel);
> + myrelid =
On 7/26/18, 10:07 AM, "Bossart, Nathan" wrote:
> The first time we use this callback, the relation won't be locked, so
> isn't it possible that we won't get a valid tuple here? I did notice
> that callbacks like RangeVarCallbackForRenameRule,
> RangeVarCallbackForPolicy, and
I took a look at 0001.
On 7/26/18, 12:24 AM, "Michael Paquier" wrote:
> 1) 0001 does the work for TRUNCATE, but using RangeVarGetRelidExtended
> with a custom callback based on the existing truncate_check_rel(). I
> had to split the session-level checks into a separate routine as no
> Relation
Hi,
So, I have spent the last couple of days trying to figure out a nice
solution for VACUUM, TRUNCATE and REINDEX, and attached is a set of
three patches to address the issues of this thread:
1) 0001 does the work for TRUNCATE, but using RangeVarGetRelidExtended
with a custom callback based on
On Tue, Jul 24, 2018 at 06:27:16PM +0900, Kyotaro HORIGUCHI wrote:
> I may be misunderstanding something because (really ?) it's still
> extremely hot in Japan, today.
It is better since yesterday, in exchange of a typhoon heading straight
to Tokyo :)
--
Michael
signature.asc
Description: PGP
At Tue, 24 Jul 2018 14:23:02 +0900, Michael Paquier wrote
in <20180724052302.gb4...@paquier.xyz>
> On Mon, Jul 23, 2018 at 09:51:54PM -0700, Andres Freund wrote:
> > On July 23, 2018 9:50:10 PM PDT, Michael Paquier
> > wrote:
> >> Oh, yes, that would be bad. My mind has slipped here. I have
On Tue, Jul 24, 2018 at 01:34:13AM -0400, Alvaro Herrera wrote:
> But I don't see why RangeVarCallbackOwnsTable isn't sufficient.
The set of relkinds checked by truncate_check_rel and
RangeVarCallbackOwnsTable is different (toast and matviews). And in the
case of VACUUM, partitioned tables can
On Tue, Jul 24, 2018 at 02:23:02PM +0900, Michael Paquier wrote:
> Well, letting any users take an exclusive lock on system catalogs at
> will is not acceptable either, so two possible answers would be to fail
> or skip such relations. The first concept applies if a relation list is
> given by
On Mon, Jul 23, 2018 at 09:51:54PM -0700, Andres Freund wrote:
> On July 23, 2018 9:50:10 PM PDT, Michael Paquier wrote:
>> Oh, yes, that would be bad. My mind has slipped here. I have seen
>> manual VACUUMs on system catalogs for applications using many temp
>> tables... So we would want to
On July 23, 2018 9:50:10 PM PDT, Michael Paquier wrote:
>On Mon, Jul 23, 2018 at 09:17:53PM -0700, Andres Freund wrote:
>> I might be mis-parsing this due to typos. Are you actually suggesting
>> vacuum on system tables should depend on that GUC? If so, why? That's
>> seems like a terrible
On Mon, Jul 23, 2018 at 09:17:53PM -0700, Andres Freund wrote:
> I might be mis-parsing this due to typos. Are you actually suggesting
> vacuum on system tables should depend on that GUC? If so, why? That's
> seems like a terrible idea. It's pretty normal to occasionally have
> to vacuum them?
On July 23, 2018 9:14:03 PM PDT, Michael Paquier wrote:
>- While it would make sense, at least to me, to make VACUUM fall into
>if
>allow_system_table_mods is allowed,
I might be mis-parsing this due to typos. Are you actually suggesting vacuum on
system tables should depend on that GUC? If
On Mon, Jul 23, 2018 at 11:29:33AM -0400, Robert Haas wrote:
> ExecuteTruncate needs to be refactored to use RangeVarGetRelidExtended
> with a non-NULL callback rather than heap_openrv, and
> expand_vacuum_rel needs to use RangeVarGetRelidExtended with a
> callback instead of RangeVarGetRelid.
On Fri, Jul 20, 2018 at 5:56 PM, Marko Tiikkaja wrote:
> On Fri, Jul 20, 2018 at 2:17 AM, Jeremy Schneider
> wrote:
>
>> I'd like to bump this old bug that Lloyd filed for more discussion. It
>> seems serious enough to me that we should at least talk about it.
>>
>> Anyone with simply the login
On Thu, Jul 19, 2018 at 7:17 PM, Jeremy Schneider wrote:
> I'd like to bump this old bug that Lloyd filed for more discussion. It
> seems serious enough to me that we should at least talk about it.
>
> Anyone with simply the login privilege and the ability to run SQL can
> instantly block all new
On Fri, Jul 20, 2018 at 2:17 AM, Jeremy Schneider
wrote:
> I'd like to bump this old bug that Lloyd filed for more discussion. It
> seems serious enough to me that we should at least talk about it.
>
> Anyone with simply the login privilege and the ability to run SQL can
> instantly block all
30 matches
Mail list logo
