From: | Mike Mascari <mascarm(at)mascari(dot)com> |
---|---|
To: | Mike Mascari <mascarm(at)mascari(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Win32 rename()/unlink() questions |
Date: | 2002-09-20 05:01:03 |
Message-ID: | 3D8AAB8F.8010001@mascari.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mike Mascari wrote:
> Bruce Momjian wrote:
>
>> Mike Mascari wrote:
>>
>>> I will do some testing with concurrency and let you know. But don't
>>> get your hopes up. This is one of the many advantages that
>>> TABLESPACEs have when more than one relation is stored in a single
>>> DATAFILE. There was Oracle for MS-DOS, after all..
>>
>>
>>
>> I was focusing on handling of pg_pwd and other config file that are
>> written by various backend while other backends are reading them. The
>> actual data files should be OK because we have an exclusive lock when we
>> are adding/removing them.
>>
>
> OK. So you want to test:
>
> 1. Process 1 opens "foo"
> 2. Process 2 opens "foo"
> 3. Process 1 renames "foo" to "bar"
> 4. Process 2 can safely read from its open file handle
Actually, looking at the pg_pwd code, you want to determine a
way for:
1. Process 1 opens "foo"
2. Process 2 opens "foo"
3. Process 1 creates "bar"
4. Process 1 renames "bar" to "foo"
5. Process 2 can continue to read data from the open file handle
and get the original "foo" data.
Is that correct?
Mike Mascari
mascarm(at)mascari(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-09-20 05:29:33 | Re: Win32 rename()/unlink() questions |
Previous Message | Mike Mascari | 2002-09-20 04:31:46 | Re: Win32 rename()/unlink() questions |