Dmitry Ivanov authored 3 months ago and Dmitry Ivanov committed 3 months ago

Previously, log_destroy would close log->fd even if it's one of the
standard streams. This behavior almost never makes sense, unless
one's trying to write a unix daemon which is obviously not the case.

Closing stderr has the following side effects:
- it breaks a reinit of the default logger;
- it inhibits ASan's final leak report;
- it causes a EPOLLHUP during a restart via `--entrypoint-fd` (Picodata).

We have to specify custom targets to disable ASan for build.rs and such.
This affects the path to picodata, so we have to adapt:

```
target/debug/picodata
target/x86_64-unknown-linux-gnu/asan/picodata
```

Also deduce target for ASan build from `rustc -vV`.

Co-Authored-By: Dmitry Rodionov <d.rodionov@picodata.io>
Co-Authored-By: Dmitry Ivanov <d.ivanov@picodata.io>

This adds support for ASan both in rust code and core tarantool. To build with ASan, simply run

```bash
make build-asan
```

Keep in mind that ASan-enabled executable lives in

```
target/x86_64-unknown-linux-gnu/asan/picodata
```

as opposed to

```
target/debug/picodata
```

This fixes the following issues:

* Release build not working on macos.
* -rdynamic, -export-dynamic and such are a code smell. They expose
  too much and hinder the ability to clearly define the API & ABI bounds.

This patch boils down to the following improvements:

* Various linkage-related shenanigans have been documented and revamped.
* All logic to build tarantool-sys is now encapsulated in tarantool-build.
* Most of the magic `println!`s are now encapsulated in build-rs-helpers.
* Unsound function `export_symbols` has been dropped in favor of
  explicit linker flags (`--require-defined` for linux & `-u` for mac).
* `TarantoolBuildRoot` is now in charge of building and linking
  tarantool libs. It defines the build tree via path helper functions.
* Picodata's `build.rs` should be a little easier to read.

Maksim Kaitmazian authored 3 months ago and Dmitry Ivanov committed 3 months ago

With these changes, a user can specify new default values for vdbe_max_steps
vtable_max_rows options in connection string.

For example, the following connection string sets both options to 42:
postgres://postgres:Passw0rd@localhost:5432?options=vtable_max_rows%3D42,vdbe_max_steps%3D42

Add alter system cluster_wal_max_size and cluster_wal_max_count parameters
which control the auto compaction of _raft_log system space based on
the size in bytes and number of tuples respectively.