Tom Lane wrote:
> Not sure where this leads to, but it's not leading to an undocumented
> one-line hack in tqual.c, and definitely not *that* one-line hack.

Sorry, here is the proper change I just applied:

/* This is to be used only for disaster recovery and requires serious analysis. */
#ifndef MAKE_ALL_TUPLES_VISIBLE
return false;
#else
return true;
#endif

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

On Sun, Feb 20, 2005 at 09:43:11 -0500,
Bruce Momjian <pgman@candle.pha.pa.us> wrote:
>
> We regularly have people on IRC who delete data and then want to recover
> it. By having the define it makes it easier for us to help them without
> them having to add actual C code.
>
> Does that make sense?

You aren't going to get a consistant snapshot if you get back all of the
deleted rows. With autovacuum it is going to get harder to do this, because
accidentally making large changes in a table is going to trigger a vacuum.
It seems like the right way to do this is a recovery using the PITR
system and putting effort into making that easier is the way to go.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Bruno Wolff III wrote:
> On Sun, Feb 20, 2005 at 09:43:11 -0500,
> Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> >
> > We regularly have people on IRC who delete data and then want to recover
> > it. By having the define it makes it easier for us to help them without
> > them having to add actual C code.
> >
> > Does that make sense?
>
> You aren't going to get a consistant snapshot if you get back all of the
> deleted rows. With autovacuum it is going to get harder to do this, because
> accidentally making large changes in a table is going to trigger a vacuum.

Right, but as far as I remember the vacuum isn't going to reuse the
rows. Rather, it is just going to mark them for later reuse.

> It seems like the right way to do this is a recovery using the PITR
> system and putting effort into making that easier is the way to go.

You are assuming someone is running PITR already, which they might not.

This define is just so we can help folks recover deleted stuff under our
guidance. Also, I think a general GUC mechanism is too dangerous.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Not sure where this leads to, but it's not leading to an undocumented
>> one-line hack in tqual.c, and definitely not *that* one-line hack.

> Sorry, here is the proper change I just applied:

> /* This is to be used only for disaster recovery and requires serious analysis. */
> #ifndef MAKE_ALL_TUPLES_VISIBLE
> return false;
> #else
> return true;
> #endif

AFAICS this has no value whatsoever. Assuming that someone has a
disaster recovery problem on their hands, how likely is it that they
will know that that code is there, or be able to turn it on (most
users don't compile from source anymore), or be able to use it
effectively, given the complete lack of documentation? As is, this
is of value only to someone familiar with the code, and such a someone
could go in and modify the logic for themselves just as easily as
turn on a #define.

I think the only real effect of this patch will be to confuse people
who are reading the source code. tqual.c is already complicated and
fragile enough --- it doesn't need conditionally compiled "features"
that we can't even explain the use of.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> Not sure where this leads to, but it's not leading to an undocumented
> >> one-line hack in tqual.c, and definitely not *that* one-line hack.
>
> > Sorry, here is the proper change I just applied:
>
> > /* This is to be used only for disaster recovery and requires serious analysis. */
> > #ifndef MAKE_ALL_TUPLES_VISIBLE
> > return false;
> > #else
> > return true;
> > #endif
>
> AFAICS this has no value whatsoever. Assuming that someone has a
> disaster recovery problem on their hands, how likely is it that they
> will know that that code is there, or be able to turn it on (most
> users don't compile from source anymore), or be able to use it
> effectively, given the complete lack of documentation? As is, this
> is of value only to someone familiar with the code, and such a someone
> could go in and modify the logic for themselves just as easily as
> turn on a #define.
>
> I think the only real effect of this patch will be to confuse people
> who are reading the source code. tqual.c is already complicated and
> fragile enough --- it doesn't need conditionally compiled "features"
> that we can't even explain the use of.

I need a note somewhere to remember where to tell people to modify the
code to recovery something. Do you have a better idea? You want just a
comment rather than a define?

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Bruce Momjian wrote:
> Tom Lane wrote:
>>I think the only real effect of this patch will be to confuse people
>>who are reading the source code. tqual.c is already complicated and
>>fragile enough --- it doesn't need conditionally compiled "features"
>>that we can't even explain the use of.
>
>
> I need a note somewhere to remember where to tell people to modify the
> code to recovery something. Do you have a better idea? You want just a
> comment rather than a define?

A short guide to disaster recovery would be useful. There's a real
shortage of people qualified to help users in this situation. I feel
comfortable in telling them what *not* to do, but nothing more.

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Sun, 2005-02-20 at 13:08 -0500, Bruce Momjian wrote:
> Bruno Wolff III wrote:
> > On Sun, Feb 20, 2005 at 09:43:11 -0500,
> > Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> > >
> > > We regularly have people on IRC who delete data and then want to recover
> > > it.

That is (one of) the purpose(s) of PITR.

> By having the define it makes it easier for us to help them without
> > > them having to add actual C code.
> > >
> > > Does that make sense?
> >
> > You aren't going to get a consistant snapshot if you get back all of the
> > deleted rows. With autovacuum it is going to get harder to do this, because
> > accidentally making large changes in a table is going to trigger a vacuum.
>
> Right, but as far as I remember the vacuum isn't going to reuse the
> rows. Rather, it is just going to mark them for later reuse.
>
> > It seems like the right way to do this is a recovery using the PITR
> > system and putting effort into making that easier is the way to go.
>
> You are assuming someone is running PITR already, which they might not.

I do hope you/we all recommend PITR as the supported route for recovery
situations?? Otherwise it never will get easier.

If PITR were more clearly recommended, then perhaps more people would
think about about using it ahead of time, just like everybody does with
commercial databases.

Best Regards, Simon Riggs




---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match