On Thu, 17 Nov 2022 at 14:56, Robert Haas wrote:
>
> Having a switch for one particular kind of error (out of many that
> could possibly occur) that triggers one particular coping strategy
> (out of many that could possibly be used) seems far too specific a
> thing to add as a core feature. And
> I don't think this is a good feature to add to PostgreSQL. First, it's
> unclear why stopping the cluster is a desirable behavior. It doesn't
> stop the user transactions from failing; it just makes them fail in
> some other way. Now it is of course perfectly legitimate for a
> particular user
On Wed, Nov 16, 2022 at 7:59 AM Maxim Orlov wrote:
> The customer, mentioned above, in this particular case, would be glad to be
> able to have a mechanism to stop the cluster.
> Again, in this concrete case.
>
> My proposal is to add a tablespace option in order to be able to configure
> which
On 2022-11-17 14:40:02 +0300, Maxim Orlov wrote:
> On Wed, 16 Nov 2022 at 20:41, Andres Freund wrote:
> > that aside, we can't do catalog accesses in all kinds of environments that
> > this currently is active in - most importantly it's affecting the startup
> > process. We don't do catalog
On Wed, 16 Nov 2022 at 20:41, Andres Freund wrote:
> Hi,
> You can't do catalog access below the bufmgr.c layer. It could lead to all
> kinds of nastiness, including potentially recursing back to md.c. Even
> leaving
>
Yep, this is my biggest concern. It turns out, that the way to make such a
Hi,
On 2022-11-16 15:59:09 +0300, Maxim Orlov wrote:
> Patch is posted as PoC is attached.
> --- a/src/backend/storage/smgr/md.c
> +++ b/src/backend/storage/smgr/md.c
> @@ -40,6 +40,7 @@
> #include "storage/sync.h"
> #include "utils/hsearch.h"
> #include "utils/memutils.h"
> +#include
Hi, Maxim!
> My proposal is to add a tablespace option in order to be able to configure
> which behaviour is appropriate for a
> particular user. I've decided to call this option “on_no_space” for now. If
> anyone has a better naming for this feature,
> please, report.
>
> So, the idea is to add
Hi!
PROBLEM
Our customer stumble onto the next behaviour of the Postgres cluster: if
disk space is exhausted, Postgres continues to
work until WAL can be successfully written. Thus, upon disk space
exhaustion, clients will get an “ERROR: could not
extend file “base/X/X”: No space left
