Re: Strange issue with NFS mounted PGDATA on ugreen NAS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Kenneth Marshall <ktm(at)rice(dot)edu>, Larry Rosenman <ler(at)lerctr(dot)org>, Pgsql hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Strange issue with NFS mounted PGDATA on ugreen NAS
Date: 2025-01-01 05:39:36
Message-ID: 13722.1735709976@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> NFS is at least supposed to tell the client that its cookie has been
> invalidated with a cookie-invalidation-cookie called cookieverf. But
> there isn't any specified way to recover. FreeBSD's client looks like
> it might try to, but I'm not sure if that Linux's server even
> implements it.

ISTM we used to disclaim responsibility for data integrity if you
try to put PGDATA on NFS. I looked at the current wording about
NFS in runtime.sgml and was frankly shocked at how optimistic it is.
Shouldn't we be saying something closer to "if it breaks you
get to keep both pieces"?

> Anyway, I'll write a patch to change rmtree() to buffer the names in
> memory. In theory there could be hundreds of gigabytes of pathnames,
> so perhaps I should do it in batches; I'll look into that.

This feels a lot like putting lipstick on a pig.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shlok Kyal 2025-01-01 06:47:24 Re: Logical replication timeout
Previous Message Amit Kapila 2025-01-01 05:36:15 Re: Conflict detection for update_deleted in logical replication