Bright D.L. wrote:
>Once step 6 completes, can psql see the data?
Yes, P1 makes sure and is able to see the data before sending Packet to
P2.
Not P1, but psql. If you can see the data from psql, then your problem
has to be in P2. If you can't see the data from psql, then P1 is the
probl
"Bright D.L." <[EMAIL PROTECTED]> writes:
> P1 did commit its insertion and verified it by successfully querying the
> last inserted data, before sending the TCP packet - the trigger - to P2
The fact that P1 can see data it inserted is no proof at all that it's
committed its transaction. I think
>> Processes P1 and P2 are executables developed in VC++. These are the
>> steps performed by P1 before sending the TCP packet (which acts as a
>> trigger) to P2.
>>
>> 1) Create an insertion query
>> 2) Execute the query
>> 3) Execute a 'Commit' command
> 4) Repeat 2 and 3 how many ever times need
Bright D.L. wrote:
Processes P1 and P2 are executables developed in VC++. These are the
steps performed by P1 before sending the TCP packet (which acts as a
trigger) to P2.
1) Create an insertion query
2) Execute the query
3) Execute a 'Commit' command
4) Repeat 2 and 3 how many ever times neede
>hi,
>have a look at transaction isolation in docs
Thanks TM. I checked the isolation level of the DB and it is "read
committed". May be I will change it to 'Serializable' and check whether
that helps.
>/tm
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
>> The scenario:
>> There are two separate processes ? one (P1) inserting
(not
>> updating) data to a table at a high rate (around one record in 10ms)
and
>> another (P2) selecting the data from the same table for further
>>processing. P1
>> and P2 use separate connection to the Databas
Thank you Craig,
>At a guess: transactional visibility. P1 will have not yet committed
its
>transaction, so the data isn't visible to P2 yet. Remember, PostgreSQL
>defaults to the READ COMMITTED isolation level and does not offer READ
>UNCOMMITTED for those rare situations where you might want it.
Bright D.L. wrote:
> I would like to know why P1 can retrieve the data from the table while
> P2 can't.
At a guess: transactional visibility. P1 will have not yet committed its
transaction, so the data isn't visible to P2 yet. Remember, PostgreSQL
defaults to the READ COMMITTED isolation level an
am Wed, dem 09.07.2008, um 16:32:11 +0800 mailte Bright D.L. folgendes:
> The scenario:
> There are two separate processes ? one (P1) inserting (not
> updating) data to a table at a high rate (around one record in 10ms) and
> another (P2) selecting the data from the same table for furt
hi,
have a look at transaction isolation in docs
/tm
begin:vcard
fn:Thomas Markus
n:Markus;Thomas
org:proventis GmbH
adr:;;Zimmerstr. 79-80;Berlin;Berlin;10117;Germany
email;internet:[EMAIL PROTECTED]
tel;work:+49 30 29 36 399 22
x-mozilla-html:FALSE
url:http://www.proventis.net
version:2.1
end
10 matches
Mail list logo
