Added to TODO.detail and TODO list.
> [ Charset ISO-8859-1 unsupported, converting... ]
> > > There are two parts to transaction commit. The first is writing all
> > > dirty buffers or log changes to the kernel, and second is fsync of the
> >
> > Backend doesn't write any dirty
[ Charset ISO-8859-1 unsupported, converting... ]
> > There are two parts to transaction commit. The first is writing all
> > dirty buffers or log changes to the kernel, and second is fsync of the
>
> Backend doesn't write any dirty buffer to the kernel at commit time.
Yes, I sus
> There are two parts to transaction commit. The first is writing all
> dirty buffers or log changes to the kernel, and second is fsync of the
Backend doesn't write any dirty buffer to the kernel at commit time.
> log file.
The first part is writing commit record into WAL buffer
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Now all you need is a free signal number. Unfortunately we're already
>> using both SIGUSR1 and SIGUSR2.
> Maybe you could dump the old meaning SIGQUIT (externally invoked error),
> move quickdie() to SIGQUIT, and you got SIGUSR1 free.
> (That woul
> Tom Lane writes:
>
> > OK, we can probably assume that at least one of sigsuspend or sigpause
> > is available everywhere.
>
> #ifdef HAVE_POSIX_SIGNALS should tell you.
>
> > Now all you need is a free signal number. Unfortunately we're already
> > using both SIGUSR1 and SIGUSR2.
>
> Maybe
Tom Lane writes:
> OK, we can probably assume that at least one of sigsuspend or sigpause
> is available everywhere.
#ifdef HAVE_POSIX_SIGNALS should tell you.
> Now all you need is a free signal number. Unfortunately we're already
> using both SIGUSR1 and SIGUSR2.
Maybe you could dump the old
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > how about sigpause, and using SIGUSR1/SIGUSR2 to wake them up ?
>
> > The standard is sigsuspend:
>
> OK, we can probably assume that at least one of sigsuspend or sigpause
> is available everywhere. Now all you need is a free signal number.
Larry Rosenman writes:
> how about sigpause, and using SIGUSR1/SIGUSR2 to wake them up ?
Both of these signals are already used.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Bruce Momjian <[EMAIL PROTECTED]> writes:
> how about sigpause, and using SIGUSR1/SIGUSR2 to wake them up ?
> The standard is sigsuspend:
OK, we can probably assume that at least one of sigsuspend or sigpause
is available everywhere. Now all you need is a free signal number.
Unfortunately
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> how about sigpause, and using SIGUSR1/SIGUSR2 to wake them up ?
>
> > Looks like a winner.
>
> sigpause() is a BSD-ism, and not part of any recognized standard
> according to my HP man pages. How portable do you think it is?
Good point. I get
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> how about sigpause, and using SIGUSR1/SIGUSR2 to wake them up ?
> Looks like a winner.
sigpause() is a BSD-ism, and not part of any recognized standard
according to my HP man pages. How portable do you think it is?
regards,
> * Tom Lane <[EMAIL PROTECTED]> [001117 23:21]:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Other backend will see they are not the lowest
> > > WAIT_ON_FSYNC and will wait for their byte to be set to NOT_IN_COMMIT
> > > so they can then continue, knowing their data was synced.
> >
> > H
* Tom Lane <[EMAIL PROTECTED]> [001117 23:21]:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Other backend will see they are not the lowest
> > WAIT_ON_FSYNC and will wait for their byte to be set to NOT_IN_COMMIT
> > so they can then continue, knowing their data was synced.
>
> How will they w
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Other backend will see they are not the lowest
> > > WAIT_ON_FSYNC and will wait for their byte to be set to NOT_IN_COMMIT
> > > so they can then continue, knowing their data was synced.
> >
> > How will they wait? Without a semaphore involved,
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Other backend will see they are not the lowest
> > WAIT_ON_FSYNC and will wait for their byte to be set to NOT_IN_COMMIT
> > so they can then continue, knowing their data was synced.
>
> How will they wait? Without a semaphore involved, your answer
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Other backend will see they are not the lowest
> WAIT_ON_FSYNC and will wait for their byte to be set to NOT_IN_COMMIT
> so they can then continue, knowing their data was synced.
How will they wait? Without a semaphore involved, your answer must
be eit
> > sleep(3) should conform to POSIX specification, if anyone has the
> > reference they can check it to see what the effect of sleep(0)
> > should be.
>
> Yes, but Posix also specifies sched_yield() which rather explicitly
> allows a process to yield its timeslice. No idea how well that is
>
17 matches
Mail list logo
