Re: Synchronization primitives (Was: Re: [HACKERS] An example of bugs for Hot Standby)

2010-01-20 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
 Streaming Replication introduces a few places with a polling pattern
 like this (in pseudocode):

 while()
 {
   /* Check if variable in shared has advanced beoynd X */
   SpinLockAcquire()
   localvar = sharedvar;
   SpinLockRelease()
   if (localvar  X)
 break;

   /* Not yet. Sleep
   pg_usleep(100);
 }

I trust there's a CHECK_FOR_INTERRUPTS in there ...

 It would be nice to have a new synchronization primitive for that.

Maybe.  The lock, the variable, the comparison operation, and the sleep
time all seem rather specific to each application.  Not sure that it'd
really buy much to try to turn it into a generic subroutine.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: Synchronization primitives (Was: Re: [HACKERS] An example of bugs for Hot Standby)

2010-01-20 Thread Simon Riggs
On Wed, 2010-01-20 at 20:00 +0200, Heikki Linnakangas wrote:

 Hot standby also has a polling loop where it waits for a
 transaction a transaction to die, though I'm not sure if that can be
 fit into the same model

I prefer that in the context of HS because the Startup process is
waiting for things to die. Given that their death may not be handled
sweetly, I would not wish to rely on that to wake Startup.

In the other two cases you mention all processes are working together
normally and we aren't expecting the other processes to die.

-- 
 Simon Riggs   www.2ndQuadrant.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: Synchronization primitives (Was: Re: [HACKERS] An example of bugs for Hot Standby)

2010-01-20 Thread Heikki Linnakangas
Tom Lane wrote:
 Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
 Streaming Replication introduces a few places with a polling pattern
 like this (in pseudocode):
 
 while()
 {
   /* Check if variable in shared has advanced beoynd X */
   SpinLockAcquire()
   localvar = sharedvar;
   SpinLockRelease()
   if (localvar  X)
 break;
 
   /* Not yet. Sleep
   pg_usleep(100);
 }
 
 I trust there's a CHECK_FOR_INTERRUPTS in there ...
 
 It would be nice to have a new synchronization primitive for that.
 
 Maybe.  The lock, the variable, the comparison operation, and the sleep
 time all seem rather specific to each application.  Not sure that it'd
 really buy much to try to turn it into a generic subroutine.

My point is that we should replace such polling loops with something
non-polling, using wait/signal or semaphores or something. That gets
quite a bit more complex. You'd probably still have the loop, but
instead of pg_usleep() you'd call some new primitive function that waits
until the shared variable changes.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: Synchronization primitives (Was: Re: [HACKERS] An example of bugs for Hot Standby)

2010-01-20 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
 My point is that we should replace such polling loops with something
 non-polling, using wait/signal or semaphores or something. That gets
 quite a bit more complex. You'd probably still have the loop, but
 instead of pg_usleep() you'd call some new primitive function that waits
 until the shared variable changes.

Maybe someday --- it's certainly not something we need to mess with for
8.5.  As Simon comments, getting it to work nicely in the face of corner
cases (like processes dying unexpectedly) could be a lot of work.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: Synchronization primitives (Was: Re: [HACKERS] An example of bugs for Hot Standby)

2010-01-20 Thread Heikki Linnakangas
Tom Lane wrote:
 Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
 My point is that we should replace such polling loops with something
 non-polling, using wait/signal or semaphores or something. That gets
 quite a bit more complex. You'd probably still have the loop, but
 instead of pg_usleep() you'd call some new primitive function that waits
 until the shared variable changes.
 
 Maybe someday --- it's certainly not something we need to mess with for
 8.5.  As Simon comments, getting it to work nicely in the face of corner
 cases (like processes dying unexpectedly) could be a lot of work.

Agreed, polling is good enough for 8.5.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: Synchronization primitives (Was: Re: [HACKERS] An example of bugs for Hot Standby)

2010-01-20 Thread David Fetter
On Wed, Jan 20, 2010 at 09:22:49PM +0200, Heikki Linnakangas wrote:
 Tom Lane wrote:
  Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
  My point is that we should replace such polling loops with something
  non-polling, using wait/signal or semaphores or something. That gets
  quite a bit more complex. You'd probably still have the loop, but
  instead of pg_usleep() you'd call some new primitive function that waits
  until the shared variable changes.
  
  Maybe someday --- it's certainly not something we need to mess with for
  8.5.  As Simon comments, getting it to work nicely in the face of corner
  cases (like processes dying unexpectedly) could be a lot of work.
 
 Agreed, polling is good enough for 8.5.

Is this a TODO yet?

Cheers,
David.
-- 
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: Synchronization primitives (Was: Re: [HACKERS] An example of bugs for Hot Standby)

2010-01-20 Thread Tom Lane
David Fetter da...@fetter.org writes:
 On Wed, Jan 20, 2010 at 09:22:49PM +0200, Heikki Linnakangas wrote:
 My point is that we should replace such polling loops with something
 non-polling, using wait/signal or semaphores or something.

 Is this a TODO yet?

It hardly seems concrete enough for a TODO item.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers