Thread: Advice Needed

Hello Everyone:

I am new to PostgreSQL and I need some advice from the experts. We are 
writing a trucking application in X-Windows with a PostgreSQL back end. 
The application will support about 70 users and about 60% of those users 
are doing a lot of querying and updating of existing records. New data 
is entered daily, but the bulk of the database work is in updating 
existing records as they "move" through various stages of the system. We 
are using C with libpq-fe to access the database. The application 
consists of many tables and interfaces that allow users to populate 
certain text widgets with criteria on which they want to search for 
records. We are loading condensed versions of the data that matches the 
search criteria into a XbaeMatrix widget. If the user decides to 
"detail" one of the records. we find that record again and populate a 
different screen with the complete set of data. If they decide to edit 
the record. we start a transaction, open a cursor, and find the record 
again, redisplay it, and enable various widgets for edit. If they abort 
the edit, we roll back and restore the interface to the pre edit mode. 
If they save the record, we commit the transaction and restore to the 
pre edit mode. Given this scenario, here are my questions.

1.    Does this model make sense based on your work with libpq-fe and 
postgres?

2.    We are only using a binary cursor for the edit operation. Does 
this make sense?

3.    Regarding MVCC and postgres locking model, does the above scenario 
seem reasonable?

I hope the above rambling makes sense. Thanks for any advice anyone can 
provide :o)

-- 
Sparta, NC 28675 USA
336.372.6812
http://www.esc1.com

Terry Lee Tucker <terry@esc1.com> writes:
> [snip]
> 1.    Does this model make sense based on your work with libpq-fe and 
> postgres?

Yes, it looks pretty standard.  But you need to think harder about
exactly what you intend to do when two people try to edit the same
record concurrently.  ("Use a cursor" does not answer that question
at all.)  That's a bit off-topic for pgsql-interfaces though; I'd
recommend discussing it in pgsql-sql.

> 2.    We are only using a binary cursor for the edit operation. Does 
> this make sense?

Not really.  I'd not bother with binary cursors at all.  You're just
opening yourself up to portability problems, and you're not saving
anything meaningful when you're fetching just one row.
        regards, tom lane

Tom,

Thanks for your response. I've considered you comments and I've been 
doing some experimenting with concurrent record updates. I now see what 
you mean in your comment. I've been executing all the queries using 
PQexec. As you well know, PQexec just sits and waits when another 
transaction has hold of the row. I'm wondering if I should use the 
Asynchronous Query routines to manage this. I've got to be able to get 
feedback to the user and give them the ability to abort the transaction. 
Based on what I've been reading it seems the the Asynchronous routines 
would work. What is your response to this? Also, I can't find any code 
examples at all on how to implement the routines. I can find some 
limited discussions about it, but no examples. I could figure it all out 
with trial and error but would like to skip that if possible. Do you 
know where I can find some code examples?

Thanks...

Tom Lane wrote:

>Terry Lee Tucker <terry@esc1.com> writes:
>  
>
>>[snip]
>>1.    Does this model make sense based on your work with libpq-fe and 
>>postgres?
>>    
>>
>
>Yes, it looks pretty standard.  But you need to think harder about
>exactly what you intend to do when two people try to edit the same
>record concurrently.  ("Use a cursor" does not answer that question
>at all.)  That's a bit off-topic for pgsql-interfaces though; I'd
>recommend discussing it in pgsql-sql.
>
>  
>
>>2.    We are only using a binary cursor for the edit operation. Does 
>>this make sense?
>>    
>>
>
>Not really.  I'd not bother with binary cursors at all.  You're just
>opening yourself up to portability problems, and you're not saving
>anything meaningful when you're fetching just one row.
>
>            regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Don't 'kill -9' the postmaster
>
>  
>

-- 
Sparta, NC 28675 USA
336.372.6812
http://www.esc1.com