Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On Tue, Jun 6, 2017 at 3:39 AM, Alvaro Herrera wrote: > FWIW I don't think calling these tablespaces "temporary" is the right > word. It's not the tablespaces that are temporary. Maybe "evanescent". While I would personally find it pretty hilarious to see the

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On 06.06.2017 14:31, Bruce Momjian wrote: On Tue, Jun 6, 2017 at 04:39:50AM -0300, Alvaro Herrera wrote: I was thinking that you could create the init fork for each unlogged table in a permanent tablespace (probably the default one for the database). FWIW I don't think calling these

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On 6/6/17 03:39, Alvaro Herrera wrote: > FWIW I don't think calling these tablespaces "temporary" is the right > word. It's not the tablespaces that are temporary. The SQL standard meaning of temporary is that the content goes away. It is only in PostgreSQL that it also means that the object

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On Tue, Jun 6, 2017 at 04:39:50AM -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > > 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

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

Andres Freund wrote: > 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

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On Mon, Jun 5, 2017 at 07:38:43PM -0700, Andres Freund wrote: > 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

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

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

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

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

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

Bruce Momjian writes: > On Wed, May 31, 2017 at 08:28:51AM -0700, Mark Dilger wrote: > >> > Uh, I thought only the sessions that created the temporary objects could >> > see them, and since they are not in WAL and autovacuum can't see them, >> > their non-existence in a

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On Wed, May 31, 2017 at 08:28:51AM -0700, Mark Dilger wrote: > > Uh, I thought only the sessions that created the temporary objects could > > see them, and since they are not in WAL and autovacuum can't see them, > > their non-existence in a temporary tablespace would not be a problem. > > You

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

> On May 31, 2017, at 7:58 AM, Bruce Momjian wrote: > > On Wed, May 31, 2017 at 07:53:22AM -0700, Mark Dilger wrote: >>> Just to clarify, the TEMPORARY clause would allow the tablespace to >>> start up empty, while normal tablespaces can't do that, right? One big >>> problem

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On Wed, May 31, 2017 at 07:53:22AM -0700, Mark Dilger wrote: > > Just to clarify, the TEMPORARY clause would allow the tablespace to > > start up empty, while normal tablespaces can't do that, right? One big > > problem is that we don't have any way to prevent non-temporary > > tablespaces from

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

> On May 31, 2017, at 6:04 AM, Bruce Momjian wrote: > > On Wed, May 31, 2017 at 07:53:53AM -0400, Robert Haas wrote: >> On Tue, May 30, 2017 at 6:50 PM, Mark Dilger wrote: On May 29, 2017, at 11:53 AM, Bruce Momjian wrote:

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On Wed, May 31, 2017 at 9:04 AM, Bruce Momjian wrote: > Just to clarify, the TEMPORARY clause would allow the tablespace to > start up empty, while normal tablespaces can't do that, right? Yeah. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On Wed, May 31, 2017 at 07:53:53AM -0400, Robert Haas wrote: > On Tue, May 30, 2017 at 6:50 PM, Mark Dilger wrote: > >> On May 29, 2017, at 11:53 AM, Bruce Momjian wrote: > >> Right now we don't document that temp_tablespaces can use > >>

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On Tue, May 30, 2017 at 6:50 PM, Mark Dilger wrote: >> On May 29, 2017, at 11:53 AM, Bruce Momjian wrote: >> Right now we don't document that temp_tablespaces can use >> non-restart-safe storage, e.g. /tmp, ramdisks. Would this be safe? >> Should we

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

> On May 29, 2017, at 11:53 AM, Bruce Momjian wrote: > > Right now we don't document that temp_tablespaces can use > non-restart-safe storage, e.g. /tmp, ramdisks. Would this be safe? > Should we document this? The only safe way to do temporary tablespaces that I have found

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On 05/30/2017 10:54 AM, Tom Lane wrote: > Bruce Momjian writes: >> On Mon, May 29, 2017 at 03:55:08PM -0400, Tom Lane wrote: >>> I'm too lazy to search the archives right now, but there was some case >>> years ago where somebody destroyed their database via an ill-thought-out

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

Bruce Momjian writes: > On Mon, May 29, 2017 at 03:55:08PM -0400, Tom Lane wrote: >> I'm too lazy to search the archives right now, but there was some case >> years ago where somebody destroyed their database via an ill-thought-out >> combination of

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On Mon, May 29, 2017 at 03:55:08PM -0400, Tom Lane wrote: > I'm too lazy to search the archives right now, but there was some case > years ago where somebody destroyed their database via an ill-thought-out > combination of automatic-initdb-if-$PGDATA-isn't-there and slow mounting. > We'd have to

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

Re: Tom Lane 2017-05-29 <28291.1496087...@sss.pgh.pa.us> > Andres Freund writes: > > On May 29, 2017 12:15:37 PM PDT, Alvaro Herrera > > wrote: > >> I think it'd be smart to support the use case directly, because there's > >> interest in it being

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

Andres Freund writes: > On May 29, 2017 12:15:37 PM PDT, Alvaro Herrera > wrote: >> I think it'd be smart to support the use case directly, because there's >> interest in it being actually supported (unlike the statu quo). >> Something like

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On May 29, 2017 12:15:37 PM PDT, Alvaro Herrera wrote: >Claudio Freire wrote: >> On Mon, May 29, 2017 at 3:53 PM, Bruce Momjian >wrote: >> > Right now we don't document that temp_tablespaces can use >> > non-restart-safe storage, e.g. /tmp,

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

Claudio Freire wrote: > On Mon, May 29, 2017 at 3:53 PM, Bruce Momjian wrote: > > Right now we don't document that temp_tablespaces can use > > non-restart-safe storage, e.g. /tmp, ramdisks. Would this be safe? > > Should we document this? > > I have set up things like that,

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

On Mon, May 29, 2017 at 3:53 PM, Bruce Momjian wrote: > Right now we don't document that temp_tablespaces can use > non-restart-safe storage, e.g. /tmp, ramdisks. Would this be safe? > Should we document this? I have set up things like that, but it's nontrivial. Just pointing

[HACKERS] Use of non-restart-safe storage by temp_tablespaces

Right now we don't document that temp_tablespaces can use non-restart-safe storage, e.g. /tmp, ramdisks. Would this be safe? Should we document this? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you