Truncation vs Deletion When `session_replication_role = replica`
First and foremost you should know the name of the FOREIGN KEY constraint:
CREATE TABLE users (
    id serial PRIMARY KEY
);

CREATE TABLE posts(
    id serial PRIMARY KEY,
    user_id INTEGER,
    
    CONSTRAINT fk_post_users 
        FOREIGN KEY (user_id) REFERENCES users(id)
);

INSERT INTO users(id) VALUES (1);
INSERT INTO posts(id, user_id) VALUES (1, 1);

Then you can DROP FOREIGN KEY and after that, TRUNCATE the table.
ALTER TABLE posts DROP CONSTRAINT fk_post_users;
TRUNCATE users;

Now, posts table remains in an inconsistent state, but you can add the foreign key again using NOT VALID option, that does not check current values.
ALTER TABLE posts ADD CONSTRAINT fk_post_users
    FOREIGN KEY (user_id) REFERENCES users(id) NOT VALID;

db&lt;&gt;fiddle here
Quoted from Postgres docs:

ADD table_constraint [ NOT VALID ]
This form adds a new constraint to a table using the same syntax as CREATE TABLE, plus the option NOT VALID, which is currently only allowed for foreign key and CHECK constraints. If the constraint is marked NOT VALID, the potentially-lengthy initial check to verify that all rows in the table satisfy the constraint is skipped. The constraint will still be enforced against subsequent inserts or updates (that is, they'll fail unless there is a matching row in the referenced table, in the case of foreign keys; and they'll fail unless the new row matches the specified check constraints). But the database will not assume that the constraint holds for all rows in the table, until it is validated by using the VALIDATE CONSTRAINT option. Foreign key constraints on partitioned tables may not be declared NOT VALID at present.
The addition of a foreign key constraint requires a SHARE ROW EXCLUSIVE lock on the referenced table.
Additional restrictions apply when unique or primary key constraints are added to partitioned tables; see CREATE TABLE.