Re: [GENERAL] Startup process thrashing

[Greg Smith]

On Thu, 11 Dec 2008, Phillip Berry wrote:

I'm not running PITR and checkpoint_segments is set to 100 as this is 
home to a very write intensive app.


That's weird then.  It shouldn't ever keep around more than 201 WAL 
segments.  I've heard one report of a similarly mysterious excess of them, 
from Robert Treat, but that was probably caused by a hardware failure.


1. Will copying the pg_xlog dir onto a larger partition cause any 
problems?


Ah, I didn't realize the disk it's on was still 100% full from what you 
said.  You're not going to get anywhere until that's sorted out.  You 
absolutely can move them all to another disk, you just can't delete them 
altogether or split them across logical disks.  The usual technique is 
something like this:


cd $PGDATA
mv pg_xlog $BIGGER
ln -s $BIGGER/pg_xlog

And then fire the server up in single-user mode to issue the VACUUM it's 
begging for.  Once it's back to running in regular mode again, issue a 
"CHECKPOINT" command, and it should erase most of those WAL files.  Then 
you could stop the server and reverse the above:


cd $PGDATA
unlink pg_xlog
mv $BIGGER/pg_xlog .

While filling that disk and grinding to a halt is bad, it's not 
necessarily any worse then the alternative if you didn't have it on a 
dedicated filesystem--that this out of control xlog creation might create 
an even greater backlog of segments.


2. Is there any reason that vacuuming would create so many WAL files? 
I've looked around and can't find any explaination, though it's a 
problem that seems to have happened before.


Nothing should make that many WAL files, normally the only way you can get 
into that position is if you're running PITR recovery but not archiving 
the segments--so they just keep piling up but the server can't recycle 
them.  What's supposed to happen is that every time there is a checkpoint, 
it deletes anything beyond 2*checkpoint_segments+1 worth of segments, 
that's where the 201 figure I mentioned comes from.


3. I installed pgbouncer yesterday for connection pooling, does the fact 
that it holds connections open have any bearing on how rapidly the 
transaction IDs are used up? As in are transaction IDs in anyway related 
to connections? It's a pretty interesting coincidence.


I'm not really familiar with pgbouncer to comment on the specifics of what 
it does.  In general, keeping transactions open longer will impact the 
pg_clog section of the database, but that shouldn't cause the WAL to grow 
out of control.  Once you get this back into production, you certainly 
should carefully monitor how much disk space is being taken up on the WAL 
disk moving forward.  If the count of them there gets back over 201 again, 
that's an indication there's something that shouldn't be happening going 
on.  That's the sort of thing you can get more information about


This isn't a real popular time of day for this list, some get some more 
ideas might show up once our many European members start posting in 
volume.  As a general aside, if you ever find yourself in this position 
again, where you've got an urgent database problem, something you might do 
in parallel with posting here is trying the IRC channel: 
http://wiki.postgresql.org/wiki/IRC2RWNames


--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD

--
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] tcp_keepalives_idle setting

[Maximilian Tyrtania]

Hi,

Am 11.12.2008 2:23 Uhr schrieb "Fujii Masao" unter <[EMAIL PROTECTED]>:

>> I'm running pg 8.3.3 on Mac OS 10.4.11 and I'm seeing the same behaviour as
>> Henry.
>> I'm trying to find out if Mac OS belongs to those platforms that doesn't
>> allow adjustment of the TCP keepalive parameters from userspace, and if so,
>> how i can change the systems settings as root.
> 
> Do you use TCP/IP socket when you execute SHOW ALL? Those parameters
> are ignored via Unix-domain socket.

Yes, i am using a tcp/ip socket. Sorry, should have mentioned that.

Thanks,

Maximilian Tyrtania



-- 
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] Data Replication

[Joshua D. Drake]

On Wed, 2008-12-10 at 21:39 -0700, Scott Marlowe wrote:
> On Wed, Dec 10, 2008 at 8:43 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> > On Wed, 2008-12-10 at 20:41 -0700, Scott Marlowe wrote:
> >> On Wed, Dec 10, 2008 at 7:40 PM, Tim Uckun <[EMAIL PROTECTED]> wrote:
> >
> >> Log shipping doesn't really lends itself to switching back and forth
> >> between masters and slaves.
> >
> > Really? It seems to me that you can make a base backup just as fast as
> > you can sync from slony (or replicator or whatever).
> 
> sorry if my post wasn't clear. slony's not really any better.  I don't
> think that there's any replication for pgsql that's easy to do that
> in.  Is there?

No probably not. I mean they are all pretty easy (especially log
shipping) but it is definitely true they are slow, depending on the size
of the database.

Joshua D. Drake


> 
-- 
PostgreSQL
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


-- 
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] Multi-table CHECK constraint

[Adam Rich]

> On Wed, Dec 10, 2008 at 05:58:08PM -0600, Jason Long wrote:
> > I need to add some complex constraints at the DB.
> >
> > For example.
> >
> > Do not allow a line item of inventory to be changed if it does not
> > result in the same number of joints originally shipped.
> >
> > These will involve several tables.
> >
> > What is the best approach for this?
> 


> You might want to talk to people who have done bookkeeping
> applications for PostgreSQL, or possibly even buy one of the
> proprietary PostgreSQL-based systems for it, as this stuff can be
> fiendishly tricky to get right.
> 

As a developer of just such a bookkeeping application, here's (IMHO) 
the best way to handle this:  Wrap the dependent operations into one
stored procedure, grant rights to that procedure and not to the
underlying tables.  If an operation (such as shipping product) 
requires multiple database queries and updates, wrapped in a 
transaction, don't place your trust in every user and/or application
to do that properly.

In your example, don't give the user or application UPDATE permission 
to the raw inventory or product tables, that's just asking for trouble.  
Instead, create a ship_product() procedure that takes all the steps
required.  (You'll also need others, adding inventory for example)

There are many, many benefits to reap once you've made the commitment
to doing this.  More re-usable code, a stable API, atomic operations,
faster transactions, less traffic over the wire, etc etc.

I would still add critical constraints and triggers as a failsafe so
an admin with rights can't accidentally introduce bad data to the
system, but there's just no substitute for proper encapsulation.
Plus, sometimes it's expensive or impossible to verify after the fact 
(in a constraint trigger) whether the transaction was valid, but 
just wrapping the stuff in a stored procedure is much simpler.










-- 
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] Startup process thrashing

[Phillip Berry]

Hi Greg,

I appreciate the reply.  Fortunately within the last 10 minutes it has finished 
the recovery...and 
then promptly shut itself down again.

The exact error is in fact:

FATAL:  database is not accepting commands to avoid wraparound data loss in 
database "aim"
2008-12-10 06:00:02 CST [21392]: [4-1] HINT:  Stop the postmaster and use a 
standalone backend to 
vacuum database "aim".

So I'm back to where I was last night which is a slight relief.  The difference 
being that the 
pg_xlog is still full and when I attempt to start Postgres in single user mode 
it fails becasue of 
that.

I'm not running PITR and checkpoint_segments is set to 100 as this is home to a 
very write intensive 
app.  The db has been running for over a year and in that time has been 
vacuumed many times without 
issue.

So now I guess I have two questions:

1. Will copying the pg_xlog dir onto a larger partition cause any problems?
2. Is there any reason that vacuuming would create so many WAL files? I've 
looked around and can't 
find any explaination, though it's a problem that seems to have happened before.
Actually make that three questions...
3. I installed pgbouncer yesterday for connection pooling, does the fact that 
it holds connections 
open have any bearing on how rapidly the transaction IDs are used up? As in are 
transaction IDs in 
anyway related to connections? It's a pretty interesting coincidence.

Cheers
Phil










On Thursday 11 December 2008 15:20:21 you wrote:
> On Thu, 11 Dec 2008, Phillip Berry wrote:
> > I've got a bit of a problem.  It started last night when postgres
> > (8.1.9) went down citing the need for a vacuum full to be done due to
> > the transaction log needing to wraparound.
>
> Not exactly.  What it said was "To avoid a database shutdown, execute a
> full-database VACUUM".  In that context, "full" means you vacuum
> everything in the database, but only regular VACUUM is needed.  VACUUM
> FULL, as you learned the hard way, is a more intensive operation, and it's
> not needed to resolve the problem you started with.  It's a somewhat
> unfortunately worded HINT.
>
> > During the vacuum of the larger of the databases a few hours in it
> > failed, it's filled up the 18GB pg_xlog partition with over 1000 wal
> > files.  Due to running out of space the vacuum failed.
>
> Ouch.  Are you running PITR recovery by setting archive_command?  Did you
> set checkpoint_segments to some very high value?  1000 WAL files is not
> normal, curious how you ended up with so many of them.
>
> > When I came in this morning I attempted to start postgres using the
> > normal init script, and now it's stuck.  The startup process is thrashing
> > the disks and working hard, pg_controldata says it's in recovery, but
> > it's been going for over two hours.
>
> It takes a long time to sort through 1000 WAL files and figure out if the
> database is consistent for every transactions mentioned there.  If your
> VACUUM FULL ran for several hours and kicked out 1000 of them, it would be
> reasonable to expect the cleanup to also take many hours.
>
> > My question is where I should go from here?  Should i kill the startup
> > script, clear out the excess wal files, start the standalone server and
> > try vacuum again?
>
> Deleting the WAL files like that will leave your database completely
> trashed.  The utility that's provided to do the job you're considering is
> pg_resetxlog:
>
> http://www.postgresql.org/docs/8.1/static/app-pgresetxlog.html
>
> Which is slightly safer, but note the dire warnings there.  You are very
> likely to get some sort of data corruption if you do that, and you won't
> know where it is.  You'll be facing a dump and restore to sort that out,
> and if you think the server startup is taking a while on a 156GB database
> you're really not going to be happy with how long a restore takes.
>
> The safest thing you can do here is just wait for the server to finish
> recovery so it starts up.  Watch the system activity with something like
> vmstat.  If the server process is busy using the CPU and it's doing stuff
> with the disks, if you have evidence it's making progress, you'll be hard
> pressed to execute any manual recovery that's any safer or more efficient
> than that is.
>
> Someone else may be able to point you toward better estimating how far
> it's got left to go, I haven't ever been stuck in your position for long
> enough before to figure that out myself.  Good luck.
>
> --
> * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD



-- 
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] Data Replication

[Scott Marlowe]

On Wed, Dec 10, 2008 at 8:43 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-12-10 at 20:41 -0700, Scott Marlowe wrote:
>> On Wed, Dec 10, 2008 at 7:40 PM, Tim Uckun <[EMAIL PROTECTED]> wrote:
>
>> Log shipping doesn't really lends itself to switching back and forth
>> between masters and slaves.
>
> Really? It seems to me that you can make a base backup just as fast as
> you can sync from slony (or replicator or whatever).

