Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue ago 19 23:35:06 -0400 2010:
>> While I don't care for having smgr.c call tablespace.c, moving the call to
>> md.c instead is surely not an improvement :-(. The problem here is that
>> we'd like the tablespace code to be above the sm
Excerpts from Tom Lane's message of jue ago 19 23:35:06 -0400 2010:
> Robert Haas writes:
> > So I propose moving the TablespaceCreateDbspace() call to mdcreate(),
> > removing the redundant check from smgrcreate(), and deleting that
> > portion of the comment which says this is in the wrong place
On Fri, Aug 20, 2010 at 10:20 AM, Heikki Linnakangas
wrote:
> On 20/08/10 17:01, Robert Haas wrote:
>>
>> On Fri, Aug 20, 2010 at 9:51 AM, Heikki Linnakangas
>> wrote:
>>>
>>> On 20/08/10 16:30, Robert Haas wrote:
I really like the idea of trying to use network-based storage in some
>>
On 20/08/10 17:01, Robert Haas wrote:
On Fri, Aug 20, 2010 at 9:51 AM, Heikki Linnakangas
wrote:
On 20/08/10 16:30, Robert Haas wrote:
I really like the idea of trying to use network-based storage in some
way. Gigabit Ethernet is a big I/O channel.
NFS?
I don't particularly trust NFS to
On Fri, Aug 20, 2010 at 9:51 AM, Heikki Linnakangas
wrote:
> On 20/08/10 16:30, Robert Haas wrote:
>>
>> I really like the idea of trying to use network-based storage in some
>> way. Gigabit Ethernet is a big I/O channel.
>
> NFS?
I don't particularly trust NFS to be either reliable or performan
On 20/08/10 16:30, Robert Haas wrote:
I really like the idea of trying to use network-based storage in some
way. Gigabit Ethernet is a big I/O channel.
NFS?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
Robert Haas writes:
> ... Perhaps tablespace.c shouldn't assume
> anything about the underlying filesystem representation and that
> knowledge should be moved somewhere under src/backend/storage, but I
> don't see how it makes sense for the smgr layer to include assumptions
> about what filesyste
On Fri, Aug 20, 2010 at 8:45 AM, Greg Stark wrote:
> On Fri, Aug 20, 2010 at 3:43 AM, Robert Haas wrote:
>> A related, interesting question is whether there's any purpose to the
>> smgr layer at all. Would we accept a patch that implemented an
>> alternative smgr layer, perhaps on a per-tablespa
On Thu, Aug 19, 2010 at 11:35 PM, Tom Lane wrote:
> While I don't care for having smgr.c call tablespace.c, moving the call to
> md.c instead is surely not an improvement :-(. The problem here is that
> we'd like the tablespace code to be above the smgr code, not below.
> Calling it from md.c mak
On 20/08/10 15:45, Greg Stark wrote:
On Fri, Aug 20, 2010 at 3:43 AM, Robert Haas wrote:
A related, interesting question is whether there's any purpose to the
smgr layer at all. Would we accept a patch that implemented an
alternative smgr layer, perhaps on a per-tablespace basis?
I definitel
On Fri, Aug 20, 2010 at 3:43 AM, Robert Haas wrote:
> A related, interesting question is whether there's any purpose to the
> smgr layer at all. Would we accept a patch that implemented an
> alternative smgr layer, perhaps on a per-tablespace basis?
I definitely want to keep it.
I think we coul
Robert Haas writes:
> So I propose moving the TablespaceCreateDbspace() call to mdcreate(),
> removing the redundant check from smgrcreate(), and deleting that
> portion of the comment which says this is in the wrong place.
While I don't care for having smgr.c call tablespace.c, moving the call t
smgrcreate() currently contains a call to TablespaceCreateDbspace().
As the comment says, this is a rather silly place to put it. The
silliest thing about it, IMHO, is that it forces the following check
to be done in both smgrcreate() and mdcreate():
if (isRedo && reln->md_fd[forknum] != NU
13 matches
Mail list logo
