Jaime Casanova wrote:
On Sun, Dec 14, 2008 at 12:13 PM, Andrew Dunstan wrote:
This version completes properly on Windows with the regression database.
actually, this one doesn't apply cleanly on head
I will have a new patch a day or two after Christmas, which I hope will
be v
On Sun, Dec 14, 2008 at 12:13 PM, Andrew Dunstan wrote:
>
> This version completes properly on Windows with the regression database.
>
actually, this one doesn't apply cleanly on head
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
AsesorÃa y desarrollo de sistemas
Guayaquil
ITAGAKI Takahiro wrote:
Andrew Dunstan wrote:
I did this, but it turned out that the problem was a logic error that I
found once I had managed to get a working debugger. However, the Windows
thread code should now be more robust, so thanks to Andrew and Magnus
for the suggestions.
Andrew Dunstan wrote:
> I did this, but it turned out that the problem was a logic error that I
> found once I had managed to get a working debugger. However, the Windows
> thread code should now be more robust, so thanks to Andrew and Magnus
> for the suggestions.
Hello, I tested parallel r
Andrew Chernow wrote:
If it previously worked without threads, than in theory a deep copy of
the thread_arg should fix the core dump; especially if the non-windows
fork() method works with this patch. Maybe you can get away with only
copying some of the members (trial-n-error), I don't thi
Philip Warner wrote:
Tom Lane wrote:
I think pretty much everybody except Philip Warner has found the stuff
around the TOC data structure and the "archiver" API to be confusing.
I'm not immediately sure about a better design though, at least not if
you don't want to duplicate a lot of code
Tom Lane wrote:
> I think pretty much everybody except Philip Warner has found the stuff
> around the TOC data structure and the "archiver" API to be confusing.
> I'm not immediately sure about a better design though, at least not if
> you don't want to duplicate a lot of code between the plain pg_
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
I'll try. It's unfortunately not as simple as it sounds, because of the
way the abstractions are arranged. I can't count the number of times I
have had to stop and try to clear my head whil
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Andrew Dunstan wrote:
>>> I'll try. It's unfortunately not as simple as it sounds, because of the
>>> way the abstractions are arranged. I can't count the number of times I
>>> have had to stop and try to clear my head while working o
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> I'll try. It's unfortunately not as simple as it sounds, because of the
>> way the abstractions are arranged. I can't count the number of times I
>> have had to stop and try to clear my head while working on this code.
> That's
Andrew Dunstan wrote:
>
>
> Andrew Chernow wrote:
>
> Parts of AH need deep cloning, notably the formatData member, which
> is done in _ReopenArchive().
>
Is it okay to clone this from within the thread?
>>>
>>> I don't see why not.
>>>
>>
>> Because another thread may b
Andrew Chernow wrote:
Parts of AH need deep cloning, notably the formatData member, which
is done in _ReopenArchive().
Is it okay to clone this from within the thread?
I don't see why not.
Because another thread may be modifying the memory you are trying to
clone. If no one modifie
Parts of AH need deep cloning, notably the formatData member, which
is done in _ReopenArchive().
Is it okay to clone this from within the thread?
I don't see why not.
Because another thread may be modifying the memory you are trying to
clone. If no one modifies the formatData struct,
Andrew Dunstan wrote:
No, as this fragment shows, fclose() is NOT called on Windows.
Oooppps. I'm the village idiot today.
The program dies with a nasty dialog box when restoring a dump of the
regression database after the second COPY thread disconnects.
I'll poke around but apparently
Andrew Chernow wrote:
Parts of AH need deep cloning, notably the formatData member, which
is done in _ReopenArchive().
Is it okay to clone this from within the thread?
I don't see why not.
The reopen() appears to mess with AH->FH, which mutltiple threads are
calling fclose on. The
Parts of AH need deep cloning, notably the formatData member, which is
done in _ReopenArchive().
Is it okay to clone this from within the thread?
The reopen() appears to mess with AH->FH, which mutltiple threads are
calling fclose on. The second thread is going to fail and the first
fclo
Andrew Chernow wrote:
Looks like the ArchiveHandle variable 'AH' and the TocEntry
'next_work_item' are not being deep copied at line 315 of your patch,
where you prepare the RestoreArgs struct for the thread. Every thread
is accessing and possibly updating the members of these structs that
Are these threads sharing memory, intentionally or by mistake?
Things they write, and things they read but might not be stable, are
not supposed to be shared. If they are it's a mistake.
Looks like the ArchiveHandle variable 'AH' and the TocEntry
'next_work_item' are not being deep copie
Andrew Dunstan wrote:
Andrew Chernow wrote:
HANDLE h = (HANDLE)_beginthreadex(NULL, 0, thread_start, arg, 0, NULL);
This didn't give me any more joy, unfortunately. But you're right, I
should be using it.
Are these threads sharing memory, intentionally or by mistake?
Things they wr
Andrew Chernow wrote:
HANDLE h = (HANDLE)_beginthreadex(NULL, 0, thread_start, arg, 0, NULL);
This didn't give me any more joy, unfortunately. But you're right, I
should be using it.
Are these threads sharing memory, intentionally or by mistake?
Things they write, and things they re
HANDLE h = (HANDLE)_beginthreadex(NULL, 0, thread_start, arg, 0, NULL);
This didn't give me any more joy, unfortunately. But you're right, I
should be using it.
Are these threads sharing memory, intentionally or by mistake?
if(h)
CloseHandle(h);
Umm, even if I wait on the handle usi
Andrew Chernow wrote:
Andrew Dunstan wrote:
OK, after quite some trying I have hit a brick wall. I have been
unable to get parallel restore to work with Windows threading. No
doubt I am missing something, but I really don't know what. Unless
someone can tell me what I am doing wrong, I hav
Andrew Dunstan wrote:
OK, after quite some trying I have hit a brick wall. I have been unable
to get parallel restore to work with Windows threading. No doubt I am
missing something, but I really don't know what. Unless someone can tell
me what I am doing wrong, I have these possibilities:
OK, after quite some trying I have hit a brick wall. I have been unable
to get parallel restore to work with Windows threading. No doubt I am
missing something, but I really don't know what. Unless someone can tell
me what I am doing wrong, I have these possibilities:
* run parallel steps
24 matches
Mail list logo
