Re: [GENERAL] Running multiple instances off one set of binaries

[Tom Lane]

Sergey Konoplev  writes:
> On Sat, Feb 9, 2013 at 7:39 PM, Karl Denninger  wrote:
>> Am I correct in that I can do this by simply initdb-ing the second instance
>> with a different data directory structure, and when starting it do so with a
>> different data directory structure?

> You are correct.

You also need a separate port number for the second instance (obviously,
only one of them can have 5432).  Another point is that you may have to
twiddle the kernel's shmem settings to make enough shared memory
available for both installations.  But people do this all the time.

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

Re: [GENERAL] Tcl & PG on Win 7 64 bit - is it working for anyone?

[Adrian Klaver]

On 02/09/2013 09:39 PM, Carlo Stonebanks wrote:

I am actually in the same folder as the libpgtcl.dll, and that particular
failure would raise a different error in any case:

'couldn't load library "libpgtc": this library or a dependent library could
not be found in library path'


I did find this thread:

http://pgtclng.sourceforge.net/thread1.html

I do not see a definitive answer in it, but there are some 
troubleshooting tips.









--
Adrian Klaver
adrian.kla...@gmail.com


--
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] Swapping volumes under tablespaces: supported?

[Kenneth Tilton]

OK. What if we do not need to access the static data on the test volume? It
is a rare application that goes there, and for those we can bring over both
volumes/tablespaces.

Thx, ken

On Fri, Feb 8, 2013 at 10:09 PM, Gavan Schneider  wrote:

