fix: skip recorder and sqlite state creation when vchord extension is not created

[Ngalstyan4]

When vchord is added to shared_preload_libraries without running CREATE EXTENSION, the object_access_hook fires on any DROP TABLE or DROP DATABASE and calls the recorder's get() function, which lazily creates the pgsql_tmp_vchord_sampling/ directory and SQLite files under PGDATA.

This is unnecessary and confusing when looking at contents of PGDATA and seeing files from an extension that has never been enabled

The commit skips all recorder operations when the extension has never been created (extension does not have an assigned OID)

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[Ngalstyan4]

I think there is a bigger issue here as well.

Is pgsql_tmp_vchord_sampling temporary and safe to delete at any point?

if so, per postgres guidance1, the files have to exist under pgsql_tmp/ directory.

Temporary files (for operations such as sorting more data than can fit in memory) are created within PGDATA/base/pgsql_tmp, or within a pgsql_tmp subdirectory of a tablespace directory if a tablespace other than pg_default is specified for them. The name of a temporary file has the form pgsql_tmpPPP.NNN, where PPP is the PID of the owning backend and NNN distinguishes different temporary files of that backend.

There are special rules around file naming as well. I ran into one issue with save/restore and I suspect many tools will have issue with current directory structure used in VectorChord.

[usamoi]

I suspect many tools will have issue with current directory structure used in VectorChord.

Yes, it's problematic. We recommend not using this feature, as it may lead to issues. #448 should stop the file or directory creation if the feature is not used. We hope this issue can be resolved in this way.

[VoVAllen]

Hi @Ngalstyan4 , the folder under pgsql_tmp/ may still not comply with the postgres guidance to name it as pgsql_tmpPPP.NNN. And the lifecycle of this folder seems not clear to us and the purpose of this folder seems not consistent to what we used it for. The ideal case is similar to pg_stat_statements, we're thinking about whether it's possible for us to put the sqlite file under the same folder like pg_stat_tmp