Re: [GENERAL] Unlogged Crash Detection

2017-08-29 Thread Michael Paquier
On Tue, Aug 29, 2017 at 11:09 PM, Andres Freund wrote: > Huh, but that's not particularly meaningful, is it? That'll just as well > be the case for a freshly created relation, no? I have assumed that the OP has some control on the timing of the relations, using an event

Re: [GENERAL] Unlogged Crash Detection

2017-08-29 Thread Andres Freund
On 2017-08-29 20:19:52 +0900, Michael Paquier wrote: > On Tue, Aug 29, 2017 at 6:06 PM, Gersner wrote: > > I see, interesting. > > Please do not top-post. This is not the recommended way of dealing > with threads on this mailing list. > > > We have lots of unlogged tables,

Re: [GENERAL] Unlogged Crash Detection

2017-08-29 Thread Michael Paquier
On Tue, Aug 29, 2017 at 6:06 PM, Gersner wrote: > I see, interesting. Please do not top-post. This is not the recommended way of dealing with threads on this mailing list. > We have lots of unlogged tables, upon a crash we want to create a > feedback/alert that data

Re: [GENERAL] Unlogged Crash Detection

2017-08-29 Thread Gersner
I see, interesting. We have lots of unlogged tables, upon a crash we want to create a feedback/alert that data disappeared. Not very familiar with the internal structure, but is it possible to identify if the current table is the INIT_FORKNUM? Gersner On Tue, Aug 29, 2017 at 11:27 AM, Michael

Re: [GENERAL] Unlogged Crash Detection

2017-08-29 Thread Michael Paquier
On Tue, Aug 29, 2017 at 5:17 PM, Gersner wrote: > Is there a reliable way to distinguish between an empty unlogged table to an > unlogged table which has been truncated due to a crash? Why do you want to make such a difference? At the beginning of a crash recovery all the, the

[GENERAL] Unlogged Crash Detection

2017-08-29 Thread Gersner
Is there a reliable way to distinguish between an empty unlogged table to an unlogged table which has been truncated due to a crash? Gersner.