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
"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 dra
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
>
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 assump
"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
> http://archives.postgresql.org/pg
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
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
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 i
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
>> mov
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
--
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
[ 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
13 matches
Mail list logo
