On Mon, May 17, 2010 at 2:10 PM, Jim Nasby deci...@decibel.org 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:
On May 6, 2010, at 10:24 PM, Robert Haas wrote:
On Tue, May 4, 2010 at 3:03 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Mon, May 17, 2010 at 2:10 PM, Jim Nasby deci...@decibel.org 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
On Tue, May 4, 2010 at 5:17 PM, Tom Lane t...@sss.pgh.pa.us 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
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 Tue, May 4, 2010 at 2:06 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
Robert Haas escribió:
On Tue, May 4, 2010 at 2:06 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Tue, May 4, 2010 at 3:03 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
Robert Haas robertmh...@gmail.com 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,
Alvaro Herrera alvhe...@commandprompt.com 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
On Tue, May 4, 2010 at 5:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Apr 27, 2010 at 9:59 PM, Robert Haas robertmh...@gmail.com 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
On Sun, Apr 25, 2010 at 9:07 PM, Robert Haas robertmh...@gmail.com 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
On Sun, Apr 25, 2010 at 10:19 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Sun, Apr 25, 2010 at 8:07 PM, Robert Haas robertmh...@gmail.com wrote:
1. We could move the responsibility for removing the files associated
with temp rels from the background writer to the owning backend.
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
On Sun, Apr 25, 2010 at 8:07 PM, Robert Haas robertmh...@gmail.com 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
16 matches
Mail list logo
