| Lists: | pgsql-hackers-win32 |
|---|
| From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
|---|---|
| To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, <pgsql-hackers-win32(at)postgresql(dot)org> |
| Subject: | Re: Half filled xlogs |
| Date: | 2005-03-20 16:02:35 |
| Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE6C70EA@algol.sollentuna.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers-win32 |
>I'm looking into copying partially filled xlogs with the Archiver
>process, to allow a more rounded warm standby database option.
>
>My understanding is that on win32, when an xlog file is still being
>written to by a backend it will be locked and unable to be copied away
>by another process.
No, that shouldn't be a problem. We open all our files with
FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE (see port/open.c). It
should work fine as the other process that reads it also opens it with
at least FILE_SHARE_READ.
To verify, I started up a backend and did a begin transaction;create
table foo(bar int);
Then I copied the xlog file, and it copied without any errors.
AFAIK, it shuold also contain the actual data, as long as it's been
synced (which would be the same on unix, right?). (or if the file is
opened with o_dsync). I haven't verified it myself, though.
//Magnus
| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Magnus Hagander <mha(at)sollentuna(dot)net> |
| Cc: | pgsql-hackers-win32(at)postgresql(dot)org |
| Subject: | Re: Half filled xlogs |
| Date: | 2005-03-20 23:09:03 |
| Message-ID: | 1111360143.11750.424.camel@localhost.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers-win32 |
On Sun, 2005-03-20 at 17:02 +0100, Magnus Hagander wrote:
> >I'm looking into copying partially filled xlogs with the Archiver
> >process, to allow a more rounded warm standby database option.
> >
> >My understanding is that on win32, when an xlog file is still being
> >written to by a backend it will be locked and unable to be copied away
> >by another process.
>
> No, that shouldn't be a problem.
OK, good. That makes it a lot simpler.
I'll post a design that explains that soon.
> We open all our files with
> FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE (see port/open.c). It
> should work fine as the other process that reads it also opens it with
> at least FILE_SHARE_READ.
...but its the implications that count!
> To verify, I started up a backend and did a begin transaction;create
> table foo(bar int);
> Then I copied the xlog file, and it copied without any errors.
>
> AFAIK, it shuold also contain the actual data, as long as it's been
> synced (which would be the same on unix, right?). (or if the file is
> opened with o_dsync). I haven't verified it myself, though.
I was hoping to verify by theory - but I'll go for it then we can test.
Best Regards, Simon Riggs