sorry if my post wasn't clear. slony's not really any better.  I don't
think that there's any replication for pgsql that's easy to do that
in.  Is there?

-- 
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] Startup process thrashing

[Greg Smith]

On Thu, 11 Dec 2008, Phillip Berry wrote:

I've got a bit of a problem.  It started last night when postgres 
(8.1.9) went down citing the need for a vacuum full to be done due to 
the transaction log needing to wraparound.


Not exactly.  What it said was "To avoid a database shutdown, execute a 
full-database VACUUM".  In that context, "full" means you vacuum 
everything in the database, but only regular VACUUM is needed.  VACUUM 
FULL, as you learned the hard way, is a more intensive operation, and it's 
not needed to resolve the problem you started with.  It's a somewhat 
unfortunately worded HINT.


During the vacuum of the larger of the databases a few hours in it 
failed, it's filled up the 18GB pg_xlog partition with over 1000 wal 
files.  Due to running out of space the vacuum failed.


Ouch.  Are you running PITR recovery by setting archive_command?  Did you 
set checkpoint_segments to some very high value?  1000 WAL files is not 
normal, curious how you ended up with so many of them.



When I came in this morning I attempted to start postgres using the normal init 
script, and now it's
stuck.  The startup process is thrashing the disks and working hard, 
pg_controldata says it's in
recovery, but it's been going for over two hours.


It takes a long time to sort through 1000 WAL files and figure out if the 
database is consistent for every transactions mentioned there.  If your 
VACUUM FULL ran for several hours and kicked out 1000 of them, it would be 
reasonable to expect the cleanup to also take many hours.



My question is where I should go from here?  Should i kill the startup script, 
clear out the excess
wal files, start the standalone server and try vacuum again?


Deleting the WAL files like that will leave your database completely 
trashed.  The utility that's provided to do the job you're considering is 
pg_resetxlog:


http://www.postgresql.org/docs/8.1/static/app-pgresetxlog.html

Which is slightly safer, but note the dire warnings there.  You are very 
likely to get some sort of data corruption if you do that, and you won't 
know where it is.  You'll be facing a dump and restore to sort that out, 
and if you think the server startup is taking a while on a 156GB database 
you're really not going to be happy with how long a restore takes.


The safest thing you can do here is just wait for the server to finish 
recovery so it starts up.  Watch the system activity with something like 
vmstat.  If the server process is busy using the CPU and it's doing stuff 
with the disks, if you have evidence it's making progress, you'll be hard 
pressed to execute any manual recovery that's any safer or more efficient 
than that is.


Someone else may be able to point you toward better estimating how far 
it's got left to go, I haven't ever been stuck in your position for long 
enough before to figure that out myself.  Good luck.


--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD

--
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] The future of Solaris?

[Greg Smith]

On Wed, 10 Dec 2008, Liraz Siri wrote:

Linux may still be behind Solaris in a few areas but I'll wager Linux 
will catch up and make Solaris completely, utterly obsolete in the not 
too distant future.


Great, free money is even better than free code; how much would you like 
to loo...er, wager on that?  Could use a new sure thing now that there's 
no more money for me to make shorting SCO stock.


I've been hearing this particular refrain constantly since 1996, when I 
first switched to working full-time mainly on Linux systems.  Every year 
seems like it's finally the year for Linux, even on the desktop, yet 
Solaris is still here.  In fact, it's better than ever.  Solaris has been 
aggressively closing the gap with Linux the last few years in the things 
it was most behind on, while keeping a lead in some areas.


As for things it's ahead on, ZFS is still way better than any Linux 
filesystem, with potential challenger Btrfs so far off from being 
enterprise quality that there's a ton of redunant work going into ext4 
just as a stopgap measure.  (You could easily argue that new features like 
"Time Slider" suggest Linux has actually been falling even further behind 
this year).  DTrace is doing wonders for people every day, while potential 
Linux competitor Systemtap seems to have completely missed the point that 
the idea is to make it easy to instrument things safely.


And the biggest thing that used to keep me away from Solaris, how painful 
the packaging made it to get a functional system with the usual GNU tools 
all installed, has been getting better fast lately, and looks almost 
completely cleaned up as of last month's OpenSolaris 2008.11.  The thing I 
think a lot of people miss is that most of the value of a Linux 
distribution is not from Linux itself.  Remember:  Linux is just a kernel. 
Combine a Solaris kernel with the rest of the usual GNU and other tools 
you see on Linux distributions, and most people won't even notice the 
swap.  There will be less supported hardware, and it will be a bit slower 
at some things, but at least the kernel will be stable moving forward.


Which brings me to...the primary thing that really bugs me lately is that 
Linux kernel development is increasingly not focused on stable releases, 
it's all about rapid innovation at any cost.  And the anti-business 
politics of some key contributors is really getting in the way of 
pragmatic adoption.  Check out this great rant from Theodore Tso about how 
badly things are broken in that area: 
http://thread.gmane.org/gmane.linux.file-systems/26246/focus=26492


The part I like is "sometimes people have suspected that some changes made 
had benefits that were so marginal that it seemed that the main 
justification was to screw over externally maintained 
drivers/filesystems".  That's sure how it feels to me.  I have some 
closed-source bits and some things that compile outside of the core kernel 
that I rely on, and every new kernel point release I get breaks one of 
them--often for trivial improvements and with *zero* regard even for the 
transition periods promised by the kernel team itself.  Here's the last 
one I got personally burned by:  http://lkml.org/lkml/2008/2/17/319 
Planned deprecation period?  "sadly it was untenable".  And people wonder 
why I stay as far back from the current kernel as feasible.


Besides Sun Microsystems hasn't been a financially healthy organization 
for quite a few years, as evidenced by its rather dismal stock 
performance:

http://finance.google.com/finance?q=java


Bah, Google Finance makes it hard to refer anybody to a specific chart. 
Stupid AJAX.  How about we stare at these three for a minute:


http://finance.yahoo.com/echarts?s=JAVA#chart1:symbol=java;range=5y
http://finance.yahoo.com/echarts?s=rht#chart1:symbol=rht;range=5y
http://finance.yahoo.com/echarts?s=novl#chart1:symbol=novl;range=5y

Wait, which one of those was the weak one likely to fail?  They all look 
pretty poor to me.  Despite its recent fall, Sun still has the largest 
market cap of the three.  You say it's been going badly for "quite a few 
years", but the only serious divergence from its competitors was only this 
year.  Sun would be doing better right now had they not decided to light 
$1B on fire back in January, that's where their stock really accelerated 
its dive downward.


RedHat is actually by far in the best financial shape of the three, at 
least they make more money than they spend.


--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD

--
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] Data Replication

[Joshua D. Drake]

On Wed, 2008-12-10 at 20:41 -0700, Scott Marlowe wrote:
> On Wed, Dec 10, 2008 at 7:40 PM, Tim Uckun <[EMAIL PROTECTED]> wrote:

> Log shipping doesn't really lends itself to switching back and forth
> between masters and slaves.

Really? It seems to me that you can make a base backup just as fast as
you can sync from slony (or replicator or whatever).

Joshua D. Drake


> 
-- 
PostgreSQL
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


-- 
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] Data Replication

[Scott Marlowe]

On Wed, Dec 10, 2008 at 7:40 PM, Tim Uckun <[EMAIL PROTECTED]> wrote:
>>
>> You have to run a new base backup and have the slave ship logs to the
>> master.
>
> Mmmm. Does this backup have to be a full backup? What if your database
> is very large?

Yes.  Your backup is very large.

> I am hoping to get a setup which is similar to SQL server mirroring.
> It uses a witness server to keep track of who got what "logs" (it's
> based on transaction logging) and allows you to failover and fail back
> without having to do a full backup in between.

Nothing like that really exists for pgsql in terms of log shipping.
If you want some part of your db backed up / replicated somewhere, use
one of the real time replication.  Failover in slony is pretty easy to
do and happens in seconds.  But you do have to resubscribe the master
as a slave and copy everything over again after a failover to make the
old master the new master again.

With the slonik help scripts, it's pretty easy to drive, and lets you
do some interesting things, like having different indexes on the
target than on the source, i.e. for reporting queries.  But DDL's a
bit of a pain.  We take our app down and disconnect all clients before
running ddl changes, and it goes smooth, with a few minutes of
downtime tops.

Log shipping doesn't really lends itself to switching back and forth
between masters and slaves.

-- 
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] Data Replication

[Tim Uckun]

>
> You have to run a new base backup and have the slave ship logs to the
> master.

Mmmm. Does this backup have to be a full backup? What if your database
is very large?

I am hoping to get a setup which is similar to SQL server mirroring.
It uses a witness server to keep track of who got what "logs" (it's
based on transaction logging) and allows you to failover and fail back
without having to do a full backup in between.

>> Is there a product which enables this kind of functionality?
>>
>
> https://projects.commandprompt.com/public/pitrtools
>

I'll check these out. Thanks.

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

[GENERAL] Startup process thrashing

[Phillip Berry]

Hello Everyone,

I've got a bit of a problem.  It started last night when postgres (8.1.9) went 
down citing the need 
for a vacuum full to be done due to the transaction log needing to wraparound.

So I stopped the server, logged in using a standalone backend and started a 
vacuum full analyze on 
all dbs (one being 156GB).  

During the vacuum of the larger of the databases a few hours in it failed, it's 
filled up the 18GB 
pg_xlog partition with over 1000 wal files.  Due to running out of space the 
vacuum failed.

When I came in this morning I attempted to start postgres using the normal init 
script, and now it's 
stuck.  The startup process is thrashing the disks and working hard, 
pg_controldata says it's in 
recovery, but it's been going for over two hours.

My question is where I should go from here?  Should i kill the startup script, 
clear out the excess 
wal files, start the standalone server and try vacuum again?  Or should I just 
wait and see if the 
startup process sorts itself out?

The startup process is responding to login attempts with FATAL:  the database 
system is starting up 
and logging these attempts so I assume it's still alive and working...

I appreciate any help and advice, I really hope it's not going to turn into 
lost data (gulp).

Output from pg_controldata:

