Re: [GENERAL] problem with pg_restore?
Jim Michaels, 15.07.2009 01:47: most programmer's text editors can't handle more than 2000 characters per line. and I want to be able to edit my dumps. I don't know what you are using, but the following editors can certainly handle more than 2000 characters: OpenSource and free: http://www.pnotepad.org http://www.pspad.com http://notepad-plus.sourceforge.net Commercial (but not expensive) http://www.textpad.com I have edited files with more than 1 characters per line in PNotepad, PSPad and Textpad Thomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] pg_stat_reset() not resetting all statistics counters
Hello Should not the execution of pg_stat_reset() reset *all* statistics counters everywhere in the database? We would like to use the numbers in pg_stat_database together with pg_postmaster_start_time() to find out the average values per second of some of the columns in this view. But when we execute pg_stat_reset() in our databases, not all values reported by pg_stat_database get updated. tup_returned, tup_fetched, tup_inserted, tup_updated and tup_deleted still have the old values after running pg_stat_reset(). Am I missing anything? Example: postgreSQL 8.3.7 running in a x86_64 GNU/Linux server. Data from pg_stat_database for the database 'rtprod' *before* running pg_stat_reset(): -[ RECORD 5 ]-+-- datid | 16777 datname | rtprod numbackends | 40 xact_commit | 1800706565 xact_rollback | 98722 blks_read | 1384382954 blks_hit | 70569876640 tup_returned | 1742826466651 tup_fetched | 67404470469 tup_inserted | 54681321 tup_updated | 11495258 tup_deleted | 18167792 Data from pg_stat_database for the database 'rtprod' *after* running pg_stat_reset(): -[ RECORD 5 ]-+-- datid | 16777 datname | rtprod numbackends | 40 xact_commit | 1 xact_rollback | 2 blks_read | 60 blks_hit | 264238 tup_returned | 1742832161264 tup_fetched | 67407042466 tup_inserted | 54681617 tup_updated | 11495340 tup_deleted | 18167979 Any ideas? regards, -- Rafael Martinez, r.m.guerr...@usit.uio.no Center for Information Technology Services University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_stat_reset() not resetting all statistics counters
Rafael Martinez wrote: But when we execute pg_stat_reset() in our databases, not all values reported by pg_stat_database get updated. tup_returned, tup_fetched, tup_inserted, tup_updated and tup_deleted still have the old values after running pg_stat_reset(). Am I missing anything? I suppose that http://archives.postgresql.org/pgsql-hackers/2009-04/msg00520.php explains why this happens :( -- Rafael Martinez, r.m.guerr...@usit.uio.no Center for Information Technology Services University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_stat_reset() not resetting all statistics counters
Brad Nicholson wrote: On Wed, 2009-07-15 at 14:13 +0200, Rafael Martinez wrote: Hello Should not the execution of pg_stat_reset() reset *all* statistics counters everywhere in the database? It only resets the stats for the current database, not the cluster wide stats - pg_database is cluster wide. Jepp, thanks, but this explanation is an 'internal' explanation. A *normal* user sees a row per database when running pg_stat_database and that all the columns have values per database. It looks wrong and it is not logic if half of the columns for a database returned by pg_stat_database get a new value and the other half still have old values after running pg_stat_reset(). Don't you think? Specially when values associated to inserts, updates, deleted, etc in pg_stat_user_* get a new value after running pg_stat_reset(). In my humble opinion this not a consistent behavior. regards, -- Rafael Martinez, r.m.guerr...@usit.uio.no Center for Information Technology Services University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_stat_reset() not resetting all statistics counters
On Wed, 2009-07-15 at 14:13 +0200, Rafael Martinez wrote: Hello Should not the execution of pg_stat_reset() reset *all* statistics counters everywhere in the database? It only resets the stats for the current database, not the cluster wide stats - pg_database is cluster wide. -- Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] initdb --locale=LATIN1 fails on Windows
The same command worked fine on PG 8.2.4. Now, using 8.3.7, the command succeeds only with locale 1252. It comments something on wrong lc_ctype. Any idea? Thanks Danny -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] filter duplicates by priority
This solved my problem. Now why didn't I think of that!? Thank you very much everybody. This list is an incredible resource. -Clark AFAICS, changing it to ORDER BY part_number,priority would solve the stated problem. If you really need the final result in priority rather than part number order, put the whole thing in a sub-select and re-sort outside it. regards, tom lane Clark Slater p...@slatech.com writes: I am trying to use DISTINCT ON to filter out *potential* duplicate values from a set of sub queries. There are certain cases where there can be repetitive part numbers that are priced differently. I'm trying to start with the full list, ordered by priority, and then remove any repeats that have a lesser priority. SELECT DISTINCT ON (part_number) * FROM ( SELECT part_number, priority FROM ... UNION ALL SELECT part_number, priority FROM ... UNION ALL SELECT part_number, priority FROM ... ) AS filter_duplicates ORDER BY priority,part_number The above statement does not work because if I ORDER BY priority,part_number then I have to DISTINCT ON (priority,part_number). But DISTINCT ON (priority, part_number) does not remove the repeated rows because the same part_number with a different priority becomes a distinct tuple. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Connection pool or load balancer supporting ident authentication
Hi. Is anyone aware of a connection pool or load balancer for PostgreSQL that supports ident based authentication? Neither pgpool-ii nor pgbouncer support this according to their docs, so I was wondering what else is out there. -- Stuart Bishop stu...@stuartbishop.net http://www.stuartbishop.net/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb --locale=LATIN1 fails on Windows
Abraham, Danny danny_abra...@bmc.com writes: Yeah, it should fail. LATIN1 is not a locale name. The same command worked fine on PG 8.2.4. If so, that was a bug in 8.2. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Automatic type conversion
I'm in the process of attempting to upgrade from 8.1 to 8.4, and I've been using the uniqueidentifier contrib module for my UUID's ... In 8.1 Postgresql was able to figure out what to do with statements like # SELECT 'Your new UUID is ' || newid(); ?column? --- Your new UUID is 5f1a4987-9005-42d6-8e62-d1ff14bb1433 (1 row) but in 8.4 (and probably 8.3 also...), # SELECT 'Your new UUID is ' || newid(); ERROR: operator is not unique: unknown || uniqueidentifier LINE 1: SELECT 'Your new UUID is ' || newid(); ^ HINT: Could not choose a best candidate operator. You might need to add explicit type casts. But, with the new internal UUID datatype, what is the magic recipe that allows this to run? # SELECT 'Your new UUID is ' || uuid_generate_v4(); ?column? --- Your new UUID is cd8d8f5f-3eea-4e96-be4f-f93daa174d8f (1 row) I could add the explicit type casts, but I'd rather find out what the nature of the subtle (or not-so-subtle) difference I've stumbled upon is...
[GENERAL] Function does not exist
Hello, I have create my own function name *addnewuser(integer,varchar.)*, and when I call this function it gives me below error, org.postgresql.util.PSQLException: ERROR: function addnewuser(bigint, character varying, character varying, character varying, character varying, character varying, character varying, unknown, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, integer) does not exist Even though function exist why it gives me this error, we use postgres-8.3.7 latest. We install postgres by .tar,gz file. -- Thanks, Dipesh If you can't make a mistake, you can't make anything.
Re: [GENERAL] Automatic type conversion
CG wrote: I could add the explicit type casts, but I'd rather find out what the nature of the subtle (or not-so-subtle) difference I've stumbled upon is... It's an intentional change, so adding typecasts is the appropriate solution. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] change database
Hi, I'm working on a port from mysql to postgres. I have a function which connect's to the database, checks for database existance and creates it otherwise. The last thing it does it executes use my_database (mysql stuff). Now I'm trying to find something similar in postgres. I know that psql has \c but that dosen't help me with jdbc. I also know that the easy solution out of this is to close the connection and then open it again with /my_database in the URL but I want to avoid this. So what are my options? With thanks, Florian
[GENERAL] savepoints in 8.3.7 or whatever...
we have an app thats doing massive amounts of inserts, batched in transactions, multiple concurrent connections (tuned for optimal throughput, usually around 1 thread per cpu core plus a couple more). occasionally a transaction gets duplicated, and that causes a constraint violation which causes the whole transaction to abort unless we wrap each insert in a savepoint. my developers are asking me if there are limits as to how many savepoints can be active, etc. they have run into various such limits in oracle. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] change database
On Wed, 2009-07-15 at 11:36 +0300, Florian Chis wrote: I'm working on a port from mysql to postgres. I have a function which connect's to the database, checks for database existance and creates it otherwise. The last thing it does it executes use my_database (mysql stuff). Now I'm trying to find something similar in postgres. I know that psql has \c but that dosen't help me with jdbc. I also know that the easy solution out of this is to close the connection and then open it again with /my_database in the URL but I want to avoid this. So what are my options? In PostgreSQL, a schema is similar to a database in MySQL -- both are effectively namespaces (logical separation). You can switch namespaces (schemas) in postgresql without reconnecting by simple set commands, like: SET search_path = my_new_schema, public; In PostgreSQL, a database is more of a physical separation, and your connection is tied to a particular database. This is probably not what you want. More information here: http://www.postgresql.org/docs/8.4/static/sql-createschema.html http://www.postgresql.org/docs/8.4/static/sql-createdatabase.html Regards, Jeff Davis -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] savepoints in 8.3.7 or whatever...
John R Pierce wrote: we have an app thats doing massive amounts of inserts, batched in transactions, multiple concurrent connections (tuned for optimal throughput, usually around 1 thread per cpu core plus a couple more). occasionally a transaction gets duplicated, and that causes a constraint violation which causes the whole transaction to abort unless we wrap each insert in a savepoint. my developers are asking me if there are limits as to how many savepoints can be active, etc. they have run into various such limits in oracle. There's a hard limit of 2^32 savepoints in a transaction, but you'll probably run into limits before that due to memory constraints (I think each savepoint will use at least 8kB). Anyway I suggest you do RELEASE SAVEPOINT after each insert to ensure resources are released as best as possible. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] PL/Python debugging - line numbers
OK, I figured some things out. Lines numbers are shown through PL/Python
if it is a syntax error, but not for a runtime error. I'm not sure if
this is because plpython.c only returns a partial stack trace, or what.
The 6 year old TODO list doesn't mention this (but does mention that
array argument support is almost done).
As a workaround, I found that the traceback module for Python 2.4+ can
supply meaningful information. It does require a try/except block. Here
is an example that will have a runtime exception, and print details of
the stack trace:
CREATE OR REPLACE FUNCTION boo(ar1 text)
RETURNS text AS
$BODY$
import traceback
if False:
loc = ar1 # this never happens
#return loc # uncomment to test a runtime error without line number
shown in PL/Python
try:
return loc
except:
plpy.error(traceback.format_exc())
$BODY$ LANGUAGE 'plpythonu' VOLATILE;
The error message is ugly, but has useful info:
mydb=# select boo('ha');
ERROR: ('Traceback (most recent call last):\n File string, line 9,
in __plpython_procedure_boo_96665\nUnboundLocalError: local variable
\'loc\' referenced before assignment\n',)
The actual error is on line 8 (not 9), which is a bit odd. Perhaps there
is a import plpy inserted somewhere internally.
I noticed that the messages through PL/Python are all tuples with length
1, like this: (my message,). Why? This doesn't print to text too nicely.
- Mike
Mike Toews wrote:
Hi,
Debugging PL/Python isn't as easy as with PL/pgSQL, as it appears I
can't see line numbers where errors occur. For example:
ERROR: plpython: function evaluate_something failed
DETAIL: type 'exceptions.TypeError': sequence index must be
integer, not 'str'
The location of this type of exception is difficult to spot out in 366
lines of code. Is there a way to report where the error occurred? I'm
using 8.3.7 via apt-get on Ubuntu Hardy LTS. I see the same message on
the server using pgsql and in pgAdmin III on a different machine. I've
tried using such options as set client_min_messages to debug; but
this doesn't change the details of the error.
Thanks,
-Mike
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] change database
In response to Florian Chis florian.c...@gmail.com: I'm working on a port from mysql to postgres. I have a function which connect's to the database, checks for database existance and creates it otherwise. The last thing it does it executes use my_database (mysql stuff). Now I'm trying to find something similar in postgres. I know that psql has \c but that dosen't help me with jdbc. I also know that the easy solution out of this is to close the connection and then open it again with /my_database in the URL but I want to avoid this. Close the connection and reopen it. There's no equivalent. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Function does not exist
dipesh mistry (Imap) wrote: Hello, I have create my own function name *addnewuser(integer,varchar.)*, and when I call this function it gives me below error, org.postgresql.util.PSQLException: ERROR: function addnewuser(bigint, character varying, character varying, character varying, character varying, character varying, character varying, unknown, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, integer) does not exist Even though function exist why it gives me this error, we use postgres-8.3.7 latest. We install postgres by .tar,gz file. -- Thanks, Dipesh If you can't make a mistake, you can't make anything. Hi, I suppose you are setting the wrong parameter when calling this function. If you use psql use the short cut command \df to get all functions you built and check this again ... such an error message is mostly a hint that something with the params is wrong ... Cheers Andy -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] best practice transitioning from one datatype to another
Another UUID question... I was hoping to put this off for a while, but it looks like it's going to need to happen sooner than later. Rats! I keep telling myself transitioning to core datatypes is good for the soul. While transitioning from 8.1 to 8.4, I need to transition to the internal UUID type in place of the contrib/uniqueidentifier module. I've built the database around uniqueidentifier, so nearly every table has one column of that data type. It's going to be tedious to ALTER TABLE foo ALTER COLUMN bar SET DATA TYPE uuid; ...repeat 600 times... I'll also have to drop and reload the views and the rules on tables. It'll be tedious even if the tables have no data in them. Can anyone recommend a better/faster way to make the transition?
Re: [GENERAL] initdb --locale=LATIN1 fails on Windows
Do you by chance know what is the ISO88591 locale to be used on Windows? It should be something like Americam_United States.ISO88591. Thanks Danny -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Function does not exist
Hello it's look like problem with casting. You defined function name(integer,...) but you call it with bigint param. Bigint cannot be casted to int - so you have to redefine your func - name(bigint, ... regards Pavel Stehule 2009/7/15 dipesh mistry (Imap) dipesh.mis...@mobilefundas.com: Hello, I have create my own function name addnewuser(integer,varchar.), and when I call this function it gives me below error, org.postgresql.util.PSQLException: ERROR: function addnewuser(bigint, character varying, character varying, character varying, character varying, character varying, character varying, unknown, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, character varying, integer) does not exist Even though function exist why it gives me this error, we use postgres-8.3.7 latest. We install postgres by .tar,gz file. -- Thanks, Dipesh If you can't make a mistake, you can't make anything. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] initdb --locale=LATIN1 fails on Windows
Actually the command is:initdb --encoding=LATIN1. It fails on Windos. fails on Windows The same command worked fine on PG 8.2.4. Now, using 8.3.7, the command succeeds only with encoding 1252. It comments something on wrong lc_ctype. Thanks Danny -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] savepoints in 8.3.7 or whatever...
On Wed, Jul 15, 2009 at 12:05 PM, John R Piercepie...@hogranch.com wrote: we have an app thats doing massive amounts of inserts, batched in transactions, multiple concurrent connections (tuned for optimal throughput, usually around 1 thread per cpu core plus a couple more). occasionally a transaction gets duplicated, and that causes a constraint violation which causes the whole transaction to abort unless we wrap each insert in a savepoint. my developers are asking me if there are limits as to how many savepoints can be active, etc. they have run into various such limits in oracle. To add to what Alvaro said, savepoints are't free. If you savepoint every single insert, you'll wind up begin much much slower than if you can insert a few dozen to a few hundred at a time. So, you might be better off bunching up a few hundred inserts at a time, and when one of the batches of 100 fail then fall back to breaking it into pieces and pushing them in until you find the one that doesn't work and spit it out into a log. It's more work on the app end, but by putting a hundred or so inserts together you get much better performance than savepointing each one. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Areca 1680 and RHEL/Centos 5.3 issue
This is more a request for other folks and their experience. We have been running Centos 5.2 in production for nearly a year with little or no issues. The kernel it came with was 2.6.18-92.el5. About two months ago I updated one of our to servers to 5.3, and the new kernel is 2.6.18-128.1.14.el5. I have had two lockups in the last month and a half where the error message was Ext3-fs error (device SDA1) ext3_get_inode_bc: unable to read inode block inode=3909144 block=3932162 SD 0:0:0:0: rejecting I/O to offline device. I was wondering if anyone else has had any experience like this lately. I filed a bug report with RH, https://bugzilla.redhat.com/show_bug.cgi?id=511911 so if you have had this situation please check in on that bug and post your experiences as well as here. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] best practice transitioning from one datatype to another
CG cgg...@yahoo.com writes: While transitioning from 8.1 to 8.4, I need to transition to the internal UUID type in place of the contrib/uniqueidentifier module. I've built the database around uniqueidentifier, so nearly every table has one column of that data type. It's going to be tedious to ALTER TABLE foo ALTER COLUMN bar SET DATA TYPE uuid; ...repeat 600 times... I'll also have to drop and reload the views and the rules on tables. It'll be tedious even if the tables have no data in them. Can anyone recommend a better/faster way to make the transition? Couldn't you rename the type to uuid in the 8.1 database before you dump? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] psql \du
Hi, I recognized in psql using the internal help (\?) that the *+* sign is missing for the shortcut \du: # \du List of roles Role name | Attributes | Member of --+--+--- # \du+ List of roles Role name | Attributes | Member of | Description --+--+---+- Where shall I place this info? Is this also a bug? Cheers Andy -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] initdb --encoding=LATIN1 fails on Windows
The same command worked fine on PG 8.2.4. Now, using 8.3.7, we are forced into WIN1252. Thanks Danny -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] best practice transitioning from one datatype to another
On Jul 16, 8:05 am, t...@sss.pgh.pa.us (Tom Lane) wrote: CG cgg...@yahoo.com writes: While transitioning from 8.1 to 8.4, I need to transition to the internal UUID type in place of the contrib/uniqueidentifier module. I've built the database around uniqueidentifier, so nearly every table has one column of that data type. It's going to be tedious to ALTER TABLE foo ALTER COLUMN bar SET DATA TYPE uuid; ...repeat 600 times... I'll also have to drop and reload the views and the rules on tables. It'll be tedious even if the tables have no data in them. Can anyone recommend a better/faster way to make the transition? Couldn't you rename the type to uuid in the 8.1 database before you dump? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-gene...@postgresql.org) To make changes to your subscription:http://www.postgresql.org/mailpref/pgsql-general Just an idea - don't know if it works, first try on a test server: 1. Dump the complete database into text format (pg_dump --format=t) 2. Do a search and replace from uniqueidentifier to uuid 3. Reimport Best Regards, Arndt Lehmann -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Concurrency issue under very heay loads
Hi, We use a typical counter within a transaction to generate order sequence number and update the next sequence number. This is a simple next counter - nothing fancy about it. When multiple clients are concurrently accessing this table and updating it, under extermely heavy loads in the system (stress testing), we find that the same order number is being generated for multiple clients. Could this be a bug? Is there a workaround? Please let me know. Thanks Raji
Re: [GENERAL] [PERFORM] Concurrency issue under very heay loads
Hi, Are you using automatic sequence increment in table? - Original Message - From: Raji Sridar (raji) To: pgsql-general@postgresql.org ; pgsql-performa...@postgresql.org Sent: Thursday, July 16, 2009 10:29 AM Subject: [PERFORM] Concurrency issue under very heay loads Hi, We use a typical counter within a transaction to generate order sequence number and update the next sequence number. This is a simple next counter - nothing fancy about it. When multiple clients are concurrently accessing this table and updating it, under extermely heavy loads in the system (stress testing), we find that the same order number is being generated for multiple clients. Could this be a bug? Is there a workaround? Please let me know. Thanks Raji
Re: [GENERAL] Concurrency issue under very heay loads
2009/7/16 Raji Sridar (raji) r...@cisco.com: Hi, We use a typical counter within a transaction to generate order sequence number and update the next sequence number. This is a simple next counter - nothing fancy about it. When multiple clients are concurrently accessing this table and updating it, under extermely heavy loads in the system (stress testing), we find that the same order number is being generated for multiple clients. Could this be a bug? Is there a workaround? Please let me know. Thanks Raji You'll not have this problem if you use serial type. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Concurrency issue under very heay loads
Raji Sridar (raji) wrote: Hi, We use a typical counter within a transaction to generate order sequence number and update the next sequence number. This is a simple next counter - nothing fancy about it. When multiple clients are concurrently accessing this table and updating it, under extermely heavy loads in the system (stress testing), we find that the same order number is being generated for multiple clients. Could this be a bug? Is there a workaround? Please let me know. without seeing your code, its hard to say where this bug is, in your counter implementation, or in postgres. you also don't say what version of postgres you're using, or even what OS you're running under... sounds like you should be using a SERIAL (which is implemented as an INTEGER or BIGINT field with an associated SEQUENCE), as these DO work just fine under heavy concurrency without any gotchas. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] How to DB export XML File in PostgreSQL?
Hello. Thank you for your interesting. Any person know that how to db export XML file in PostgreSQL? I use Ver. 8.4 and Operating System Linux. Have a nice day.
Re: [GENERAL] How to DB export XML File in PostgreSQL?
Steve Choi, 16.07.2009 07:43: Hello. Thank you for your interesting. Any person know that how to db export XML file in PostgreSQL? I use Ver. 8.4 and Operating System Linux. Have a nice day. I'm not sure I understand your question. Do you want to export the data of your database into a (single?) XML file, or do you want to export XML files that stored in the database? Thomas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
