On Sat, Oct 22, 2016 at 9:45 AM, Tom Lane <[email protected]> wrote:
> Michael Paquier <[email protected]> writes:
>> On Sat, Oct 22, 2016 at 12:15 AM, Jim Nasby <[email protected]> wrote:
>>> On 10/21/16 8:47 AM, Tom Lane wrote:
>>>> If we are willing to do that then we don't really have to solve the
>>>> problem on the backend side. One could expect that autovacuum would
>>>> clean things up within a few minutes after a backend failure.
>
>> I am really thinking that we should just do that and call it a day
>> then, but document the fact that if one wants to look at the content
>> of orphaned tables after a crash he had better turn autovacuum to off
>> for the time of the analysis.
>
> Yeah, agreed. This also points up the value of Robert's suggestion
> of a "really off" setting.
Okay, so I suggest something like the attached as HEAD-only change
because that's a behavior modification.
--
Michael
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f87f3e0..0a365a0 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -800,6 +800,14 @@ analyze threshold = analyze base threshold + analyze scale
factor * number of tu
</para>
<para>
+ Autovacuum detects orphaned temporary tables that could be left behind
+ by a crashed backend, and forcibly drops them. In the event of a backend
+ crash, looking at the contents of orphaned temporary tables to perform
+ some research on their contents is possible though it is advised to
+ set <varname>autovacuum</> to <literal>off</> before doing so.
+ </para>
+
+ <para>
The default thresholds and scale factors are taken from
<filename>postgresql.conf</filename>, but it is possible to override them
(and many other autovacuum control parameters) on a per-table basis; see
diff --git a/src/backend/postmaster/autovacuum.c
b/src/backend/postmaster/autovacuum.c
index e3a6911..3a0f4a8 100644
--- a/src/backend/postmaster/autovacuum.c
+++ b/src/backend/postmaster/autovacuum.c
@@ -2037,34 +2037,21 @@ do_autovacuum(void)
/* We just ignore it if the owning backend is still
active */
if (backendID == MyBackendId ||
BackendIdGetProc(backendID) == NULL)
{
+ ObjectAddress object;
+
/*
- * We found an orphan temp table (which was
probably left
- * behind by a crashed backend). If it's so
old as to need
- * vacuum for wraparound, forcibly drop it.
Otherwise just
- * log a complaint.
+ * We found an orphan temp table which was
probably left
+ * behind by a crashed backend, so forcibly
drop it.
*/
- if (wraparound)
- {
- ObjectAddress object;
-
- ereport(LOG,
- (errmsg("autovacuum:
dropping orphan temp table \"%s\".\"%s\" in database \"%s\"",
-
get_namespace_name(classForm->relnamespace),
-
NameStr(classForm->relname),
-
get_database_name(MyDatabaseId))));
- object.classId = RelationRelationId;
- object.objectId = relid;
- object.objectSubId = 0;
- performDeletion(&object, DROP_CASCADE,
PERFORM_DELETION_INTERNAL);
- }
- else
- {
- ereport(LOG,
- (errmsg("autovacuum:
found orphan temp table \"%s\".\"%s\" in database \"%s\"",
-
get_namespace_name(classForm->relnamespace),
-
NameStr(classForm->relname),
-
get_database_name(MyDatabaseId))));
- }
+ ereport(LOG,
+ (errmsg("autovacuum: dropping
orphan temp table \"%s\".\"%s\" in database \"%s\"",
+
get_namespace_name(classForm->relnamespace),
+
NameStr(classForm->relname),
+
get_database_name(MyDatabaseId))));
+ object.classId = RelationRelationId;
+ object.objectId = relid;
+ object.objectSubId = 0;
+ performDeletion(&object, DROP_CASCADE,
PERFORM_DELETION_INTERNAL);
}
}
else
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
