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
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,
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
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
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
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.