pg_control version number:812
Catalog version number:   200510211
Database system identifier:   5142157718116482999
Database cluster state:   in recovery
pg_control last modified: Wed 10 Dec 2008 05:55:52 PM CST
Current log file ID:  811
Next log file segment:221
Latest checkpoint location:   327/8AE2BED0
Prior checkpoint location:327/8AE2BE80
Latest checkpoint's REDO location:327/8AE2BED0
Latest checkpoint's UNDO location:0/0
Latest checkpoint's TimeLineID:   1
Latest checkpoint's NextXID:  2146484231
Latest checkpoint's NextOID:  123620
Latest checkpoint's NextMultiXactId:  806872
Latest checkpoint's NextMultiOffset:  1766404
Time of latest checkpoint:Wed 10 Dec 2008 06:01:01 AM CST
Maximum data alignment:   8
Database block size:  8192
Blocks per segment of large relation: 131072
Bytes per WAL segment:16777216
Maximum length of identifiers:64
Maximum columns in an index:  32
Date/time type storage:   floating-point numbers
Maximum length of locale name:128
LC_COLLATE:   en_US.UTF-8
LC_CTYPE: en_US.UTF-8

-- 
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] Data Replication

[Joshua D. Drake]

On Thu, 2008-12-11 at 15:21 +1300, Tim Uckun wrote:

> What happens when I bring the primary back on line. I now want this to
> be primary again and catch up on all the transactions that were sent
> to the secondary. I want the secondary to resume it's backup status.
> 

You have to run a new base backup and have the slave ship logs to the
master.

> Is there a product which enables this kind of functionality?
> 

https://projects.commandprompt.com/public/pitrtools

-- 
PostgreSQL
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


-- 
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] Data Replication

[Tim Uckun]

On Thu, Dec 11, 2008 at 1:05 PM, David Wall <[EMAIL PROTECTED]> wrote:
> We've done warm standby as you indicate, and we've not needed anything
> special.

Thanks for sharing your configuation. I have one additional question thought...

How do you handle the reverting?  For example.

Say I have a primary database which is located at my main data center.

I am log shipping to a secondary data center.

My primary database server goes down.

Presume I have some scripts or something which detects this and
switches to the secondary.

What happens when I bring the primary back on line. I now want this to
be primary again and catch up on all the transactions that were sent
to the secondary. I want the secondary to resume it's backup status.

Is there a product which enables this kind of functionality?

-- 
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] Ubuntu for servers (was TurnKey PostgreSQL)

[Guy Rouillier]

Joshua D. Drake wrote:


BSD is dying.


We all are, sooner or later ;)

--
Guy Rouillier

--
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] tcp_keepalives_idle setting

[Fujii Masao]

Hi,

On Wed, Dec 10, 2008 at 7:26 PM, Maximilian Tyrtania
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> recently Tom Lane wrote:
>
> "henry" writes:
>>> I have tried setting tcp_keepalives_idle = 120 (eg), then restarting PG,
>>> but SHOW ALL; shows tcp_keepalives_idle=0 (ignoring my setting).
>
>>Just FYI, this is the expected behavior on platforms where the kernel
>>doesn't allow adjustment of the TCP keepalive parameters from
>>userspace.
>
> I'm running pg 8.3.3 on Mac OS 10.4.11 and I'm seeing the same behaviour as
> Henry.
> I'm trying to find out if Mac OS belongs to those platforms that doesn't
> allow adjustment of the TCP keepalive parameters from userspace, and if so,
> how i can change the systems settings as root.

Do you use TCP/IP socket when you execute SHOW ALL? Those parameters
are ignored via Unix-domain socket.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
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] Multi-table CHECK constraint

[David Fetter]

On Wed, Dec 10, 2008 at 05:58:08PM -0600, Jason Long wrote:
> I need to add some complex constraints at the DB.
>
> For example.
>
> Do not allow a line item of inventory to be changed if it does not  
> result in the same number of joints originally shipped.
>
> These will involve several tables.
>
> What is the best approach for this?

Triggers.

> Here is what I have been trying.
>
> CREATE OR REPLACE FUNCTION numoriginaljts(genericitem_id bigint)
>  RETURNS double precision AS
> 'select coalesce(vsjo.diff,0) from inventory.t_generic_item gi
> left join view.generic_item_shipment_id v on v.id=gi.id
> left join v_shipment_jts_off vsjo on vsjo."shipmentId"=v.shipment_id
> where gi.id=$1;'
>  LANGUAGE 'sql' VOLATILE
>  COST 100;
> ALTER FUNCTION numoriginaljts(bigint) OWNER TO exploreco;
>
> alter table inventory.t_generic_item add constraint  
> check_shipment_original_jts CHECK (numoriginaljts(id)=0);
>
> *Does this approach seem reasonable?

Nope.  You're lying to the database by wrapping otherwise disallowed
SQL in a check constraint, and it will get its revenge.

> This did not work, but it is probably my error.  It actually let me
> break the constraint, but my constraint kicked in when I tried to
> correct the problem.  Can someone point me to an example of doing
> something like this?*
>
> The point of this is to never let the total number of original
> pieces be  different than the number originally shipped.
>
> My code has done this occasionally and users can override the
> inventory.
>
> Basically I would rather the application throw an error than let
> this  number become unbalanced.

You might want to talk to people who have done bookkeeping
applications for PostgreSQL, or possibly even buy one of the
proprietary PostgreSQL-based systems for it, as this stuff can be
fiendishly tricky to get right.

Cheers,
David.
-- 
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: [EMAIL PROTECTED]

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
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] Multi-table CHECK constraint

[Jason Long]

Richard Broersma wrote:

On Wed, Dec 10, 2008 at 3:58 PM, Jason Long
<[EMAIL PROTECTED]> wrote:

  

I need to add some complex constraints at the DB.
These will involve several tables.
What is the best approach for this?



Well ANSI-SQL provides the CREATE ASSERTION for this purpose.
However, PostgreSQL doesn't support this feature.  It can be mimiced
by using the PostgreSQL CONSTRAINT TRIGGER extenstion.  IIRC, it works
very much like an ordinary trigger except that you must raise an error
when an DML attempt possibly violates your condition.

  

Can someone point me to an example of doing something like this?



http://www.postgresql.org/docs/8.3/interactive/sql-createconstraint.html
http://www.postgresql.org/docs/8.3/interactive/triggers.html

I hope this helps.


  

Thanks.  I will look into this and see how it goes.

Any other advice would be greatly appreciated.

Re: [GENERAL] Multi-table CHECK constraint

[Richard Broersma]

On Wed, Dec 10, 2008 at 3:58 PM, Jason Long
<[EMAIL PROTECTED]> wrote:

> I need to add some complex constraints at the DB.
> These will involve several tables.
> What is the best approach for this?

Well ANSI-SQL provides the CREATE ASSERTION for this purpose.
However, PostgreSQL doesn't support this feature.  It can be mimiced
by using the PostgreSQL CONSTRAINT TRIGGER extenstion.  IIRC, it works
very much like an ordinary trigger except that you must raise an error
when an DML attempt possibly violates your condition.

> Can someone point me to an example of doing something like this?

http://www.postgresql.org/docs/8.3/interactive/sql-createconstraint.html
http://www.postgresql.org/docs/8.3/interactive/triggers.html

I hope this helps.


-- 
Regards,
Richard Broersma Jr.

Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug

-- 
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] Data Replication

[David Wall]

We've done warm standby as you indicate, and we've not needed anything 
special.


On the primary's postgresql.conf we use:

archive_command = '~/postgresql/bin/copyWAL "%p" "%f"'

Our copyWAL script is just a wrapper for 'scp' since we want to copy the 
data encrypted over the network:


#!/bin/bash

WALPATH=$1
WALFILE=$2
WALCOPYLOG=~/postgresql/logs/WALcopy.log

echo $0 - $(date) - Copy WAL received PATH: $WALPATH and FILE: $WALFILE 
>> $WALCOPYLOG

echo $0 - $(date) - $(ls -l $PGDATA/$WALPATH) >> $WALCOPYLOG

scp -B -C -p "$WALPATH" 
[EMAIL PROTECTED]:postgresql/recoveryWALs/"$WALFILE"

RET=$?
if [ $RET -ne 0 ]; then
 echo $0 - $(date) - Copy WAL PATH: $WALPATH - failed to copy to backup 
system, exit code: $RET >> $WALCOPYLOG

 exit RET
fi

# 0 exit status means successfully copied
exit 0;

On the warm standby, our recovery.conf uses pg_standby, which is part of 
the contrib code:


restore_command = '~/postgresql/bin/pg_standby -l -d -t 
~/postgresql/recoveryWALs/STOP_RECOVERY ~/postgresql/recoveryWALs %f %p 
%r 2>> ~/po

stgresql/logs/pg_standby.log'

We have a script that puts the STOP_RECOVERY file in the specified 
folder when we want it to go into live mode.


Hope this helps

David


Rutherdale, Will wrote:

Thanks, Joshua.

As I mentioned to Steve, warm standby / log shipping seems to be the
main feature I'm looking for.

The PITR solution you mention:  is that an improvement over regular log
shipping?  Or do I misunderstand where that fits into the system?

-Will
  


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

[GENERAL] Multi-table CHECK constraint

[Jason Long]

I need to add some complex constraints at the DB.

For example.

Do not allow a line item of inventory to be changed if it does not 
result in the same number of joints originally shipped.


These will involve several tables.

What is the best approach for this?

Here is what I have been trying.

CREATE OR REPLACE FUNCTION numoriginaljts(genericitem_id bigint)
 RETURNS double precision AS
'select coalesce(vsjo.diff,0) from inventory.t_generic_item gi
left join view.generic_item_shipment_id v on v.id=gi.id
left join v_shipment_jts_off vsjo on vsjo."shipmentId"=v.shipment_id
where gi.id=$1;'
 LANGUAGE 'sql' VOLATILE
 COST 100;
ALTER FUNCTION numoriginaljts(bigint) OWNER TO exploreco;

alter table inventory.t_generic_item add constraint 
check_shipment_original_jts CHECK (numoriginaljts(id)=0);


*Does this approach seem reasonable?
This did not work, but it is probably my error.  It actually let me 
break the constraint, but my constraint kicked in when I tried to 
correct the problem.

Can someone point me to an example of doing something like this?*

The point of this is to never let the total number of original pieces be 
different than the number originally shipped.


My code has done this occasionally and users can override the inventory.

Basically I would rather the application throw an error than let this 
number become unbalanced.


--
Thank you for your time,

Jason Long
CEO and Chief Software Engineer
BS Physics, MS Chemical Engineering
http://www.octgsoftware.com
HJBug Founder and President 
http://www.hjbug.com   

Re: [GENERAL] Data Replication

[Joshua D. Drake]

On Wed, 2008-12-10 at 18:45 -0500, Rutherdale, Will wrote:
> Thanks, Joshua.
> 
> As I mentioned to Steve, warm standby / log shipping seems to be the
> main feature I'm looking for.
> 
> The PITR solution you mention:  is that an improvement over regular log
> shipping?  Or do I misunderstand where that fits into the system?