> On Friday, February 8, 2013 at 10:58, Tom Lane wrote:
>
>  If it breaks you get to keep both pieces.
>>
>>  Tom is an optimist. My (unscheduled) attempt at this resulted in a lot
> more than two pieces all of which appeared broken in their own right.
>
> If you want to (re)start a conversation about making mount/unmount/move
> tablespace a reality be my guest, but, be warned, there seem to be some
> very fundamental barriers.
>
> Regards
> Gavan Schneider
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/**mailpref/pgsql-general
>



-- 
Kenneth Tilton

*Director of Software Development*

*MCNA Dental Plans*
200 West Cypress Creek Road
Suite 500
Fort Lauderdale, FL 33309

954-730-7131 X181 (Office)
954-628-3347 (Fax)
1-800-494-6262 X181 (Toll Free)

ktil...@mcna.net  (Email)

www.mcna.net (Website)
CONFIDENTIALITY NOTICE: This electronic mail may contain information that
is privileged, confidential, and/or otherwise protected from disclosure to
anyone other than its intended recipient(s). Any dissemination or use of
this electronic mail or its contents by persons other than the intended
recipient(s) is strictly prohibited. If you have received this
communication in error, please notify the sender immediately by reply
e-mail so that we may correct our internal records. Please then delete the
original message. Thank you.

[GENERAL] to_number, to_char inconsistency.

[Jeremy Lowery]

I load and dump text files with currency values in it. The decimal in these
input and output formats in implied. The V format character works great for
outputing numeric data:

# select to_char(123.45, '999V99');
 to_char
-
  12345
(1 row)


However, when importing data, the V doesn't do the same thing:

# select to_number('12345', '999V99');
ERROR:  numeric field overflow
DETAIL:  A field with precision 3, scale 0 must round to an absolute value
less than 10^3.


So I have to do this:
# select to_number('12345', '9')/100;

Is there an easier way to insert this into a NUMERIC(5, 2) field?

Re: [GENERAL] to_number, to_char inconsistency.

[Szymon Guz]

On 10 February 2013 20:50, Jeremy Lowery  wrote:

> I load and dump text files with currency values in it. The decimal in
> these input and output formats in implied. The V format character works
> great for outputing numeric data:
>
> # select to_char(123.45, '999V99');
>  to_char
> -
>   12345
> (1 row)
>
>
> However, when importing data, the V doesn't do the same thing:
>
> # select to_number('12345', '999V99');
> ERROR:  numeric field overflow
> DETAIL:  A field with precision 3, scale 0 must round to an absolute value
> less than 10^3.
>
>
> So I have to do this:
> # select to_number('12345', '9')/100;
>
> Is there an easier way to insert this into a NUMERIC(5, 2) field?
>

Hi Jeremy,
I've always been doing such conversions in quite a different way:

SELECT 123.45::TEXT;

The conversion from text to numeric I'd do like:

SELECT '12345'::NUMERIC(10,2)/100;

regards
Szymon

Re: [GENERAL] to_number, to_char inconsistency.

[Tom Lane]

Jeremy Lowery  writes:
> I load and dump text files with currency values in it. The decimal in these
> input and output formats in implied. The V format character works great for
> outputing numeric data:

> # select to_char(123.45, '999V99');
>  to_char
> -
>   12345
> (1 row)

> However, when importing data, the V doesn't do the same thing:

> # select to_number('12345', '999V99');

A look at the source code shows that to_number doesn't do anything at
all with the V format code, so this isn't terribly surprising.  It
wouldn't be very hard to make it do the right thing, probably, but
nobody's had that particular itch yet.  Feel free to scratch it and
send a patch ...

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

Re: [GENERAL] var/log/postgresql deletion mystery Ubuntu 12.10

[Andrew Taylor]

Here's what I did to fix this in Ubuntu 12.10.

Now I cannot explain (a) why this problem came into being or (b) what the
science is behind my fix. This was my first dive into Linux logs and there
being seemingly an array of ways logging can be handled now, and was
handled historically, with some variation across linux distributions. It's
a little bewildering.  All I can say it this works, and if someone can
offer me insight into (postgres) logs in Ubuntu it would be appreciated. So
here we go:

Syslog seems to be one of the key processes available for logging. You can
use this to determine what gets logged by given processes.

In /etc/rsyslog.d/50-default.conf
Add this line:
local0.* -/var/log/postgresql/

And edit this line from this:
daemon.*;mail.*;\
news.err;\
*.=debug;*.=info;\
*.=notice;*.=warn |/dev/xconsole

To be this:
daemon.*;mail.*;\
news.err;\
*.=debug;*.=info;\
*.=notice;*.=warn |/dev/xconsole;\
local0.none

The above is based on information at this link:
https://bowerstudios.com/node/890

Now (as if by magic) The /var/log/postgres directory is deleted and
recreated on shutdown/startup, AND a postgresql-9.1-main.log file is
created on reboot.


On Fri, Feb 8, 2013 at 11:43 PM, Tom Lane  wrote:

> Andrew Taylor  writes:
> > I have to create this directory each time I want to start the server.
> > Something is deleting it when I close down or start up my laptop.
>
> > Any suggestions as to what could be doing this, or how I could find out?
> I
> > presently have version 9.1 installed.
>
> > All I can add is "it used to work!". Since then I have upgraded to ubuntu
> > 12.10 from 12.04 and installed mongodb amongst other things.
>
> Over in Fedora-land they've recently switched to a scheme whereby most
> "temporary" directories are deleted at reboot, so that packages need to
> arrange for their recreation.  Is it possible something similar is going
> on in your newer Ubuntu version?  It would seem to me to be the height
> of stupidity to flush log files this way, but it's hard to think of
> another reason for the directory to disappear.  If all other stuff under
> /var/log is deleted or reset at reboot, then this could be the explanation.
>
> regards, tom lane
>

[GENERAL] Can you create aliases in the psql shell?

[Modulok]

List,

Is there a way to create command aliases in the psql shell? I can never
remember all the \d* commands and have to look them up every time. If I could
create things like \list_databases, \list_tables, \list_roles, etc, it would be
much easier for me to remember.

Is there a way to create such aliases? I'm using 9.2.3 if that matters. I
didn't see anything in the man page. If not is there another command line
client interface?

Cheers!
-Modulok-


-- 
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] Can you create aliases in the psql shell?

[Kevin Grittner]

Modulok  wrote:

> Is there a way to create command aliases in the psql shell? I can never

> remember all the \d* commands and have to look them up every time. If I 
> could
> create things like \list_databases, \list_tables, \list_roles, etc, 
> it would be
> much easier for me to remember.
> 
> Is there a way to create such aliases? I'm using 9.2.3 if that matters. I
> didn't see anything in the man page. If not is there another command line
> client interface?

\set list_databases '\\l'

Then you can type :list_databases to get the same effect as \l

-Kevin



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Upsert Functionality using CTEs

[Tim Uckun]

I am using a query like this to try and normalize a table.

WITH nd as (select * from sales order by id limit 100),

people_update as (update people p set first_name = nd.first_name from
nd where p.email = nd.email returning nd.id),

insert into  people (first_name, email, created_at, updated_at)
  select first_name, email , now(), now()
  from nd
  left join people_update using(id) where
people_update.id is null),

This works pretty good except for when the top 100 records have
duplicated email address (two sales for the same email address).

I am wondering what the best strategy is for dealing with this
scenario.  Doing the records one at a time would work but obviously it
would be much slower.  There are no other columns I can rely on to
make the record more unique either.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] REINDEX deadlock - Postgresql -9.1

[Anoop K]

We are hitting a situation where REINDEX is resulting in postgresql to go
to dead lock state* for ever*. On debugging the issue we found that
3 connections are going in to some dead lock state.

   1. *idle in transaction   *
   2. *REINDEX waiting   *
   3. *SELECT waiting*

All these connections are made in the same minute. Once in deadlock state
we are not able to make new connections to db.(So not able to view pg_locks
also). New connections appears as '*startup waiting*' in ps output.
Initially we suspected <*idle in transaction> *is the result of not closing
a connection. But it seems it got stuck after creating a connection and is
not able to proceed.

Any clues ..

Thanks
Anoop

Re: [GENERAL] REINDEX deadlock - Postgresql -9.1

[John R Pierce]

On 2/6/2013 1:28 AM, Anoop K wrote:

3 connections are going in to some dead lock state.

 1. *idle in transaction *
 2. *REINDEX waiting *
 3. *SELECT waiting *



you need to track down what resources are being locked by those 
processes, by joining pg_stat_activity against pg_locks and (been 
awhile, I forget the magic join query that gives you useful info here)


IDLE in Transaction means that connection did a BEGIN;  but isn't 
executing any commands at all at present and is just sitting there. This 
should never happen, and is generally a sign of buggy application 
software, or poorly designed ORM or something.



--
john r pierce  37N 122W
somewhere on the middle of the left coast

Re: [GENERAL] REINDEX deadlock - Postgresql -9.1

[Sergey Konoplev]

On Wed, Feb 6, 2013 at 1:28 AM, Anoop K  wrote:
> We are hitting a situation where REINDEX is resulting in postgresql to go to
> dead lock state for ever. On debugging the issue we found that
> 3 connections are going in to some dead lock state.
>
> idle in transaction
> REINDEX waiting
> SELECT waiting
>
> All these connections are made in the same minute. Once in deadlock state we
> are not able to make new connections to db.(So not able to view pg_locks
> also). New connections appears as 'startup waiting' in ps output. Initially
> we suspected  is the result of not closing a
> connection. But it seems it got stuck after creating a connection and is not
> able to proceed.

The 'idle in transaction' means that someone started a transaction
(BEGIN) and did not finished it (COMMIT/ROLLBACK) in the first
connections. The 'startup waiting' message means that something got an
exclusive lock on some system catalogs.

You should not allow persistent or long running 'idle in transaction's
that could affect tables that are actively used by other connections
mostly if these tables are system ones. You need to find out what
caused this 'idle in transaction', in the other words why the
transaction was not finished, to solve the problem.

>
> Any clues ..
>
> Thanks
> Anoop



--
Sergey Konoplev
Database and Software Architect
http://www.linkedin.com/in/grayhemp

Phones:
USA +1 415 867 9984
Russia, Moscow +7 901 903 0499
Russia, Krasnodar +7 988 888 1979

Skype: gray-hemp
Jabber: gray...@gmail.com


-- 
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] REINDEX deadlock - Postgresql -9.1

[Anoop K]

We analyzed the application side. It doesn't seem to be create a
transaction and keep it open. StackTraces indicate that it is BLOCKED in
JDBC openConnection.

Any JDBC driver issue or other scenarios which can result in <*idle in
transaction*> ?

Anoop

On Mon, Feb 11, 2013 at 11:16 AM, Sergey Konoplev  wrote:

> On Wed, Feb 6, 2013 at 1:28 AM, Anoop K  wrote:
> > We are hitting a situation where REINDEX is resulting in postgresql to
> go to
> > dead lock state for ever. On debugging the issue we found that
> > 3 connections are going in to some dead lock state.
> >
> > idle in transaction
> > REINDEX waiting
> > SELECT waiting
> >
> > All these connections are made in the same minute. Once in deadlock
> state we
> > are not able to make new connections to db.(So not able to view pg_locks
> > also). New connections appears as 'startup waiting' in ps output.
> Initially
> > we suspected  is the result of not closing a
> > connection. But it seems it got stuck after creating a connection and is
> not
> > able to proceed.
>
> The 'idle in transaction' means that someone started a transaction
> (BEGIN) and did not finished it (COMMIT/ROLLBACK) in the first
> connections. The 'startup waiting' message means that something got an
> exclusive lock on some system catalogs.
>
> You should not allow persistent or long running 'idle in transaction's
> that could affect tables that are actively used by other connections
> mostly if these tables are system ones. You need to find out what
> caused this 'idle in transaction', in the other words why the
> transaction was not finished, to solve the problem.
>
> >
> > Any clues ..
> >
> > Thanks
> > Anoop
>
>
>
> --
> Sergey Konoplev
> Database and Software Architect
> http://www.linkedin.com/in/grayhemp
>
> Phones:
> USA +1 415 867 9984
> Russia, Moscow +7 901 903 0499
> Russia, Krasnodar +7 988 888 1979
>
> Skype: gray-hemp
> Jabber: gray...@gmail.com
>

Re: [GENERAL] Upsert Functionality using CTEs

[Sergey Konoplev]

On Sun, Feb 10, 2013 at 5:23 PM, Tim Uckun  wrote:
> This works pretty good except for when the top 100 records have
> duplicated email address (two sales for the same email address).

How is it assumed to work when the migrating email already exists in people?

>
> I am wondering what the best strategy is for dealing with this
> scenario.  Doing the records one at a time would work but obviously it
> would be much slower.  There are no other columns I can rely on to
> make the record more unique either.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general



-- 
Sergey Konoplev
Database and Software Architect
http://www.linkedin.com/in/grayhemp

Phones:
USA +1 415 867 9984
Russia, Moscow +7 901 903 0499
Russia, Krasnodar +7 988 888 1979

Skype: gray-hemp
Jabber: gray...@gmail.com


-- 
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] REINDEX deadlock - Postgresql -9.1

[John R Pierce]

On 2/10/2013 9:55 PM, Anoop K wrote:
We analyzed the application side. It doesn't seem to be create a 
transaction and keep it open. StackTraces indicate that it is BLOCKED 
in JDBC openConnection.


Any JDBC driver issue or other scenarios which can result in <*idle in 
transaction*> ?


JDBC has a wretched habit of autostarting transactions on any query if 
the connection is not in autocommit mode.  if you don't want to use 
autocommit mode, then you need to issue Commit() calls after each batch 
of queries, even if the queries are read only, to release any implied locks.




--
john r pierce  37N 122W
somewhere on the middle of the left coast

Re: [GENERAL] REINDEX deadlock - Postgresql -9.1

[Anoop K]

Yes, we do that.

On Mon, Feb 11, 2013 at 11:53 AM, John R Pierce  wrote:

>  On 2/10/2013 9:55 PM, Anoop K wrote:
>
> We analyzed the application side. It doesn't seem to be create a
> transaction and keep it open. StackTraces indicate that it is BLOCKED in
> JDBC openConnection.
>
>  Any JDBC driver issue or other scenarios which can result in <*idle in
> transaction*> ?
>
>
> JDBC has a wretched habit of autostarting transactions on any query if the
> connection is not in autocommit mode.  if you don't want to use autocommit
> mode, then you need to issue Commit() calls after each batch of queries,
> even if the queries are read only, to release any implied locks.
>
>
>
>
> --
> john r pierce  37N 122W
> somewhere on the middle of the left coast
>
>

Re: [GENERAL] REINDEX deadlock - Postgresql -9.1

[Sergey Konoplev]

On Sun, Feb 10, 2013 at 9:55 PM, Anoop K  wrote:
> We analyzed the application side. It doesn't seem to be create a transaction
> and keep it open. StackTraces indicate that it is BLOCKED in JDBC
> openConnection.
>
> Any JDBC driver issue or other scenarios which can result in  transaction> ?

There are no other scenarios for 'idle in transaction'. Unfortunately
I am not a JDBC specialist but googling 'postgresql jdbc idle in
transaction' shows a lot of threads where people discuss such things.
I am pretty sure there is an answer among them.

>
> Anoop
>
>
> On Mon, Feb 11, 2013 at 11:16 AM, Sergey Konoplev  wrote:
>>
>> On Wed, Feb 6, 2013 at 1:28 AM, Anoop K  wrote:
>> > We are hitting a situation where REINDEX is resulting in postgresql to
>> > go to
>> > dead lock state for ever. On debugging the issue we found that
>> > 3 connections are going in to some dead lock state.
>> >
>> > idle in transaction
>> > REINDEX waiting
>> > SELECT waiting
>> >
>> > All these connections are made in the same minute. Once in deadlock
>> > state we
>> > are not able to make new connections to db.(So not able to view pg_locks
>> > also). New connections appears as 'startup waiting' in ps output.
>> > Initially
>> > we suspected  is the result of not closing a
>> > connection. But it seems it got stuck after creating a connection and is
>> > not
>> > able to proceed.
>>
>> The 'idle in transaction' means that someone started a transaction
>> (BEGIN) and did not finished it (COMMIT/ROLLBACK) in the first
>> connections. The 'startup waiting' message means that something got an
>> exclusive lock on some system catalogs.
>>
>> You should not allow persistent or long running 'idle in transaction's
>> that could affect tables that are actively used by other connections
>> mostly if these tables are system ones. You need to find out what
>> caused this 'idle in transaction', in the other words why the
>> transaction was not finished, to solve the problem.
>>
>> >
>> > Any clues ..
>> >
>> > Thanks
>> > Anoop
>>
>>
>>
>> --
>> Sergey Konoplev
>> Database and Software Architect
>> http://www.linkedin.com/in/grayhemp
>>
>> Phones:
>> USA +1 415 867 9984
>> Russia, Moscow +7 901 903 0499
>> Russia, Krasnodar +7 988 888 1979
>>
>> Skype: gray-hemp
>> Jabber: gray...@gmail.com
>
>



-- 
Sergey Konoplev
Database and Software Architect
http://www.linkedin.com/in/grayhemp

Phones:
USA +1 415 867 9984
Russia, Moscow +7 901 903 0499
Russia, Krasnodar +7 988 888 1979

Skype: gray-hemp
Jabber: gray...@gmail.com


-- 
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] REINDEX deadlock - Postgresql -9.1

[John R Pierce]

On 2/10/2013 10:25 PM, Anoop K wrote:

Yes, we do that.



well, you need to figure out which connection isn't doing that, as one 
of them is leaving a long running transaction pending.


as I said, join pg_stat_activity.pid with pg_locks and whatever to find 
out what tables its locking on.


try these
http://wiki.postgresql.org/wiki/Lock_Monitoring



--
john r pierce  37N 122W
somewhere on the middle of the left coast



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Order of granting with many waiting on one lock

[Chris Angelico]

I've poked around a bit with my good friend Google Search and come up
blank, and I'm fairly sure this is something that shouldn't be relied
upon, but it's a point of curiosity.

Suppose I have twenty processes that all request the same lock. (I'm
working with pg_advisory_xact_lock, but any exclusive lock should do.)
One of them will obtain it, the others will block. The winner then
holds the lock for a second or so, then commits (releasing the lock),
then goes back and requests it again. Rinse and repeat. Yes, I know
this sounds ridiculous, but it's a simplified version of the
worst-case scenario in one of our systems.

The question is: How is it decided which process will get the lock
when the previous one commits? Is there any sort of guarantee that all
the processes will eventually get a turn, or could two processes
handball the lock to each other and play keepings-off against the
other eighteen?

Chris Angelico


-- 
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] Order of granting with many waiting on one lock

[Pavan Deolasee]

On Mon, Feb 11, 2013 at 12:26 PM, Chris Angelico  wrote:
> Is there any sort of guarantee that all
> the processes will eventually get a turn, or could two processes
> handball the lock to each other and play keepings-off against the
> other eighteen?
>

That should not happen. There are instances when a lock requester will
be promoted ahead of others to avoid deadlock, but in the scenario you
described, no single process will starve forever. See following
comment in ProcSleep() function under src/backend/storage/lmgr/proc.c
which is self-explanatory.

/*
 * Determine where to add myself in the wait queue.
 *
 * Normally I should go at the end of the queue.  However, if I already
 * hold locks that conflict with the request of any previous waiter, put
 * myself in the queue just in front of the first such waiter. This is not
 * a necessary step, since deadlock detection would move me to before that
 * waiter anyway; but it's relatively cheap to detect such a conflict
 * immediately, and avoid delaying till deadlock timeout.
 *
 * Special case: if I find I should go in front of some waiter, check to
 * see if I conflict with already-held locks or the requests before that
 * waiter.  If not, then just grant myself the requested lock immediately.
 * This is the same as the test for immediate grant in LockAcquire, except
 * we are only considering the part of the wait queue before my insertion
 * point.
 */

