[DocDB] PITR: Disable restoring to before the sequence was dropped

[sanketkedia]

Description

1. Consider a table that has the following schema:

CREATE TABLE orders(
   id INT NOT NULL,
   details VARCHAR NOT NULL
);

2. Say we made the id column a sequence

CREATE SEQUENCE order_id_seq
START 10
INCREMENT 10
OWNED BY orders.id;

3. Assume at time t1 we have the following data in the table:
   SELECT * FROM orders;

id details
10 Order of IPhone11

4. Say at time t2 (> t1) we drop the sequence
   DROP SEQUENCE order_id_seq;

5. Now say that we restore to time t1. After restoration, if we try to insert a row with the next id in the sequence (we should be able to since, after restoration, the sequence order_id_seq should be restored), it throws an error. We are not able to insert rows in the orders table using the sequence. Note that we are able to insert a row specifying an explicit value of the id column i.e.

INSERT INTO orders (id, name) values (2, 'Order of earphones’); → Works
INSERT INTO orders (id, name) values (nextval(‘order_id_seq’), 'Order of chocolates’); → throws an error ERROR:  relation "order_id_seq" does not exist

The fix for this is non-trivial. Until we add support for it, we should have a way to prevent restorations such as the above and propagate a suitable error all the way to the client. To detect such a condition, during the restoration of pg catalog tables, we could check the contents of the pg_sequence table for both the times and error out if there are differences.