Partition DDL in the hot path

[fbac]

Currently inserting a gateway envelope can force a partition creation:

func InsertGatewayEnvelopeWithChecksStandalone(
	ctx context.Context,
	q *queries.Queries,
	row queries.InsertGatewayEnvelopeParams,
) (queries.InsertGatewayEnvelopeRow, error) {
	inserted, err := q.InsertGatewayEnvelope(ctx, row)

	if err == nil {
		return inserted, nil
	}

	if !strings.Contains(err.Error(), "no partition of relation") {
		return queries.InsertGatewayEnvelopeRow{}, err
	}

	err = q.EnsureGatewayParts(ctx, queries.EnsureGatewayPartsParams{
		OriginatorNodeID:     row.OriginatorNodeID,
		OriginatorSequenceID: row.OriginatorSequenceID,
		BandWidth:            GatewayEnvelopeBandWidth,
	})
	if err != nil {
		return queries.InsertGatewayEnvelopeRow{}, err
	}

	// retry insert
	return q.InsertGatewayEnvelope(ctx, row)
}

Even if rare, this could be avoided by using a background job that ensure partitions exists ahead of time.

[neekolas]

I can't find the doc, but I do remember a good thread with Martin about why this might still be preferable even with the inconsistency in performance.

The gist I recall is that it removes any possibility of the partition not being there in advance, which simplifies testing and removes whole categories of "all writes are broken" bugs.

Maybe some assumptions have changed either around the costs or the benefits, but I wouldn't be hasty to change this if we don't absolutely have to.

[tylerhawkes]

I think that keeping this code while trying to ensure that partitions are created ahead of time is the best of both worlds, though you would want to log in the existing function if it ever had to create a partition.

[fbac]

I like the hybrid approach.

@neekolas that makes a lot of sense.