Thanks,
Pavan

-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee


-- 
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] Order of granting with many waiting on one lock

[Chris Angelico]

On Mon, Feb 11, 2013 at 6:12 PM, Pavan Deolasee
 wrote:
>  * Determine where to add myself in the wait queue.
>  *
>  * Normally I should go at the end of the queue.

Ah! That's perfect. So they'll actually go into perfect strict
round-robin, assuming that there are no other locks coming into play
(which I expect will be the case; I've been careful to avoid
deadlocks).

Thanks Pavan, fast response and perfect information!

ChrisA


-- 
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] Upsert Functionality using CTEs

[Alban Hertroys]

On Feb 11, 2013, at 2:23, Tim Uckun  wrote:

> This works pretty good except for when the top 100 records have
> duplicated email address (two sales for the same email address).
> 
> I am wondering what the best strategy is for dealing with this
> scenario.  Doing the records one at a time would work but obviously it
> would be much slower.  There are no other columns I can rely on to
> make the record more unique either.

The best strategy is fixing your data-model so that you have a unique key. As 
you found out already, e-mail addresses aren't very suitable as unique keys for 
people. For this particular case I'd suggest adding a surrogate key.

Alternatively, you might try using (first_name, email) as your key. You'll 
probably still get some duplicates, but they should be less and perhaps few 
enough for your case.


Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general