Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment
Date
Msg-id 46D6B86C.1040203@phlo.org
Whole thread Raw
In response to Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment  (Gregory Stark <stark@enterprisedb.com>)
Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> And I'm quite tempted to not flush the XLOG at all during ABORT, and to
>> only force synchronous commits if one of the to-be-deleted files is
>> non-temporary.
> 
> +1 on the first, but -1 on the second, because we'd have to track
> whether deleted files are temp or not ... it's very unclear that it'd
> be worth the trouble.

I'm confused. smgrcreate already tracks if it created a file for a temp
relation or not (at least it has an isTemp parameter, which it also
stores in the delete list). I'd have thought the second suggestion would
amount to a few lines of code in smgrGetPendingDeletes to let it report
if all pending deletes carried the isTemp flag or not.

>>> The only way we could make this more robust is if we could have
>>> WAL-before-data rule for file *creation*, but I think that's not
>>> possible given that we don't know what relfilenode number we will use
>>> until we've successfully created a file.
> 
>> It seems doable, but it's not pretty. One possible scheme would be to
>> emit a record *after* chosing a name but *before* creating the file,
> 
> No, because the way you know the name is good is a successful
> open(O_CREAT).

The idea was to log *twice*. Once the we're about to create a file, and
the second time that we succeeded. That way, the filename shows up in the
log, even if we crash immediatly after physically creating the file, which
gives recovery at least a chance to clean up the mess.

greetings, Florian Pflug



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [DOCS] Contrib modules documentation online
Next
From: "Gabor Szabo"
Date:
Subject: testing more than one configuration on a single build machine