It is a supplement to the system. Warm standby / log shipping in
postgresql by itself is very bare. Basically you have the ability to
archive files and take a base backup but there are no utilities to
actually perform any of those functions.

PITR Tools gives you a nice wrapper around all the various external
tools you need to get standby working. Once configured it even handles
archiver monitoring etc...

If you look here:

https://projects.commandprompt.com/public/pitrtools/browser/trunk/cmd_standby.README

It will show you how cmd_standby uses pg_standby to perform various
functions (including things like failover).


Sincerely,

Joshua D. Drake


-- 
PostgreSQL
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


-- 
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] Data Replication

[Rutherdale, Will]

Thanks, Joshua.

As I mentioned to Steve, warm standby / log shipping seems to be the
main feature I'm looking for.

The PITR solution you mention:  is that an improvement over regular log
shipping?  Or do I misunderstand where that fits into the system?

-Will


-Original Message-
From: Joshua D. Drake [mailto:[EMAIL PROTECTED] 
Sent: 10 December 2008 17:52
To: Rutherdale, Will
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Data Replication

On Wed, 2008-12-10 at 17:18 -0500, Rutherdale, Will wrote:
> Hi.
> 
> I am trying to determine what kind of data replication is currently
> available in PostgreSQL.  This is for purposes of examining
capabilities
> of PostgreSQL as compared to other RDBMSs.
> 
> I attempted some searches in various areas and came up with a
> bewildering array of results but no clear answer.
> 
> a)  Slony-I provides master/slave data replication (3rd party product
> but FOSS)

Correct.

> b)  PGCluster for Multi-master data replication, also 3rd party add-on
> tool, also FOSS.

Correct. Unsure of stability.

> c)  Postgres-R for multi-master data replication, appears to be a code
> fork of PostgreSQL

Not stable as far as I know.

> d)  Support for data replication in core PostgreSQL engine coming up,
as
> announced in this article in June 2008:
>
http://scale-out-blog.blogspot.com/2008/06/postgresql-gets-religion-abou
> t.html

  e) PITR which is asynchronous log shipping. This is available in all
versions >= 8.1 (foss)

  f) PostgreSQL Replicator an asynchronous replication system and a fork
of the core postgresql (see
https://projects.commandprompt.com/public/replicator)

  g) Londiste, created by Skype. Similar to Slony but easier to manage

> 
> By contrast, when I search a similar question about MySQL, I get a
clear
> answer that both master/slave and multi-master data replication are
> supported directly by the core engine.

And broken but yes :)

> 
> Could somebody please help me sort this out?  I would like to know
> 
> i)  What is the current available support for data replication in
> PostgreSQL?

See above. Let me know if it is unclear.

> ii)  Does anybody have experience with these tools they could share?

Slony is useful if a bit difficult to manage. It is extremely flexible
however. We have several customers that user it.

Replicator is a previously closed source product. It is easy to use and
the latest version for 8.3 is in beta with 1.9 on the horizon which adds
DDL replication. We have several customers that use it.

Londiste I have played with a bit, it works but I have no production
experience with it.

> iii)  Is data replication planned for an upcoming release of
PostgreSQL,
> and if so what are the exact features and when is the release
expected?
> 

Planned yes, guaranteed no and it is still log shipping which means read
only slaves are out (as I recall).

Sincerely,

Joshua D. Drake



> -Will
> 
> 
> 
> 
>  - - - - -  Cisco
- - - - -
> This e-mail and any attachments may contain information which is
confidential,
> proprietary, privileged or otherwise protected by law. The information
is solely
> intended for the named addressee (or a person responsible for
delivering it to
> the addressee). If you are not the intended recipient of this message,
you are
> not authorized to read, print, retain, copy or disseminate this
message or any
> part of it. If you have received this e-mail in error, please notify
the sender
> immediately by return e-mail and delete it from your computer.
> 
> 
-- 
PostgreSQL
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


-- 
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] Data Replication

[Joshua D. Drake]

On Wed, 2008-12-10 at 18:34 -0500, Rutherdale, Will wrote:
> Thanks very much, Steve.
> 
> The main (but not only) type of data replication activity I'm interested
> in right now would be the warm standby.  Thus it appears from the
> documents you showed me that log shipping is one solution currently
> available in PostgreSQL.  I would want to make this work between
> geographically separated machines that have TCP/IP connectivity between
> them.
> 
> From what I understand from the documents so far, I can set up log
> shipping using pgsql without any external packages.  There also seems to
> be support for periodic backups from the primary to the warm standby.

You can. There is a BSD open source project here:

http://projects.commandprompt.com/public/pitrtools

That will help you with your warm standby needs quite a bit.

Joshua D. Drake

-- 
PostgreSQL
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


-- 
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] Data Replication

[Rutherdale, Will]

Thanks very much, Steve.

The main (but not only) type of data replication activity I'm interested
in right now would be the warm standby.  Thus it appears from the
documents you showed me that log shipping is one solution currently
available in PostgreSQL.  I would want to make this work between
geographically separated machines that have TCP/IP connectivity between
them.

From what I understand from the documents so far, I can set up log
shipping using pgsql without any external packages.  There also seems to
be support for periodic backups from the primary to the warm standby.

-Will

BTW  Hope you don't mind my quoting style.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steve Atkins
Sent: 10 December 2008 17:50
To: PostgreSQL General
Subject: Re: [GENERAL] Data Replication


On Dec 10, 2008, at 2:18 PM, Rutherdale, Will wrote:

> Hi.
>
> I am trying to determine what kind of data replication is currently
> available in PostgreSQL.  This is for purposes of examining
> capabilities
> of PostgreSQL as compared to other RDBMSs.
>
> I attempted some searches in various areas and came up with a
> bewildering array of results but no clear answer.
>
> a)  Slony-I provides master/slave data replication (3rd party product
> but FOSS)
> b)  PGCluster for Multi-master data replication, also 3rd party add-on
> tool, also FOSS.
> c)  Postgres-R for multi-master data replication, appears to be a code
> fork of PostgreSQL
> d)  Support for data replication in core PostgreSQL engine coming
> up, as
> announced in this article in June 2008:
>
http://scale-out-blog.blogspot.com/2008/06/postgresql-gets-religion-abou
> t.html
>
> By contrast, when I search a similar question about MySQL, I get a
> clear
> answer that both master/slave and multi-master data replication are
> supported directly by the core engine.

Kinda.

> Could somebody please help me sort this out?  I would like to know
>
> i)  What is the current available support for data replication in
> PostgreSQL?

There's not really such a thing as one true replication solution. There
are a wide range of different requirements and tradeoffs. HA is
different
to load balancing is different to geographical distribution and so on.

http://www.postgresql.org/docs/8.3/static/high-availability.html covers
some of the tradeoffs of different approaches.

Log shipping, skytools and pgpool are the three main methods I can
think of that you didn't mention.

http://wiki.postgresql.org/wiki/Replication%2C_Clustering%2C_and_Connect
ion_Pooling
  has
others, and a bunch of references.

> ii)  Does anybody have experience with these tools they could share?
> iii)  Is data replication planned for an upcoming release of
> PostgreSQL,
> and if so what are the exact features and when is the release
> expected?

See http://www.postgresql.org/docs/8.3/static/warm-standby.html for
the current in-core support for log-shipping based replication.

Cheers,
   Steve


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



 - - - - -  Cisco- 
- - - -
This e-mail and any attachments may contain information which is confidential,
proprietary, privileged or otherwise protected by law. The information is solely
intended for the named addressee (or a person responsible for delivering it to
the addressee). If you are not the intended recipient of this message, you are
not authorized to read, print, retain, copy or disseminate this message or any
part of it. If you have received this e-mail in error, please notify the sender
immediately by return e-mail and delete it from your computer.


-- 
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] Ubuntu for servers (was TurnKey PostgreSQL)

[Andrew Gould]

On Wed, Dec 10, 2008 at 4:04 PM, Joshua D. Drake <[EMAIL PROTECTED]>wrote:

> On Wed, 2008-12-10 at 15:55 -0500, Eric Schwarzenbach wrote:
> > Robert Treat wrote:
> > > On Tuesday 09 December 2008 19:43:02 Liraz Siri wrote:
> > >
> > >> Greg has a good point. Ubuntu is a bit of a moving target. In
> contrast,
> > >> Debian has a much slower release cycle than Ubuntu and is thus
> > >> considered by many people to be preferable for production server
> > >> applications.
> > >>
> > >>
> > >
> > > Another option for folks is to switch to another operating system thats
> a bit
> > > more stable *cough*solaris*cough*bsd*cough*
> > >
> > > :-)
> > >
> > And don't forget about BSD.
>
> BSD is dying.
>

Cron can find no entry for this event.  We apologize for any inconvenience.

 - Andrew

Re: [GENERAL] Data Replication

[Joshua D. Drake]

On Wed, 2008-12-10 at 17:18 -0500, Rutherdale, Will wrote:
> Hi.
> 
> I am trying to determine what kind of data replication is currently
> available in PostgreSQL.  This is for purposes of examining capabilities
> of PostgreSQL as compared to other RDBMSs.
> 
> I attempted some searches in various areas and came up with a
> bewildering array of results but no clear answer.
> 
> a)  Slony-I provides master/slave data replication (3rd party product
> but FOSS)

Correct.

> b)  PGCluster for Multi-master data replication, also 3rd party add-on
> tool, also FOSS.

Correct. Unsure of stability.

> c)  Postgres-R for multi-master data replication, appears to be a code
> fork of PostgreSQL

Not stable as far as I know.

> d)  Support for data replication in core PostgreSQL engine coming up, as
> announced in this article in June 2008:
> http://scale-out-blog.blogspot.com/2008/06/postgresql-gets-religion-abou
> t.html

  e) PITR which is asynchronous log shipping. This is available in all
versions >= 8.1 (foss)

  f) PostgreSQL Replicator an asynchronous replication system and a fork
of the core postgresql (see
https://projects.commandprompt.com/public/replicator)

  g) Londiste, created by Skype. Similar to Slony but easier to manage

> 
> By contrast, when I search a similar question about MySQL, I get a clear
> answer that both master/slave and multi-master data replication are
> supported directly by the core engine.

And broken but yes :)

> 
> Could somebody please help me sort this out?  I would like to know
> 
> i)  What is the current available support for data replication in
> PostgreSQL?

See above. Let me know if it is unclear.

> ii)  Does anybody have experience with these tools they could share?

Slony is useful if a bit difficult to manage. It is extremely flexible
however. We have several customers that user it.

