Re: Strange locking behaviour

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brian McCane <bmccane(at)mccons(dot)net>
Cc: PostgreSQL <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Strange locking behaviour
Date: 2002-02-23 00:51:26
Message-ID: 21965.1014425486@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Brian McCane <bmccane(at)mccons(dot)net> writes:
> BEGIN WORK ;
> SELECT stockid FROM stocks WHERE ticker = 'M$FT' FOR UPDATE ;
> UPDATE stocks SET nextupdate = NOW + INTERVAL '1 DAY' ;
> ....Insert 7 years of stock data....
> UPDATE stocks SET nextupdate = NOW() ;
> COMMIT WORK ;

What exactly does the "Insert" step do? Why are you bothering to UPDATE
stocks.nextupdate twice in this transaction? It's not like any other
transaction will be able to see the now + 1 day setting. Do you really
mean to update *all* rows of stocks here?

> The program that gets the 5 minute updates does:

> SELECT stockid FROM stocks WHERE nextupdate <= NOW() ;
> -- and for each stockid it finds above
> BEGIN WORK ;
> ....Insert new data...
> COMMIT WORK ;

Again, what exactly does the "Insert" step do? Does it change
stocks.nextupdate? (One would hope so, else there's a tight loop here.)
If it does, won't it block at that point waiting for the other
transaction's updates to be committed?

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Lamar Owen 2002-02-23 04:59:24 Re: What does PGDG stand for in postgresql-7.2-1PGDG.rpm
Previous Message Bruce Momjian 2002-02-22 22:45:39 Re: shared_buffers and effective_cache_size