Merge ba68a3e into d5e9e11

.editorconfig

@@ -0,0 +1,9 @@
+# Unix-style newlines with a newline ending every file
+[*]
+end_of_line = lf
+insert_final_newline = true
+
+[*.js]
+charset = utf-8
+indent_style = space
+indent_size = 2

.npmignore

@@ -5,4 +5,5 @@ coverage/
 .nyc_output/
 docs/
 CHANGELOG.md
-README.md
+README.md
+.editorconfig

CHANGELOG.md

@@ -1,5 +1,33 @@
 # Changes
 
+## 4.0.0
+
+- Switched maintenance and monitoring operations to a dedicated queue for multi-master and/or concurrency control.
+- MAJOR: Consolidated the maintenance constructor options and removed any options for intervals less than 1 second.  
+  - Removed:
+    - `expireCheckInterval`
+    - `expireCheckIntervalSeconds`
+    - `expireCheckIntervalMinutes`
+    - `archiveCheckInterval`
+    - `archiveCheckIntervalSeconds`
+    - `archiveCheckIntervalMinutes`
+    - `deleteCheckInterval`
+  - Added:
+    - `maintenacneIntervalSeconds`
+    - `maintenanceIntervalMinutes`
+
+### Context
+
+The breaking changes introduced in this release should not cause any run-time failures, but if you are relying on customized maintenance intervals, you will need to adjust the configuration options when you upgrade.
+
+To keep maintenance operations running as light as possible, concurrency of each item (expiration, archiving, deletion) has been adjusted to 1 operation at a time. In the process of doing this, I've also migrated all internal timers to queues, basically having pg-boss eat its own dog food.
+
+This decision was made to address certain deployment situations, where a new instance is being started before another instance is turned off.  If and when this were to occur (it's quite common, actually), you may have a race condition of 2 maintenance operations attempting to execute at the same time, which in my experience has caused unpredictable deadlock errors (see [issue #133](https://github.com/timgit/pg-boss/issues/133)) because of the use of unordered data sets in CTEs from a `DELETE ... RETURNING` statement. Upon review, addressing the concurrency problem was a far better option than introducing more changes to how the actual sql statement is working (or not :)
+
+The result of using a queue for maintenance instead of a timer is you can now run pg-boss in a (sort of) multi-master mode, where more than 1 instance is using `start()` simultaneously. Beginning in this release, if 2 or more instances are using `start()`, only 1 of them will be able to fetch the job (maintnenance or state monitoring) and issue the related SQL statements. 
+
+This is not an advertisement to go crazy with "master" instances, as you would still need to be careful since no explicit locking is in place to guard against schema creation or migration.  This may eventually lead to a future without the need of `connect()` entirely, so we'll see where this goes. 
+
 ## 3.2.2
 
 - Deferring housekeeping operations on start to reduce deadlocks during concurrent start() instances

docs/configuration.md

@@ -5,20 +5,18 @@ pg-boss can be customized using configuration options when an instance is create
 
 <!-- TOC -->
 
-- [Constructor Options](#constructor-options)
+- [Configuration](#configuration)
+  - [Constructor Options](#constructor-options)
     - [Database options](#database-options)
-    - [Job monitor options](#job-monitor-options)
-    - [Job creation options](#job-creation-options)
-    - [Job fetch options](#job-fetch-options)
-    - [Job expiration options](#job-expiration-options)
-    - [Job archive options](#job-archive-options)
-- [Publish Options](#publish-options)
+    - [Queue options](#queue-options)
+    - [Maintenance options](#maintenance-options)
+  - [Publish Options](#publish-options)
     - [Delayed jobs](#delayed-jobs)
     - [Unique jobs](#unique-jobs)
     - [Throttled jobs](#throttled-jobs)
     - [Job retries](#job-retries)
     - [Job expiration](#job-expiration)
-- [Subscribe Options](#subscribe-options)
+  - [Subscribe Options](#subscribe-options)
 
 <!-- /TOC -->
 
@@ -78,23 +76,20 @@ Since passing only a connection string is intended to be for convenience, you ca
 
     Only alphanumeric and underscore allowed, length: <= 50 characters
 
-### Job monitor options
+### Queue options
+
+* **uuid** - string, defaults to "v1"
+
+    job uuid format used, "v1" or "v4"
 
 * **monitorStateIntervalSeconds** - int, default undefined
 
-    Specifies how often in seconds an instance will fire the `monitor-states` event. Cannot be less than 1.
+    Specifies how often in seconds an instance will fire the `monitor-states` event. Cannot be less than 1.  This is only available 
 
 * **monitorStateIntervalMinutes** - int, default undefined
 
     Specifies how often in minutes an instance will fire the `monitor-states` event. Cannot be less than 1. Do not use if using `monitorStateIntervalSeconds`.
 
-### Job creation options
-
-* **uuid** - string, defaults to "v1"
-
-    uuid format used, "v1" or "v4"
-
-### Job fetch options
 * **newJobCheckInterval**, int
 
     interval to check for new jobs in milliseconds, must be >=100
@@ -103,54 +98,36 @@ Since passing only a connection string is intended to be for convenience, you ca
 
     Default: 1. interval to check for new jobs in seconds, must be >=1
 
-When `newJobCheckIntervalSeconds` is specified, `newJobCheckInterval` is ignored.
-
-### Job expiration options
-* **expireCheckInterval**, int
-
-    interval to expire jobs in milliseconds, must be >=100
-
-* **expireCheckIntervalSeconds**, int
-
-    interval to expire jobs in seconds, must be >=1
+> When `newJobCheckIntervalSeconds` is specified, `newJobCheckInterval` is ignored.
 
-* **expireCheckIntervalMinutes**, int
+### Maintenance options
 
-    Default: 1. interval to expire jobs in minutes, must be >=1
+Maintenance operations include checking active jobs for expiration, archiving completed jobs from the primary job table, and deleting archived jobs from the archive table.  
 
-When `expireCheckIntervalMinutes` is specified, `expireCheckIntervalSeconds` and `expireCheckInterval` are ignored.
-
-When `expireCheckIntervalSeconds` is specified, `expireCheckInterval` is ignored.
-
-### Job archive options
+* **noSupervisor**, bool, default undefined
+
+  If this is set to true, maintenance and monitoring operations will not be started during a `start()` after the schema is created.  This is an advanced use case, as bypassing maintenance operations is not something you would want to do under normal circumstances.
 
 * **archiveCompletedJobsEvery**, string, [PostgreSQL interval](https://www.postgresql.org/docs/9.5/static/datatype-datetime.html#DATATYPE-INTERVAL-INPUT)
 
     Default: "1 hour".  When jobs become eligible for archive after completion.
 
-* **archiveCheckInterval**, int
-
-    interval to archive jobs in milliseconds, must be >=100
-
-* **archiveCheckIntervalSeconds**, int
-
-    interval to archive jobs in seconds, must be >=1
+* **deleteArchivedJobsEvery**, string, [PostgreSQL interval](https://www.postgresql.org/docs/9.5/static/datatype-datetime.html#DATATYPE-INTERVAL-INPUT)
 
-* **archiveCheckIntervalMinutes**, int
+    Default: "7 days".  When jobs in the archive table become eligible for deletion.
 
-    Default: 60. interval to archive jobs in minutes, must be >=1
+* **maintenanceIntervalSeconds**, int
 
-When `archiveCheckIntervalMinutes` is specified, `archiveCheckIntervalSeconds` and `archiveCheckInterval` are ignored.
+    maintenance interval in seconds, must be >=1
 
-When `archiveCheckIntervalSeconds` is specified, `archiveCheckInterval` is ignored.
+* **maintenanceIntervalMinutes**, int
 
-* **deleteArchivedJobsEvery**, string, [PostgreSQL interval](https://www.postgresql.org/docs/9.5/static/datatype-datetime.html#DATATYPE-INTERVAL-INPUT)
-
-    Default: "7 days".  When jobs in the archive table become eligible for deletion.
+    Default: 1. interval in minutes, must be >=1
 
-* **deleteCheckInterval**, int
+> When `maintenanceIntervalMinutes` is specified, `maintenanceIntervalSeconds` and `maintenanceInterval` are ignored. 
+>
+> When `maintenanceIntervalSeconds` is specified, `maintenanceInterval` is ignored.
 
-    interval to delete jobs in milliseconds, must be >=100.   Default: 1 hour
 
 ## Publish Options