On 2017-06-05 22:34:17 -0400, Bruce Momjian wrote: > On Mon, Jun 5, 2017 at 04:38:32PM -0500, Jerry Sievers wrote: > > The SAN snaps capture the entire pgdata and WAL pg_xlog area but there > > is no attempt to copy the NVME device when the snaps are made. > > > > There's an event trigger plus batch job now running tou avoid this risk. > > > > We realize too that there are implications here if a backup is > > instantiated and PITR is done. > > > > Just FYI that there could be others running like this ignorant of the > > potential gotchas. > > Yes, if we implement the TODO you will create a TEMPORARY tablespace > that can't contain non-temporary and/or non-unlogged tables.
FWIW, allowing UNLOGGED tables, rather than just TEMPORARY ones, increases the complexity of that project noticeably. For TEMPORARY you basically don't need to do much but to recreate the structure inside the tablespace at start - fairly simple. But for UNLOGGED you need to find a way to recreate the relevant file and init forks - otherwise we might not notice what needs to be reset at a crash restart, and we might error out when executing selects etc. and then the table's not there. Presumably recreating files & init forks that at first table access is doable, but it's not entirely trivial to do locking wise. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