Replicator is a previously closed source product. It is easy to use and
the latest version for 8.3 is in beta with 1.9 on the horizon which adds
DDL replication. We have several customers that use it.

Londiste I have played with a bit, it works but I have no production
experience with it.

> iii)  Is data replication planned for an upcoming release of PostgreSQL,
> and if so what are the exact features and when is the release expected?
> 

Planned yes, guaranteed no and it is still log shipping which means read
only slaves are out (as I recall).

Sincerely,

Joshua D. Drake



> -Will
> 
> 
> 
> 
>  - - - - -  Cisco
> - - - - -
> This e-mail and any attachments may contain information which is confidential,
> proprietary, privileged or otherwise protected by law. The information is 
> solely
> intended for the named addressee (or a person responsible for delivering it to
> the addressee). If you are not the intended recipient of this message, you are
> not authorized to read, print, retain, copy or disseminate this message or any
> part of it. If you have received this e-mail in error, please notify the 
> sender
> immediately by return e-mail and delete it from your computer.
> 
> 
-- 
PostgreSQL
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


-- 
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] Data Replication

[Steve Atkins]

On Dec 10, 2008, at 2:18 PM, Rutherdale, Will wrote:


Hi.

I am trying to determine what kind of data replication is currently
available in PostgreSQL.  This is for purposes of examining  
capabilities

of PostgreSQL as compared to other RDBMSs.

I attempted some searches in various areas and came up with a
bewildering array of results but no clear answer.

a)  Slony-I provides master/slave data replication (3rd party product
but FOSS)
b)  PGCluster for Multi-master data replication, also 3rd party add-on
tool, also FOSS.
c)  Postgres-R for multi-master data replication, appears to be a code
fork of PostgreSQL
d)  Support for data replication in core PostgreSQL engine coming  
up, as

announced in this article in June 2008:
http://scale-out-blog.blogspot.com/2008/06/postgresql-gets-religion-abou
t.html

By contrast, when I search a similar question about MySQL, I get a  
clear

answer that both master/slave and multi-master data replication are
supported directly by the core engine.


Kinda.


Could somebody please help me sort this out?  I would like to know

i)  What is the current available support for data replication in
PostgreSQL?


There's not really such a thing as one true replication solution. There
are a wide range of different requirements and tradeoffs. HA is  
different

to load balancing is different to geographical distribution and so on.

http://www.postgresql.org/docs/8.3/static/high-availability.html covers
some of the tradeoffs of different approaches.

Log shipping, skytools and pgpool are the three main methods I can
think of that you didn't mention.

http://wiki.postgresql.org/wiki/Replication%2C_Clustering%2C_and_Connection_Pooling 
 has

others, and a bunch of references.


ii)  Does anybody have experience with these tools they could share?
iii)  Is data replication planned for an upcoming release of  
PostgreSQL,
and if so what are the exact features and when is the release  
expected?


See http://www.postgresql.org/docs/8.3/static/warm-standby.html for
the current in-core support for log-shipping based replication.

Cheers,
  Steve


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

[GENERAL] Data Replication

[Rutherdale, Will]

Hi.

I am trying to determine what kind of data replication is currently
available in PostgreSQL.  This is for purposes of examining capabilities
of PostgreSQL as compared to other RDBMSs.

I attempted some searches in various areas and came up with a
bewildering array of results but no clear answer.

a)  Slony-I provides master/slave data replication (3rd party product
but FOSS)
b)  PGCluster for Multi-master data replication, also 3rd party add-on
tool, also FOSS.
c)  Postgres-R for multi-master data replication, appears to be a code
fork of PostgreSQL
d)  Support for data replication in core PostgreSQL engine coming up, as
announced in this article in June 2008:
http://scale-out-blog.blogspot.com/2008/06/postgresql-gets-religion-abou
t.html

By contrast, when I search a similar question about MySQL, I get a clear
answer that both master/slave and multi-master data replication are
supported directly by the core engine.

Could somebody please help me sort this out?  I would like to know

i)  What is the current available support for data replication in
PostgreSQL?
ii)  Does anybody have experience with these tools they could share?
iii)  Is data replication planned for an upcoming release of PostgreSQL,
and if so what are the exact features and when is the release expected?

-Will




 - - - - -  Cisco- 
- - - -
This e-mail and any attachments may contain information which is confidential,
proprietary, privileged or otherwise protected by law. The information is solely
intended for the named addressee (or a person responsible for delivering it to
the addressee). If you are not the intended recipient of this message, you are
not authorized to read, print, retain, copy or disseminate this message or any
part of it. If you have received this e-mail in error, please notify the sender
immediately by return e-mail and delete it from your computer.


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

[GENERAL] When to hold Pg East

[Joshua D. Drake]

Hello,

While I am currently negotiating where to hold Pg East, it would be
great if we could get some community to help us determine WHEN to hold
Pg East.

There is a very short survey (four or five questions) over at:

http://www.postgresqlconference.org/2009/east/

If I could get responses to it that would be very helpful, thanks!

Sincerely,

Joshua D. Drake
-- 
PostgreSQL
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


-- 
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] Ubuntu for servers (was TurnKey PostgreSQL)

[Joshua D. Drake]

On Wed, 2008-12-10 at 15:55 -0500, Eric Schwarzenbach wrote:
> Robert Treat wrote:
> > On Tuesday 09 December 2008 19:43:02 Liraz Siri wrote:
> >   
> >> Greg has a good point. Ubuntu is a bit of a moving target. In contrast,
> >> Debian has a much slower release cycle than Ubuntu and is thus
> >> considered by many people to be preferable for production server
> >> applications.
> >>
> >> 
> >
> > Another option for folks is to switch to another operating system thats a 
> > bit 
> > more stable *cough*solaris*cough*bsd*cough* 
> >
> > :-)
> >   
> And don't forget about BSD.

BSD is dying.

> 
-- 
PostgreSQL
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


-- 
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] Getting text into a table

[novice]

2008/12/11 Mark Morgan Lloyd <[EMAIL PROTECTED]>:
> I wonder if I could ask a question which might be marginally off-topic: how
> do people assemble multiple lines of text into a row in a table?
>
> I've got a number of cases where I've got a file containing some sort of
> activity log, where a sequence of activities extends over multiple lines.
>
> In some cases multiple activities might be interleaved, rather than each
> activity comprising a sequence of contiguous lines.
>
> Complicating things, related lines might be only recognisable by content.
>
> As an example, a Sendmail maillog file where a delayed outgoing message will
> result in a number of lines of text. I'd like each row in the table to
> contain the sender, recipient, eventual state, and the time it took to
> arrive at that state.
>
> I'm sure I'm not the only person doing this sort of thing, but there has to
> be a better answer than coding Perl for each job. Does anybody have any
> suggestions for tools well-matched to this sort of problem, i.e. that can
> match patterns, store matched patterns or update counters, backtrack where
> necessary, and so on?
>

You're right, you're not the only one. I use awk and postgres's substr
function, but I'm only a newbie and I'm hoping to hear about the more
easy/advanced options available.

-- 
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] Ubuntu for servers (was TurnKey PostgreSQL)

[Eric Schwarzenbach]

Robert Treat wrote:
> On Tuesday 09 December 2008 19:43:02 Liraz Siri wrote:
>   
>> Greg has a good point. Ubuntu is a bit of a moving target. In contrast,
>> Debian has a much slower release cycle than Ubuntu and is thus
>> considered by many people to be preferable for production server
>> applications.
>>
>> 
>
> Another option for folks is to switch to another operating system thats a bit 
> more stable *cough*solaris*cough*bsd*cough* 
>
> :-)
>   
And don't forget about BSD.

-- 
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] The future of Solaris?

[Liraz Siri]

Damian Carey wrote:

> I understand and accept that this is just your opinion, but its sheer
> dripping passion tends to highlight its lack objectivity!
> "and make Solaris completely, utterly obsolete in the not too distant future".

For what it's worth, I really like Solaris. I wish Linux had dtrace
(last time I checked systemtap still had a long way to go).

> For what it's worth ..
> 1. Solaris and Linux are both fine pieces of technology

No doubt.

> 2. In the most general sense, I suspect Solaris (in general) will
> survive longer than your next Ubuntu instance, so you would be safe
> using Solaris instead of Ubuntu.

Well, the way I see it Ubuntu is really just a specialized version of
Debian. If it were not for Debian, Ubuntu would definitely be weaker
than Solaris in terms of long term viability. Not to mention it would
suffer from the same centralized point of failure. Debian on the other
hand is a different story. It's been around for 15 years and I'll wager
it'll still be alive and kicking 15 years from now. I'm not sure you can
say the same for Solaris though...

> 3. Sun is struggling, but it is made up of profitable and unprofitable
> areas. The Solaris and Server areas would seem to be relatively
> profitable, so even if Sun as a whole failed, the profitable areas
> would likely march on into the future.

The trouble with Solaris is that it's fleeing into the high-end while
Linux is constantly eroding it's position from below. Sure, Solaris
still has a profitable edge in some high-end applications but there is a
huge amount of momentum behind Linux, which seems to be catching up. In
other words, even if Solaris is profitable now that doesn't necessarily
mean it will be profitable 5 years from now.

> 4. As anyone with a little life experience could tell you, things
> don't just disappear. That is true in computer or other areas of life.
> Cobal aint going away. Baddies aint going away. Religion aint going
> away. There are plenty of Solaris fan boys to keep Solaris going.
> Even if all your friends tell you it is bad and as god as dead.

I agree. "Old" technologies never seem to die off completely, but many
of them do seem to retire into archaic pockets of isolated, neglected
obscurity.

> 5. Ubutu is generally an excellent choice for a desktop, and Solaris
> is generally an excellent choice as a server.

No argument.

> Did I tell you I currently use MS-Windows exclusively! Not because of
> the technology, but just because all my customers do.

Network effects will do that to you. :)

I'm thinking maybe it was a mistake to bring up the subject. It's
certainly off topic, and I suspect continuing the discussion will
generate more heat than light, so let's just agree to wait and see.

Putting my intuitions aside, I personally would very much like to see
Solaris survive over the long haul. It's always been a source for
technical excellence and innovation in the "boring" systems space and
having competition will be good for our ecosystem.

(That wraps it up for me)

Cheers,
Liraz

-- 
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] The future of Solaris?

[Martin Gainty]

what is this single point of failure?

have you submitted the bug to a JIRA or bugzilla to address this?
http://docs.sun.com/app/docs/doc/817-0552/gbfdy?a=view

If the patch was not in latest distro 
http://docs.sun.com/app/docs/doc/817-0552/apa-sparc-23587?a=view

then when will it be scheduled in?

thanks,
Martin 

