PostgreSQL database queues claim items with a single atomic query

On PostgreSQL, database queues now claim items with a single atomic UPDATE ... RETURNING statement instead of a SELECT followed by a conditional UPDATE. The statement uses FOR UPDATE SKIP LOCKED, so concurrent queue consumers skip items that are being claimed by another consumer and each claim a different item in one query. Previously, parallel consumers all selected the same oldest item, only one of them won the subsequent update, and the others retried the whole loop; with N parallel consumers, N claims cost roughly N² queries. A single consumer also saves one query per claimed item.

New service class and queue class

When the pgsql module is installed, the queue.database service is now \Drupal\pgsql\Queue\QueueDatabaseFactory, which extends \Drupal\Core\Queue\QueueDatabaseFactory. When the queue's database connection is PostgreSQL, its get() method returns a \Drupal\pgsql\Queue\DatabaseQueue, which extends \Drupal\Core\Queue\DatabaseQueue and only overrides claimItem(). On any other connection the factory returns the generic \Drupal\Core\Queue\DatabaseQueue as before.

Because both new classes extend their core counterparts, code that type hints or does instanceof checks against the core classes keeps working. Modules that decorate or override the queue.database service, or that compare against the exact class name, may need to account for the new classes on PostgreSQL sites.

No changes for queue API consumers

\Drupal\Core\Queue\QueueInterface is unchanged. Code that creates, claims, releases, or deletes queue items through the queue API needs no changes. The claim semantics are the same: the oldest unclaimed item is claimed and its lease is set to the current time plus the lease time. Only the number of queries and the behavior under concurrency differ: consumers no longer race each other for the same item, and a claim never needs a retry.