PostgreSQL 10 beta 2 makes sequence changes transactional

Schema changes are easier to compose when a failed transaction can undo them. PostgreSQL 10 beta 2 extends that behavior to ALTER SEQUENCE, one of the changes listed in the July 13 announcement. The same beta fixes several interactions between new capabilities and existing database rules. It is a useful point to examine what a prerelease changes beyond making individual features compile.

The announcement says beta 2 previews all the features planned for PostgreSQL 10 and includes fixes found during beta 1 testing. It remains a test release with known open issues. Moving from beta 1 or an earlier version requires pg_dump and pg_restore, or pg_upgrade, so its installation is not presented as a simple replacement of beta 1 binaries over an unchanged cluster.

I value PostgreSQL's transactional schema behavior because it makes migration failure easier to reason about. Sequence operations need careful distinctions within that model. This beta changes the behavior of a schema command without making every operation that obtains or changes a sequence value transactional.

Restarting a sequence has a concurrency contract

The ALTER SEQUENCE reference at the beta 2 tag explains the new behavior of RESTART. It changes the current sequence value so the next nextval returns the specified restart value. Unlike a setval call, the restart operation is transactional and blocks concurrent transactions from obtaining numbers from that sequence.

For a sequence already named serial, the documented form is:

ALTER SEQUENCE serial RESTART WITH 105;

This command changes what the next sequence allocation will return. A different clause, START WITH, changes the recorded starting value used by a later restart without changing the current sequence value. The two clauses therefore express different changes even though both mention a starting number.

Transactional restart also has an operational cost. Other transactions seeking numbers from the same sequence must wait while the alteration holds its required exclusion. The reference explicitly identifies setval as an alternative when that mode of operation is not desired. Choosing between the operations includes choosing their transaction and concurrency behavior, not merely selecting equivalent-looking syntax.

The reference separately notes that sequence parameter changes do not immediately replace values other backends have already cached. Those backends exhaust their cached values before noticing the changed generation parameters. Sequence behavior includes both stored configuration and allocation state, so a general statement that sequence changes are now transactional would omit useful details.

Partitioning must preserve existing database rules

Several beta 2 fixes concern the interaction of partitioning with the rest of PostgreSQL. The announcement includes applying row-level-security policies to partitioned tables and preventing BEFORE triggers from violating partition constraints. It also fixes memory leaks in the new partitioning code and stops explicitly marking range-partitioning columns NOT NULL.

These changes affect different properties of a partitioned table. A partition constraint governs which rows belong in a partition. A trigger can change a row before storage, so the database must account for the row after that trigger runs. Row-level security concerns which rows the caller may access. Introducing partitioning cannot leave those existing mechanisms with inconsistent interpretations of the same operation.

The release also prevents table partitions from being converted into views and teaches PL/pgSQL about partitioned tables. That gives a sense of the integration work a beta is testing. A new table form has consequences for schema changes and procedural code as well as the statement that creates it.

I consider these interactions more informative than a simple list of supported syntax. A database feature becomes useful when its behavior remains understandable alongside constraints, triggers, and access policy. Beta feedback is finding cases where those combinations need correction.

Logical replication needs consistent table interpretation

The announcement fixes initial table synchronization when corresponding tables have columns in a different order. It also fixes logical replication with full replication identity. Both entries concern how a replication operation interprets the data it is moving, beyond the existence of a connection between servers.

Different physical column order is a particularly useful case to identify. A successful copy must associate data with the intended destination columns. Treating the source's position as sufficient would be wrong when the destination uses another order. The beta announcement identifies that combination as a corrected case and asks users to retest reported problems.

Other integration fixes affect transition tables in triggers, including combinations with partitioning or inheritance, writable common table expressions, and ON CONFLICT. These are examples of new facilities meeting several ways PostgreSQL can change rows. They explain why testing isolated demonstration queries is only part of evaluating a beta.

Connection handling also needs prerelease testing

The client-library changes include trying the next host after a timeout when multiple hosts are specified, and allowing multiple host addresses alongside multiple hostnames. A list of alternative endpoints is useful only if connection attempts advance correctly after a failed attempt. This is connection control flow, separate from SQL execution once a session exists.

Beta 2 includes applicable fixes from supported older branches as well as corrections reported against beta 1. The project asks users to check its open-items list before reporting bugs and expects further betas or release candidates as testing requires. At this stage, the actionable changes include a transactional sequence command with documented blocking behavior and a set of repaired feature interactions that applications can exercise against the prerelease.