Hi hackers,
Mr Lane, thank you for backporting this also to version 13. It seems
to be occuring in the wild (without debug_discard_caches) for real
user too when doing a lot of "CREATE INDEX i ON
unlogged_table_truncated_after_crash (x,y)" which sometimes (rarely)
results in SIGSEGV11. I've
On 11/18/22 15:43, Tom Lane wrote:
> David Geier writes:
>> On a different note: are we frequently running our tests suites with
>> debug_discard_caches=1 enabled?
>> It doesn't seem like.
>
> Hmm. Buildfarm members avocet and trilobite are supposed to be
> doing that, but their runtimes
David Geier writes:
> On a different note: are we frequently running our tests suites with
> debug_discard_caches=1 enabled?
> It doesn't seem like.
Hmm. Buildfarm members avocet and trilobite are supposed to be
doing that, but their runtimes of late put the lie to it.
Configuration option
Hi Tom,
Back-patching but keeping RelationOpenSgmr() for extensions sounds
reasonable.
On a different note: are we frequently running our tests suites with
debug_discard_caches=1 enabled?
It doesn't seem like. I just ran make check with debug_discard_caches=1 on
- latest master: everything
I wrote:
> I wonder whether we ought to back-patch f10f0ae42. We could
> leave the RelationOpenSmgr macro in existence to avoid unnecessary
> breakage of extension code, but stop using it within our own code.
Concretely, about like this for v14 (didn't look at the older
branches yet).
I'm not
Spyridon Dimitrios Agathos writes:
> while testing the developer settings of PSQL (14.5) I came across this
> issue:
> postgres=# CREATE UNLOGGED TABLE stats (
> postgres(# pg_hash BIGINT NOT NULL,
> postgres(# category TEXT NOT NULL,
> postgres(# PRIMARY KEY (pg_hash, category)
>
Hi Hackers,
while testing the developer settings of PSQL (14.5) I came across this
issue:
postgres=# CREATE UNLOGGED TABLE stats (
postgres(# pg_hash BIGINT NOT NULL,
postgres(# category TEXT NOT NULL,
postgres(# PRIMARY KEY (pg_hash, category)
postgres(# );
server closed the
