On Fri, Feb 13, 2009 at 9:49 PM, Tom Lane wrote:
>
> The only other corruption mechanism I can think of is that pg_clog might
> contain commit bits for some logically inconsistent set of transaction
> numbers, due to some pages of pg_clog having made it to disk and others
> not. That could result
On Fri, 2009-02-13 at 11:19 -0500, Tom Lane wrote:
> Aside from the "how did this happen" puzzle, the real point of any
> investigation of course ought to be whether we can make heap_page_prune
> more robust. At the very least it's undesirable to be leaving the page
> in a state where VACUUM FUL
Tom Lane wrote:
Aside from the "how did this happen" puzzle, the real point of any
investigation of course ought to be whether we can make heap_page_prune
more robust. At the very least it's undesirable to be leaving the page
in a state where VACUUM FULL will decide it can't shrink.
I'm as puz
Cheers, i'll give it ago. I'm probably going to do a full restore over
the weekend while i can shut things down without too many complaints...
I can save any of the files if you are interested in them later on...
JOHN
Tom Lane wrote:
John Lister writes:
Any help would be appreciated as th
John Lister writes:
> Any help would be appreciated as the pg_class table is constantly
> growing which i'm guessing is going to start to affect performance
> fairly soon. I'd like to avoid a full restore from backup if possible.
BTW, what I would recommend as a recovery action is to zero out t
John Lister writes:
> Originally in psql-admin, but copied here at the request of Tom to..
Thanks for forwarding this. The reason I wanted to call it to the
attention of pgsql-hackers is that the page contents seem a bit odd,
and I'm not sure that we should just write it off as "pilot error".
Wh
>Please send to pgsql-hackers --- I'd like to get more eyeballs on this.
>There's no personally identifiable information here except that you've
>got a table named temp_queue that you've repeatedly TRUNCATEd or
>CLUSTERed or some such (likely the former since the reltuples counts
>are all zero). I
Joe Conway <[EMAIL PROTECTED]> writes:
> Fortunately this was his own development database he was messing with,
> but it was an interesting exercise none-the-less. Maybe this reinforces
> the need to have a command for enabling/disabling triggers.
No, it reinforces the cardinal rule about not ex
Alvaro Herrera wrote:
On Sat, Aug 30, 2003 at 12:57:26PM -0700, Joe Conway wrote:
Joe Conway wrote:
I don't have any more detail yet on exactly what he was doing at this
point, but I grabbed a copy of $PGDATA and looked at it on my own
machine (since he doesn't have debug and assert support). L
On Sat, Aug 30, 2003 at 12:57:26PM -0700, Joe Conway wrote:
> Joe Conway wrote:
> >I don't have any more detail yet on exactly what he was doing at this
> >point, but I grabbed a copy of $PGDATA and looked at it on my own
> >machine (since he doesn't have debug and assert support). Logging into
Joe Conway wrote:
I don't have any more detail yet on exactly what he was doing at this
point, but I grabbed a copy of $PGDATA and looked at it on my own
machine (since he doesn't have debug and assert support). Logging into
any other database works fine, but the offending database produces this
Tim Allen <[EMAIL PROTECTED]> writes:
> Are there any known database-corrupting bugs in 7.0.3?
None that aren't also in earlier releases, AFAIR, so your report is
fairly troubling. However there's not enough here to venture a guess
about the source of the problem.
Do you see any backend crashes
Can confirm this. Get this just yesterday time ago...
Messages:
NOTICE: Rel acm: TID 1697/217: OID IS INVALID. TUPGONE 1.
And lots of such lines...
And
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or whil
13 matches
Mail list logo