__ 
Disclaimer and confidentiality note 
Everything in this e-mail and any attachments relates to the official business 
of Sender. This transmission is of a confidential nature and Sender does not 
endorse distribution to any party other than intended recipient. Sender does 
not necessarily endorse content contained within this transmission. 




> Date: Wed, 10 Dec 2008 21:00:11 +0200
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: pgsql-general@postgresql.org
> Subject: [GENERAL] The future of Solaris?
> 
> Guy Rouillier wrote:
> > Liraz Siri wrote:
> >> Solaris is awesome (dtrace rocks!), but I still prefer Debian/Linux for
> >> the same reasons I prefer PostgreSQL over MySQL - its lack of dependence
> >> on any single company.
> > 
> > OpenSolaris?
> > 
> 
> I think it takes more than a license to make a true community opensource
> project. You need significant buy-in from a large consortium of diverse
> interests. Sun dominates Solaris/OpenSolaris development and IMHO it is
> unlikely Solaris would survive as a viable long term option if Sun
> dropped support for it. Solaris has a single point of failure. Linux may
> still be behind Solaris in a few areas but I'll wager Linux will catch
> up and make Solaris completely, utterly obsolete in the not too distant
> future. Sun opened up Solaris too late. It has no future outside of tiny
> specialized niches and legacy installations.
> 
> But thats just my opinion. I could be wrong.
> 
> Cheers,
> Liraz
> 
> -- 
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

_
Send e-mail anywhere. No map, no compass.
http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_anywhere_122008

Re: [GENERAL] The future of Solaris?

[Dann Corbit]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-general-
> [EMAIL PROTECTED] On Behalf Of Emanuel Calvo Franco
> Sent: Wednesday, December 10, 2008 11:27 AM
> To: Liraz Siri; General PostgreSQL List
> Subject: Re: [GENERAL] The future of Solaris?
> 
> 2008/12/10 Liraz Siri <[EMAIL PROTECTED]>:
> > Guy Rouillier wrote:
> >> Liraz Siri wrote:
> >>> Solaris is awesome (dtrace rocks!), but I still prefer
Debian/Linux
> for
> >>> the same reasons I prefer PostgreSQL over MySQL - its lack of
> dependence
> >>> on any single company.
> >>
> >> OpenSolaris?
> >>
> >
> > I think it takes more than a license to make a true community
> opensource
> > project. You need significant buy-in from a large consortium of
> diverse
> > interests. Sun dominates Solaris/OpenSolaris development and IMHO it
> is
> > unlikely Solaris would survive as a viable long term option if Sun
> > dropped support for it. Solaris has a single point of failure. Linux
> may
> > still be behind Solaris in a few areas but I'll wager Linux will
> catch
> > up and make Solaris completely, utterly obsolete in the not too
> distant
> > future. Sun opened up Solaris too late. It has no future outside of
> tiny
> > specialized niches and legacy installations.
> >
> 
> Just look at the last improvements about new technologies of Sun
> (Solaris -Os)  versus Linux and you will see that Solaris is more
alive
> than everytime.
> 
> You said Solaris will be obsolete. I think you must read about the
> new projects of Sun and the community inside (Open Source Community).
> 
> In fact Sun, sponsor the Open Source (adding Postgresql).
> At the end, the projects more care are from high-end companies.
> 
> In other hand, in the year 2000 several people saids the same things
> about Linux, but the prophecies was wrong.
> 
> In fact, Windows still leading the statistics and linux don't have
> too much numbers than we could think.
> 
> I'm not Sun fan-boy. I'm linux sysadmin. But i'm tired of hearing that
> Linux is the best, when there are serious bugs in some developments
> and most of the real high-servers are in Unix platforms.
> 
> in other way, we must think in aviability of Postgres to run better in
> every platform and do not underestimate the benefits of each platform.
> 
> sorry for my poor english :)

Reminds me of the quote:
"The reports of my death are somewhat exaggerated."

Operating systems ebb and flow and die {if ever} very, very slowly.
If a tool works for a business, they will keep using it for a very, very
long time.

We have customers running on 1985 VAX hardware using RMS and Rdb 4.x
which is absolutely ancient.  But if it fully accomplishes the mission
it needs to fulfill, why change anything?  I think Sun is getting
smarter and smarter (from what I have seen) and I guess that they are
going to do very well.  But our guesses don't matter.

The brilliant strategy of PostgreSQL is to have as open an architecture
as possible so that it compiles anywhere.  So if Linux takes the world
by storm, everyone can have PostgreSQL on Linux.  Or if Windows
dominates, then fine -- PostgreSQL on Windows.  If Apple should suddenly
go nuclear then we can have PostgreSQL on our Macs.  And if Sun blooms
into a fireball in space then our rocket ships can all be powered by
PostgreSQL.

People are always predicting the demise of operating systems and
programming languages.  And you know what?  Most of the lines of code in
the world are *still* written in COBOL .  Maybe COBOL is not as
active for new projects any more, but all of that COBOL is not just
going to go away.  And with a million or so Sun boxes sitting around in
IT centers, Sun is going to be here for a good, long while too.

So my advice is -- don't worry about it.



-- 
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] The future of Solaris?

[Emanuel Calvo Franco]

2008/12/10 Liraz Siri <[EMAIL PROTECTED]>:
> Guy Rouillier wrote:
>> Liraz Siri wrote:
>>> Solaris is awesome (dtrace rocks!), but I still prefer Debian/Linux for
>>> the same reasons I prefer PostgreSQL over MySQL - its lack of dependence
>>> on any single company.
>>
>> OpenSolaris?
>>
>
> I think it takes more than a license to make a true community opensource
> project. You need significant buy-in from a large consortium of diverse
> interests. Sun dominates Solaris/OpenSolaris development and IMHO it is
> unlikely Solaris would survive as a viable long term option if Sun
> dropped support for it. Solaris has a single point of failure. Linux may
> still be behind Solaris in a few areas but I'll wager Linux will catch
> up and make Solaris completely, utterly obsolete in the not too distant
> future. Sun opened up Solaris too late. It has no future outside of tiny
> specialized niches and legacy installations.
>

Just look at the last improvements about new technologies of Sun
(Solaris -Os)  versus Linux and you will see that Solaris is more alive
than everytime.

You said Solaris will be obsolete. I think you must read about the
new projects of Sun and the community inside (Open Source Community).

In fact Sun, sponsor the Open Source (adding Postgresql).
At the end, the projects more care are from high-end companies.

In other hand, in the year 2000 several people saids the same things
about Linux, but the prophecies was wrong.

In fact, Windows still leading the statistics and linux don't have
too much numbers than we could think.

I'm not Sun fan-boy. I'm linux sysadmin. But i'm tired of hearing that
Linux is the best, when there are serious bugs in some developments
and most of the real high-servers are in Unix platforms.

in other way, we must think in aviability of Postgres to run better in
every platform and do not underestimate the benefits of each platform.

sorry for my poor english :)

> But thats just my opinion. I could be wrong.
>
> Cheers,
> Liraz
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>



-- 
  Emanuel Calvo Franco
Syscope Postgresql Consultant
 ArPUG / AOSUG Member

-- 
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] The future of Solaris?

[Damian Carey]

On Thu, Dec 11, 2008 at 6:00 AM, Liraz Siri <[EMAIL PROTECTED]> wrote:
> Guy Rouillier wrote:
>> Liraz Siri wrote:
>>> Solaris is awesome (dtrace rocks!), but I still prefer Debian/Linux for
>>> the same reasons I prefer PostgreSQL over MySQL - its lack of dependence
>>> on any single company.
>>
>> OpenSolaris?
>>
> I think it takes more than a license to make a true community opensource
> project. You need significant buy-in from a large consortium of diverse
> interests. Sun dominates Solaris/OpenSolaris development and IMHO it is
> unlikely Solaris would survive as a viable long term option if Sun
> dropped support for it. Solaris has a single point of failure. Linux may
> still be behind Solaris in a few areas but I'll wager Linux will catch
> up and make Solaris completely, utterly obsolete in the not too distant
> future. Sun opened up Solaris too late. It has no future outside of tiny
> specialized niches and legacy installations.
> But thats just my opinion. I could be wrong.
> Cheers,
> Liraz

I understand and accept that this is just your opinion, but its sheer
dripping passion tends to highlight its lack objectivity!
"and make Solaris completely, utterly obsolete in the not too distant future".

For what it's worth ..
1. Solaris and Linux are both fine pieces of technology
2. In the most general sense, I suspect Solaris (in general) will
survive longer than your next Ubuntu instance, so you would be safe
using Solaris instead of Ubuntu.
3. Sun is struggling, but it is made up of profitable and unprofitable
areas. The Solaris and Server areas would seem to be relatively
profitable, so even if Sun as a whole failed, the profitable areas
would likely march on into the future.
4. As anyone with a little life experience could tell you, things
don't just disappear. That is true in computer or other areas of life.
Cobal aint going away. Baddies aint going away. Religion aint going
away. There are plenty of Solaris fan boys to keep Solaris going.
Even if all your friends tell you it is bad and as god as dead.
5. Ubutu is generally an excellent choice for a desktop, and Solaris
is generally an excellent choice as a server.

Did I tell you I currently use MS-Windows exclusively! Not because of
the technology, but just because all my customers do.

All the best
-Damian

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

[GENERAL] The future of Solaris?

[Liraz Siri]

Guy Rouillier wrote:
> Liraz Siri wrote:
>> Solaris is awesome (dtrace rocks!), but I still prefer Debian/Linux for
>> the same reasons I prefer PostgreSQL over MySQL - its lack of dependence
>> on any single company.
> 
> OpenSolaris?
> 

I think it takes more than a license to make a true community opensource
project. You need significant buy-in from a large consortium of diverse
interests. Sun dominates Solaris/OpenSolaris development and IMHO it is
unlikely Solaris would survive as a viable long term option if Sun
dropped support for it. Solaris has a single point of failure. Linux may
still be behind Solaris in a few areas but I'll wager Linux will catch
up and make Solaris completely, utterly obsolete in the not too distant
future. Sun opened up Solaris too late. It has no future outside of tiny
specialized niches and legacy installations.

But thats just my opinion. I could be wrong.

Cheers,
Liraz

-- 
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] Ubuntu for servers (was TurnKey PostgreSQL)

[Emanuel Calvo Franco]

