Tag Info

Hot answers tagged

9

I believe this is by design, according to the description of the read-committed isolation level for PostgreSQL 9.2: UPDATE, DELETE, SELECT FOR UPDATE, and SELECT FOR SHARE commands behave the same as SELECT in terms of searching for target rows: they will only find target rows that were committed as of the command start time1. However, such a target row ...


7

Mat and Erwin are both right, and I'm only adding another answer to further expand on what they said in a way which won't fit in a comment. Since their answers don't seem to satisfy everyone, and there was a suggestion that PostgreSQL developers should be consulted, and I am one, I will elaborate. The important point here is that under the SQL standard, ...


6

I completely agree with @Mat's excellent answer. I only write another answer, because it wouldn't fit into a comment. In reply to your comment: The DELETE in S2 is already hooked on a particular row version. Since this is killed by S1 in the meantime, S2 considers itself successful. Though not obvious from a quick glance, the series of events virtually is ...


5

The table should be create table cali ( id serial primary key, alk_from bigint, alk_to bigint, and_from int, and_to int ); And do \COPY cali (alk_from, alk_to, and_from, and_to) FROM '/home/.../data/output/id_cali.csv' (FORMAT CSV); So that it knows to not insert into the id serial column. The serial type is not a true type. From ...


5

BLOB is correct, as that is a binary string. TEXT is a character string, but protobuf is not character data; so use some kind of BLOB As for TINY/MEDIUM/LONG; how big is your data? TINYBLOB : max 255 bytes BLOB : max 65,535 bytes MEDIUMBLOB : max 16,777,215 bytes LONGBLOB : max 4,294,967,295 bytes In some small minority of cases TINYBLOB may suffice, ...


3

This is a bit of a FAQ. You'd find more information if you searched for ON DUPLICATE KEY UPDATE (the MySQL syntax), MERGE (the SQL-standard syntax), or UPSERT. It's surprisingly hard. The best article I've seen on it yet is Depesz's "why is upsert so complicated". There's also the SO question Insert, on duplicate update (postgresql) which has suggestions ...


3

No SQL Server will not be able to write directly to a serial port or TCP socket. You'll need to either write an application that pulls the data from the SQL Server, or a SQL CLR procedure that calls out to the TCP IP address and socket. I'd recommend using an app to query the SQL Server database then write that data to the serial port or TCP socket.


1

A READ ONLY transaction cannot cause a write transaction (that does not perform DDL) to fail, unless it explicitly uses LOCK TABLE or advisory locks. READ ONLY transactions cannot SELECT ... FOR SHARE or SELECT ... FOR UPDATE. As they can't do DML, the strongest lock they can take on a table is ACCESS SHARE, which conflicts only with the ACCESS EXCLUSIVE ...



Only top voted, non community-wiki answers of a minimum length are eligible