)
Regards
Venki
---Original Message---
From: Martijn van Oosterhout
Date: 11/02/05 17:47:26
To: Venki
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Disappearing Records
On Wed, Nov 02, 2005 at 05:00:35PM +0530, Venki wrote:
> >The really nasty thing about it is that becau
In article <[EMAIL PROTECTED]>,
Douglas McNaught <[EMAIL PROTECTED]> writes:
> Rory Browne <[EMAIL PROTECTED]> writes:
>> select u.username, g.groupname from users u, groups g where u.group_id=g.id
>> (assuming users are in exactly one group)
>>
>> If the group_id field in the users table was cor
On Wed, Nov 02, 2005 at 10:28:56AM -0500, Tom Lane wrote:
> Looking at the code, I think that actually a regular, non-FREEZE VACUUM
> would do the "right thing" for tuples up to about 1 billion xacts past
> wrap, which is probably enough. So the answer may be "just VACUUM".
> I'm still too lazy to
Martijn van Oosterhout writes:
> On Wed, Nov 02, 2005 at 09:46:38AM -0500, Tom Lane wrote:
>> You sure about that? I think VACUUM just tests for "committed or not".
>>
>> I'm too lazy to set up a test case, but it's possible that VACUUM FREEZE
>> would resurrect wrapped-around tuples, or could b
On Wed, Nov 02, 2005 at 09:46:38AM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > The really nasty thing about it is that because the records are now
> > considered really old, as soon as you do run VACUUM it'll start
> > removing the rows you want to save...
>
> You sure about that?
Martijn van Oosterhout writes:
> The really nasty thing about it is that because the records are now
> considered really old, as soon as you do run VACUUM it'll start
> removing the rows you want to save...
You sure about that? I think VACUUM just tests for "committed or not".
I'm too lazy to s
Rory Browne <[EMAIL PROTECTED]> writes:
> select u.username, g.groupname from users u, groups g where u.group_id=g.id
> (assuming users are in exactly one group)
>
> If the group_id field in the users table was corrupted, and set to a
> value that isn't in the groups table, then that view wouldn't
Thanks guys for your suggestions, but the problem turned out to be my
lack of experience(with PostgreSQL), combined with a bug in our PHP
Code.
Coming from a MySQL background, I assumed that if you "select x from
y", then y would be the name of a table. It turned out that in the
case that y was ac
On Wed, Nov 02, 2005 at 05:00:35PM +0530, Venki wrote:
> >The really nasty thing about it is that because the records are now
> >considered really old, as soon as you do run VACUUM it'll start
> >removing the rows you want to save...
> So does this mean that when we do a vacuum for the first time
Am I wrong in this?
regards
Venki
---Original Message---
From: Martijn van Oosterhout
Date: 11/02/05 17:09:45
To: John Sidney-Woollett
Cc: Venki; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Disappearing Records
On Wed, Nov 02, 2005 at 07:40:29AM +, John Sidney-Woolle
On Wed, Nov 02, 2005 at 07:40:29AM +, John Sidney-Woollett wrote:
> If you have suffered data loss for this reason, then you'll need to get
> help from the developers to see whether it can be recovered, or what you
> can do to reconstruct the data.
The really nasty thing about it is that bec
nced this problem disappearinf records.
regards
Venki
---Original Message---
From: Tom Lane
Date: 11/01/05 20:30:51
To: Rory Browne
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Disappearing Records
Rory Browne <[EMAIL PROTECTED]> writes:
What is th
disappearinf records.
regards
Venki
---Original Message---
From: Tom Lane
Date: 11/01/05 20:30:51
To: Rory Browne
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Disappearing Records
Rory Browne <[EMAIL PROTECTED]> writes:
> What is the first thing you would do, when you
Rory Browne <[EMAIL PROTECTED]> writes:
> What is the first thing you would do, when you find that your system
> has been losing information? Information is there at one stage, and
> later it's not.
Has your system been used long enough that it could be subject to
transaction ID wraparound?
Do you have any cascading deletes that could be doing this by performing
a delete on a different table and cascading to the table in question?
Terry
Rory Browne wrote:
Hi all
What is the first thing you would do, when you find that your system
has been losing information? Information is there
Hi all
What is the first thing you would do, when you find that your system
has been losing information? Information is there at one stage, and
later it's not.
I tried checking the logs, but there isn't a delete or drop there
anywhere, nor anything else that seems relevent. I tried googling for
v
16 matches
Mail list logo