2008/12/10 Liraz Siri <[EMAIL PROTECTED]>:
> Robert Treat wrote:
>> On Tuesday 09 December 2008 19:43:02 Liraz Siri wrote:
>>> Greg has a good point. Ubuntu is a bit of a moving target. In contrast,
>>> Debian has a much slower release cycle than Ubuntu and is thus
>>> considered by many people to be preferable for production server
>>> applications.
>>>
>>
>> Another option for folks is to switch to another operating system thats a bit
>> more stable *cough*solaris*cough*bsd*cough*
>
> Solaris is awesome (dtrace rocks!), but I still prefer Debian/Linux for
> the same reasons I prefer PostgreSQL over MySQL - its lack of dependence
> on any single company.
>

But in the other hand, solaris platform has got  a really good deployment in
clusterization for Open Solaris and Solaris (visit
http://docs.sun.com/app/docs/doc/819-5578/cacjgdbc?a=view or
http://www.sun.com/bigadmin/features/articles/postgresql_opensolaris.jsp )
Zfs in combination with PITR could be  am exelent way too.
Too many people think in Sun +Mysql but in fact, Sun still works on Postgresql.

> Besides Sun Microsystems hasn't been a financially healthy organization
> for quite a few years, as evidenced by its rather dismal stock performance:
>

Big companies are in these ways... But i long time measures the have constant
growings and mores stable numbers.

> http://finance.google.com/finance?q=java
>
> Cheers,
> Liraz
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>



-- 
  Emanuel Calvo Franco
Syscope Postgresql Consultant
 ArPUG / AOSUG Member

-- 
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] quit milis

[Thomas Kellerer]

Tonny Sapri, 10.12.2008 09:12:

I want quit milis postgresql.


What are quit milis?


--
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] IN limit

[Scott Marlowe]

On Wed, Dec 10, 2008 at 11:28 AM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 10, 2008 at 11:08 AM, Said Ramirez <[EMAIL PROTECTED]> wrote:
>> Is there a limit to the number of entries I can pass in an IN clause as part
>> of a SELECT statement? As in
>> SELECT baz FROM foo where id in ( 1, 2,... ) ;
>
> I think it's high enough you'd have performance problems before it
> would fail.  If there even is one.

Just tested it with a subselect with 10M rows in an in clause.  Not
sure if that's the same as literal strings though.

-- 
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] IN limit

[Scott Marlowe]

On Wed, Dec 10, 2008 at 11:08 AM, Said Ramirez <[EMAIL PROTECTED]> wrote:
> Is there a limit to the number of entries I can pass in an IN clause as part
> of a SELECT statement? As in
> SELECT baz FROM foo where id in ( 1, 2,... ) ;

I think it's high enough you'd have performance problems before it
would fail.  If there even is one.

-- 
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] Ubuntu for servers (was TurnKey PostgreSQL)

[Guy Rouillier]

Liraz Siri wrote:

Solaris is awesome (dtrace rocks!), but I still prefer Debian/Linux for
the same reasons I prefer PostgreSQL over MySQL - its lack of dependence
on any single company.


OpenSolaris?

--
Guy Rouillier

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

[GENERAL] IN limit

[Said Ramirez]

Is there a limit to the number of entries I can pass in an IN clause as 
part of a SELECT statement? As in

SELECT baz FROM foo where id in ( 1, 2,... ) ;
 Thanks,
  -Said

--
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] c function - undefined symbols

[Tom Lane]

Steffn <[EMAIL PROTECTED]> writes:
> Thanks for your reply. Yes, thats also my suspicion. But what library to 
> include?

There is no library to include --- you need to be building *your* code
as a library that can be loaded into the Postgres backend, which will
supply the missing function.  This is somewhat platform-specific and
frankly I'd suggest using pgxs rather than puzzling it out for yourself.
See
http://www.postgresql.org/docs/8.3/static/xfunc-c.html#XFUNC-C-PGXS

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] 8.2.6 -> 8.1.11: syntax error at or near "OWNED BY"

[Tom Lane]

"Alexander Farber" <[EMAIL PROTECTED]> writes:
> I've pg_dump'ed a database from PostgreSQL 8.2.6 / openSUSE 10.3
> and now trying to load it as a "postgres" user at 8.1.1 / CentOS 5.2
> and get numerous errors like:

In general there is no promise that you can load pg_dump output into
previous server versions.  You'll need to edit the file by hand if you
want to do this.

> (I have to use CentOS and would like to use its native PostgreSQL 8.1)

Even if you have to use CentOS, using 8.1.1 is a horrid idea --- the
current 8.1 release is 8.1.15.  Try to get a more up-to-date copy
of CentOS.

However, there's really no very good reason not to install 8.2 or 8.3
from the RPMs that the Postgres project offers.

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] 8.2.6 -> 8.1.11: syntax error at or near "OWNED BY"

[Alexander Farber]

Hello,

On Wed, Dec 10, 2008 at 3:49 PM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> We run pgsql 8.3 on Centos 5.2 and are VERY happy with the PGDG rpms on it.
>

thanks for the confirmation Scott. I have installed PGDG with pgsql 8.2
at my CentOS 5.2 server and it seems to work now. I hope any updates will
come timely over that PGDG too. (My target as a lazy sysadmin is to
install everything and then to touch that server as seldom as possible)

Greetings from Germany
Alex

-- 
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] 8.2.6 -> 8.1.11: syntax error at or near "OWNED BY"

[Grzegorz Jaśkiewicz]

On Wed, Dec 10, 2008 at 2:21 PM, Alexander Farber
<[EMAIL PROTECTED]> wrote:
> Thank you for replies, I've decided to upgrade by adding
> http://yum.pgsqlrpms.org/ to the yum config at my CentOS server
>

way to go!



-- 
GJ

-- 
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] 8.2.6 -> 8.1.11: syntax error at or near "OWNED BY"

[Scott Marlowe]

On Wed, Dec 10, 2008 at 7:21 AM, Alexander Farber
<[EMAIL PROTECTED]> wrote:
> Thank you for replies, I've decided to upgrade by adding
> http://yum.pgsqlrpms.org/ to the yum config at my CentOS server

We run pgsql 8.3 on Centos 5.2 and are VERY happy with the PGDG rpms on it.

-- 
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] 8.2.6 -> 8.1.11: syntax error at or near "OWNED BY"

[Alexander Farber]

Thank you for replies, I've decided to upgrade by adding
http://yum.pgsqlrpms.org/ to the yum config at my CentOS server

-- 
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] Favorite Tom Lane quotes

[Mark Morgan Lloyd]

Robert Treat wrote:


http://archives.postgresql.org/pgsql-hackers/2006-04/msg00288.php
I remember after reading this post wondering whether Tom uses caffeinated 
soap... 


Reading that link, I'm reminded of the "tertiary storage" code that 
somebody (at UCB?) grafted onto the PostgreSQL server. IIRC There were 
still hooks for it in v6 although they've since been removed.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
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] disallow updates on column or whole table

[Bill Moran]

Don't change thread subjects, it confuses people.  Start a new thread
if you have a new topic.

In response to Peter Billen <[EMAIL PROTECTED]>:
> 
> What is the best way to disallow updates on a column of a table, or even 
> on a whole table itself?
> 
> I can write a BEFORE UPDATE trigger which compares old.column_name(s) to 
> new.column_name(s) and raise an exception if these values are different.
> 
> Are there better ways?

You can use the GRANT system to enforce table-wide restrictions.  See
the docs on GRANT and REVOKE and associated doc sections.

-- 
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

[EMAIL PROTECTED]
Phone: 412-422-3463x4023

-- 
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] 8.2.6 -> 8.1.11: syntax error at or near "OWNED BY"

[Grzegorz Jaśkiewicz]

you should have dump it using pg_dump from 8.1.X. Plus, I don't think
going back is a good idea. There is 8.3 available for centos, use it.

-- 
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] 8.2.6 -> 8.1.11: syntax error at or near "OWNED BY"

[A. Kretschmer]

In response to Alexander Farber :
> Does anybody please know what's wrong here
> (some new syntax introduced in 8.2.x)?

Right.


> And what could I do to workaround it

Update your server or edit the dump.


Andreas
-- 
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID:   0x3FFF606C, privat 0x7F4584DA   http://wwwkeys.de.pgp.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] 8.2.6 -> 8.1.11: syntax error at or near "OWNED BY"

[Scott Marlowe]

On Wed, Dec 10, 2008 at 6:41 AM, Alexander Farber
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've pg_dump'ed a database from PostgreSQL 8.2.6 / openSUSE 10.3
> and now trying to load it as a "postgres" user at 8.1.1 / CentOS 5.2
> and get numerous errors like:

That's not directly supported.  The other direction is.  You could try
dumpig the 8.2 database with the 8.1 dump, but it's not guaranteed to
work either.

> Does anybody please know what's wrong here
> (some new syntax introduced in 8.2.x)?

Yep.

> And what could I do to workaround it
> (I have to use CentOS and would like to use its native PostgreSQL 8.1)

Create the same basic thing by hand in 8.1 and dump it and see what
the syntax looks like.  Now write a script to transform your 8.2 dump
into that format.

OR upgrade your 8.1 machine to 8.2

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

[GENERAL] 8.2.6 -> 8.1.11: syntax error at or near "OWNED BY"

[Alexander Farber]

Hello,

I've pg_dump'ed a database from PostgreSQL 8.2.6 / openSUSE 10.3
and now trying to load it as a "postgres" user at 8.1.1 / CentOS 5.2
and get numerous errors like:

CREATE TABLE
ALTER TABLE
CREATE SEQUENCE
ALTER TABLE
psql:denkwerk.sql:1156: ERROR:  syntax error at or near "OWNED" at character 38
psql:denkwerk.sql:1156: LINE 1: ALTER SEQUENCE resource_types_id_seq
OWNED BY resource_types...
psql:denkwerk.sql:1156:  ^
 setval

  4
(1 row)

The corresponding spot in the dump file is:

CREATE TABLE resource_types (
id integer NOT NULL,
name character varying(60)
);
ALTER TABLE public.resource_types OWNER TO denkwerk;
CREATE SEQUENCE resource_types_id_seq
INCREMENT BY 1
NO MAXVALUE
NO MINVALUE
CACHE 1;
ALTER TABLE public.resource_types_id_seq OWNER TO denkwerk;
ALTER SEQUENCE resource_types_id_seq OWNED BY resource_types.id; --line 1156

Does anybody please know what's wrong here
(some new syntax introduced in 8.2.x)?
And what could I do to workaround it
(I have to use CentOS and would like to use its native PostgreSQL 8.1)

Thank you for any hints
Alex

-- 
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] c function - undefined symbols

[Albe Laurenz]

