On Mon, 2007-02-26 at 13:15 -0600, Jason Minion wrote:
This is currently unsupported in mainstream PostgreSQL, as the WAL only
works on the cluster basis. The only options you currently have for
performing this is to use the last full backup and copies of WAL files
to restore the cluster on a
On Fri, 2007-03-23 at 17:16 -0600, Warren Little wrote:
My concern is that there were many more logfiles to be played
following 001011A00FD
(ie 0001011E005C) yet it appears the recovery stop at that
point and called it good.
I would assume all WAL logs would be
Hi!
I've probably missed somthing but here is my problem.
I have a view that is really slow and I ca easily work around the slowness by
bypassing the view and query the real table directly.
Example:
From view, the slow one:
SELECT * from my_view
On Thu, 2007-03-29 at 18:18 +0300, Sabin Coanda wrote:
The problem still persist, and I'm not able to fix it alone.
Is anyone which is using WAL on Windows to tell me some tips to make it
workable, or to confirm there is a problem, please ?
From your earlier problem description you seem to
Simon,
I have no issues with how the error was handled, just the
notification that an error was encountered.
@ 2007-03-23 05:57:33 MDTLOG: restored log file
0001011A00FD from archive
@ 2007-03-23 05:57:35 MDTLOG: incorrect resource manager data
checksum in record at
I ran the command show autovacuum and postgres responds with ON.
My colleague says that I should be able to see it running if I run ps
-aef. He said that he doesn't trust postgres reporting on itself.
When I run the Unix ps command as above I don't see autovacuum. Does
anyone know if
Hi,
On Friday 30 March 2007 16:43, Carol Walter wrote:
| I ran the command show autovacuum and postgres responds with ON.
| My colleague says that I should be able to see it running if I run ps
| -aef. He said that he doesn't trust postgres reporting on itself.
| When I run the Unix ps command
Carol Walter wrote:
I ran the command show autovacuum and postgres responds with ON.
My colleague says that I should be able to see it running if I run ps
-aef. He said that he doesn't trust postgres reporting on itself.
I wouldn't trust your colleague then ...
When I run the Unix ps
On Fri, 2007-03-30 at 08:23 -0600, Warren Little wrote:
On slightly different topic, is there some way to determine the
timeline of the corrupted segment, ie what was the original time of
the last restored transaction.
You need to examine the WAL files using xlogdump available from
Rickard =?iso-8859-1?b?U2r2c3Ry9m0=?= [EMAIL PROTECTED] writes:
I have a view that is really slow and I ca easily work around the slowness by
bypassing the view and query the real table directly.
Let's see the exact definition of the view and EXPLAIN ANALYZE results
for doing it both ways.
Simon Riggs [EMAIL PROTECTED] writes:
I think there is a problem here. If we stop before the end of logs we
should be incrementing the timeline id.
There is no good reason here to think that we have stopped before the
end of logs, and I don't think I want the code bumping the timeline ID
on
On Fri, 2007-03-30 at 12:40 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I think there is a problem here. If we stop before the end of logs we
should be incrementing the timeline id.
There is no good reason here to think that we have stopped before the
end of logs, and I
12 matches
Mail list logo
