Tom Lane wrote:
There are, however, a bunch of local bugs, including these:
* On a symlink-less platform (ie, Windows), TablespaceCreateDbspace is
#ifdef'd to be a no-op. This is wrong because it performs the essential
function of re-creating a tablespace or database directory if needed
Qingqing Zhou [EMAIL PROTECTED] wrote
Tom Lane [EMAIL PROTECTED] wrote
What we should be seeing, and don't see, is an indication of a backup
block attached to this WAL record. Furthermore, I don't see any
indication of a backup block attached to *any* of the WAL records in
Alex's
On Mon, 2006-03-27 at 22:03 -0500, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I think what's happened here is that VACUUM FULL moved the only tuple
off page 1 of the relation, then truncated off page 1, and now
heap_update_redo is panicking
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2006-03-27 at 22:03 -0500, Tom Lane wrote:
The subsequent replay of the deletion or truncation
will get rid of any unwanted data again.
Trouble is, it is not a watertight assumption that there *will be* a
subsequent truncation, even if it is a
On Tue, Mar 28, 2006 at 10:07:35AM -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2006-03-27 at 22:03 -0500, Tom Lane wrote:
The subsequent replay of the deletion or truncation
will get rid of any unwanted data again.
Trouble is, it is not a watertight assumption
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, Mar 28, 2006 at 10:07:35AM -0500, Tom Lane wrote:
Well, in fact we'll have correctly recreated the page, so I'm not
thinking that it's necessary or desirable to check this.
Would the suggestion made in
On Tue, 2006-03-28 at 10:07 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2006-03-27 at 22:03 -0500, Tom Lane wrote:
The subsequent replay of the deletion or truncation
will get rid of any unwanted data again.
Trouble is, it is not a watertight assumption that
I wrote:
* log_heap_update decides that it can set XLOG_HEAP_INIT_PAGE instead
of storing the full destination page, if the destination contains only
the single tuple being moved. This is fine, except it also resets the
buffer indicator for the *source* page, which is wrong --- that page
may
Tom Lane [EMAIL PROTECTED] wrote
What we should be seeing, and don't see, is an indication of a backup
block attached to this WAL record. Furthermore, I don't see any
indication of a backup block attached to *any* of the WAL records in
Alex's printout. The only conclusion I can draw is
[ redirecting to a more appropriate mailing list ]
Alex bahdushka [EMAIL PROTECTED] writes:
LOG: REDO @ D/19176610; LSN D/19176644: prev D/191765E8; xid 81148979: Heap
- clean: rel 1663/16386/16559898; blk 0
LOG: REDO @ D/19176644; LSN D/191766A4: prev D/19176610; xid 81148979: Heap
-
Tom Lane [EMAIL PROTECTED] writes:
I think what's happened here is that VACUUM FULL moved the only tuple
off page 1 of the relation, then truncated off page 1, and now
heap_update_redo is panicking because it can't find page 1 to replay the
move. Curious that we've not seen a case like this
Greg Stark [EMAIL PROTECTED] writes:
This sounds familiar
http://archives.postgresql.org/pgsql-hackers/2005-05/msg01369.php
Hm, I had totally forgotten about that todo item :-(. Time to push it
back up the priority list.
regards, tom lane
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I think what's happened here is that VACUUM FULL moved the only tuple
off page 1 of the relation, then truncated off page 1, and now
heap_update_redo is panicking because it can't find page 1 to replay the
move. Curious
13 matches
Mail list logo