Steffn wrote:
> I am currently trying my first steps in writing my own functions in C. I 
> read through the documentation and tried the most simple examples as shown in 
> . Sadly 
> this was already the point where I stumbled. I luckily compiled and 
> tested the add_one integer variant. But as soon as I added the 
> add_one_float8 I couldn't link no more. My linker dies with.
> 
> Undefined symbols:
> "_Float8GetDatum", referenced from:
> _add_one_float8 in foo.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> 
> Following the documentation I only added 
> "/Library/PostgreSQL/8.3/include/**" to my header search path. What else 
> do I need to configure?

I guess that the include path you need is 
/Library/PostgreSQL/8.3/include/server.

Where in the documentation did you find the path?
I read the following in
http://www.postgresql.org/docs/8.3/static/xfunc-c.html#AEN40954

 "Use pg_config --includedir-server to find out where the
  PostgreSQL server header files are installed on your system"

What is the result of "pg_config --includedir-server" for you?

Yours,
Laurenz Albe

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

[GENERAL] Getting text into a table

[Mark Morgan Lloyd]

I wonder if I could ask a question which might be marginally off-topic: 
how do people assemble multiple lines of text into a row in a table?


I've got a number of cases where I've got a file containing some sort of 
activity log, where a sequence of activities extends over multiple lines.


In some cases multiple activities might be interleaved, rather than each 
activity comprising a sequence of contiguous lines.


Complicating things, related lines might be only recognisable by content.

As an example, a Sendmail maillog file where a delayed outgoing message 
will result in a number of lines of text. I'd like each row in the table 
to contain the sender, recipient, eventual state, and the time it took 
to arrive at that state.


I'm sure I'm not the only person doing this sort of thing, but there has 
to be a better answer than coding Perl for each job. Does anybody have 
any suggestions for tools well-matched to this sort of problem, i.e. 
that can match patterns, store matched patterns or update counters, 
backtrack where necessary, and so on?


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
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] c function - undefined symbols

[Quan Zongliang]

> I added /Library/PostgreSQL/8.3/lib/** to my library search path,

Try to add "-L/PostgreSQL/8.3/lib -lpg" options to linker's command line.
You can get details with "ld --help".

Good luck.

---
Quan Zongliang
[EMAIL PROTECTED]
CIT Japan:  http://www.cit.co.jp
CIT China:  http://www.citbj.com.cn


-- 
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] Monty on MySQL 5.1: "Oops, we did it again"

[Bruce Momjian]

Gurjeet Singh wrote:
> As I read it, he is supportive of the community process that PG follows; I
> am not so sure he promotes Postgres though :)

I based my comments on discussions I have had with him, not based on his
blog.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] c function - undefined symbols

[Steffn]

Hi!

Thanks for your reply. Yes, thats also my suspicion. But what library to 
include?
I added /Library/PostgreSQL/8.3/lib/** to my library search path, but it 
won't help. If I knew which library I have to add, I think I can figure 
out how to properly configure my build settings. Couldn't find any hints 
in the docu nor in the mailing list.


Thanks,
steffn

Richard Huxton wrote, On 12/10/08 11:21 AM:

Steffn wrote:
  

Undefined symbols:
"_Float8GetDatum", referenced from:
   _add_one_float8 in foo.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Following the documentation I only added
"/Library/PostgreSQL/8.3/include/**" to my header search path. What else
do I need to configure?



I'm not a "C" hacker, but that's failing at the linking stage, not the
compiling stage. Are you missing the right lib to go with your headers?


  


--
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] PostgreSQL and eval()

[Mark Morgan Lloyd]

Richard Huxton wrote:

Mark Morgan Lloyd wrote:

Alternatively I appreciate that I could use PL/pgSQL but that would
assume that if I sent the sequence of operations to somebody else that
he also had it compiled into his server.


Well, pl/pgsql has been automatically included in all recent version of
PG. You might have to issue "CREATE LANGUAGE plpgsql" in the database
first (permissions might be an issue I suppose) but that's all.


Thanks, I'd forgotten it was built by default.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

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

[GENERAL] noobquestion: How does Postgres delete 'smart' when deleting with FK contraints?

[Erwin Moller]

Hi group,

Consider the following simplified table:

create table tbltest(
 testid INTEGER PRIMARY KEY,
 reftotestid INTEGER REFERENCES tbltest(testid),
 langid INTEGER
);

INSERT INTO tbltest (testid,reftotestid,langid) VALUES (1,NULL,4);
INSERT INTO tbltest (testid,reftotestid,langid) VALUES (2,NULL,4);
INSERT INTO tbltest (testid,reftotestid,langid) VALUES (3,2,4);
INSERT INTO tbltest (testid,reftotestid,langid) VALUES (4,3,4);
INSERT INTO tbltest (testid,reftotestid,langid) VALUES (5,1,4);
INSERT INTO tbltest (testid,reftotestid,langid) VALUES (6,2,4);
INSERT INTO tbltest (testid,reftotestid,langid) VALUES (7,3,4);
INSERT INTO tbltest (testid,reftotestid,langid) VALUES (8,4,4);

Now, if I give the command:
delete from tbltest where (testid=1);
I get the error:
ERROR:  update or delete on "tbltest" violates foreign key constraint 
"tbltest_reftotestid_fkey" on "tbltest"
That makes total sense of course. the row with testid which holds 1 is 
still referenced by other rows.


But when I give this command:
delete from tbltest where (langid=4);

Postgres just deletes them all.
That suprised me a little.
I expected, for no particular reason, that postgres would just start 
deleting the records that fit the criteria (in this case all) in some 
'random' order.

So I expected Postgres would hit a FK contraint.

But my Postgresql (8.1) is smart enough to do it anyway. :-)

Now I am curious, can anybody explain to me how Postgresql pulls that trick?

Thanks for your time.

Regards,
Erwin Moller


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

[GENERAL] disallow updates on column or whole table

[Peter Billen]

Hi all,

What is the best way to disallow updates on a column of a table, or even 
on a whole table itself?


I can write a BEFORE UPDATE trigger which compares old.column_name(s) to 
new.column_name(s) and raise an exception if these values are different.


Are there better ways?

Certain properties cannot be changed once inserted. I would like to 
enforce that in my database schema.


Thanks in advance. Kind regards,

Peter

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

[GENERAL] tcp_keepalives_idle setting

[Maximilian Tyrtania]

Hi,

recently Tom Lane wrote:

"henry" writes:
>> I have tried setting tcp_keepalives_idle = 120 (eg), then restarting PG,
>> but SHOW ALL; shows tcp_keepalives_idle=0 (ignoring my setting).

>Just FYI, this is the expected behavior on platforms where the kernel
>doesn't allow adjustment of the TCP keepalive parameters from
>userspace.

I'm running pg 8.3.3 on Mac OS 10.4.11 and I'm seeing the same behaviour as
Henry. 
I'm trying to find out if Mac OS belongs to those platforms that doesn't
allow adjustment of the TCP keepalive parameters from userspace, and if so,
how i can change the systems settings as root.

Maximilian Tyrtania | IT-Entwickler
[EMAIL PROTECTED]
fischerAppelt Kommunikation GmbH



-- 
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] quit milis

[Richard Huxton]

Tonny Sapri wrote:
> I want quit milis postgresql.

There is a form you can fill in here:

http://www.postgresql.org/community/lists/

-- 
  Richard Huxton
  Archonet Ltd

-- 
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] c function - undefined symbols

[Richard Huxton]

Steffn wrote:
> Undefined symbols:
> "_Float8GetDatum", referenced from:
>_add_one_float8 in foo.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> 
> Following the documentation I only added
> "/Library/PostgreSQL/8.3/include/**" to my header search path. What else
> do I need to configure?

I'm not a "C" hacker, but that's failing at the linking stage, not the
compiling stage. Are you missing the right lib to go with your headers?


-- 
  Richard Huxton
  Archonet Ltd

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

[GENERAL] c function - undefined symbols

[Steffn]

I already asked this question on the psql-novice list, but didn't get 
any reply. I am aware that this is probably a basic question and hope 
someone here can point me in the right direction!


Hi!

I am currently trying my first steps in writing my own functions in C. I 
read through the documentation and tried the most simple examples as 
shown in . Sadly 
this was already the point where I stumbled. I luckily compiled and 
tested the add_one integer variant. But as soon as I added the 
add_one_float8 I couldn't link no more. My linker dies with.


Undefined symbols:
"_Float8GetDatum", referenced from:
   _add_one_float8 in foo.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Following the documentation I only added 
"/Library/PostgreSQL/8.3/include/**" to my header search path. What else 
do I need to configure?


Thanks for your help!
steffn

Environment used:
OS X 10.5.5
XCode 3.1
Postgres 8.3.4

Same behavior under WinXP and Ubuntu. So IMHO I am clearly missing a 
point on configuring my build environment.


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

[GENERAL] PostgreSQL and eval()

[Mark Morgan Lloyd]

I had to do some repeated ad-hoc queries yesterday for a report that was 
needed in a hurry, and found myself doing repeated editing of an 
embedded function name.


If one wants to store the name of a function in a table for subsequent 
use in customised queries is the only way to use it by coding an eval() 
function using PL/pgSQL's execute?


I appreciate that I could create a function on the fly as a wrapper of 
the one that was to be called, but again that takes manual editing.


Alternatively I appreciate that I could use PL/pgSQL but that would 
assume that if I sent the sequence of operations to somebody else that 
he also had it compiled into his server.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

--
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] equal and like

[Schwéger Gábor]

Thank You.
After reindex it's working fine.

Gabor

On Ked, December 9, 2008 23:06, Bill Moran wrote:
> In response to "Schwéger Gábor" <[EMAIL PROTECTED]>:
>>
>> This is my first post to this list.
>> Our database moved to a larger partition.
>> And now I have a problem with a select query:
>> db=# SELECT id, login FROM u WHERE login LIKE 'bellamarth';
>>id   |login
>> +-
>>  173002 | bellamarth
>> (1 row)
>>
>> db=# SELECT id, login FROM u WHERE login = 'bellamarth';
>>  id | login
>> +---
>> (0 rows)
>>
>> The type of login is text.
>> What is the problem with the equal sign?
>> psql server version: 8.2.11
>>
>> Could you help me?
>
> Just a guess, but does the problem go away if you do
> REINDEX table u;
>
> --
> Bill Moran
> Collaborative Fusion Inc.
> http://people.collaborativefusion.com/~wmoran/
>
> [EMAIL PROTECTED]
> Phone: 412-422-3463x4023
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>



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

[GENERAL] quit milis

[Tonny Sapri]

I want quit milis postgresql.

thank you.


  Mulai chatting dengan teman di Yahoo! Pingbox baru sekarang!! Membuat 
tempat chat pribadi di blog Anda sekarang sangatlah mudah. 
http://id.messenger.yahoo.com/pingbox/

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