On Mon, May 17, 2010 at 2:10 PM, Jim Nasby wrote:
> Any particular reason not to use directories to help organize things? IE:
>
> base/database_oid/pg_temp_rels/backend_pid/relfilenode
>
> Perhaps relfilenode should be something else.
>
> This seems to have several advantages:
>
> 1: It's more org
On Tue, May 4, 2010 at 5:17 PM, Tom Lane wrote:
> FWIW, that's not the case, anymore than it is for blocks in shared
> buffer cache for regular rels. smgrextend() results in an observable
> extension of the file EOF immediately, whether or not you can see
> up-to-date data for those pages.
>
> No
On Mon, May 17, 2010 at 2:10 PM, Jim Nasby wrote:
>> It seems prett clear that it isn't desirable to simply add backend ID
>> to RelFileNode, because there are too many places using RelFileNode
>> already for purposes where the backend ID can be inferred from
>> context, such as buffer headers and
On May 6, 2010, at 10:24 PM, Robert Haas wrote:
> On Tue, May 4, 2010 at 3:03 PM, Alvaro Herrera
> wrote:
> [smgr.c,inval.c] Do we need to call CacheInvalidSmgr for temporary
> relations? I think the only backend that can have an smgr reference
> to a temprel other than the owning bac
On Tue, Apr 27, 2010 at 9:59 PM, Robert Haas wrote:
> [storage.c,xact.c,twophase.c] smgrGetPendingDeletes returns via an out
> parameter (its second argument) a list of RelFileNodes pending delete,
> which we then write to WAL or to the two-phase state file.
It appears that we are playing a littl
On Tue, May 4, 2010 at 5:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> One possible thing we might do (bearing in mind that we might need to
>> wall off access at multiple levels) would be to forbid creating a
>> relcache entry for a non-local temprel. That would, in turn, forbid
>> doing pret
Alvaro Herrera writes:
> I don't very much like the wildcard idea; but I don't think it's
> unreasonable to refuse to provide a file size. If the owning backend
> has still got part of the table in local buffers, you'll get a
> misleading answer, so perhaps it's best to not give an answer at all.
Robert Haas writes:
> One possible thing we might do (bearing in mind that we might need to
> wall off access at multiple levels) would be to forbid creating a
> relcache entry for a non-local temprel. That would, in turn, forbid
> doing pretty much anything to such a relation, although I'm not s
On Tue, May 4, 2010 at 3:03 PM, Alvaro Herrera
wrote:
>> > Hmm, wasn't there a proposal to have the owning backend delete the files
>> > instead of asking the bgwriter to?
>>
>> I did propose that upthread; it may have been proposed previously
>> also. This might be worth doing independently of th
Robert Haas escribió:
> On Tue, May 4, 2010 at 2:06 PM, Alvaro Herrera
> wrote:
> > Robert Haas escribió:
>
> Hey, thanks for writing back! I just spent the last few hours
> thinking about this and beating my head against the wall.
:-)
> >> [smgr.c,inval.c] Do we need to call CacheInvalidSmgr
On Tue, May 4, 2010 at 2:06 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
Hey, thanks for writing back! I just spent the last few hours
thinking about this and beating my head against the wall.
>> [smgr.c,inval.c] Do we need to call CacheInvalidSmgr for temporary
>> relations? I think the
Robert Haas escribió:
> [smgr.c,inval.c] Do we need to call CacheInvalidSmgr for temporary
> relations? I think the only backend that can have an smgr reference
> to a temprel other than the owning backend is bgwriter, and AFAICS
> bgwriter will only have such a reference if it's responding to a
On Sun, Apr 25, 2010 at 9:07 PM, Robert Haas wrote:
> 4. We could add an additional 32-bit value to RelFileNode to identify
> the backend (or a sentinel value when not temp) and create a separate
> structure XLogRelFileNode or PermRelFileNode or somesuch for use in
> contexts where no temp rels ar
On Sun, Apr 25, 2010 at 10:19 PM, Jaime Casanova
wrote:
> On Sun, Apr 25, 2010 at 8:07 PM, Robert Haas wrote:
>>
>> 1. We could move the responsibility for removing the files associated
>> with temp rels from the background writer to the owning backend. I
>> think the reason why we initially tru
On Sun, Apr 25, 2010 at 8:07 PM, Robert Haas wrote:
>
> 1. We could move the responsibility for removing the files associated
> with temp rels from the background writer to the owning backend. I
> think the reason why we initially truncate the files and only later
> remove them is because somebod
Time for a new thread specific to this subject. For previous
discussion, see here:
http://archives.postgresql.org/pgsql-hackers/2010-04/msg01140.php
http://archives.postgresql.org/pgsql-hackers/2010-04/msg01152.php
I attempted to implement this by adding an isTemp argument to relpath,
but ran in
16 matches
Mail list logo
