Re: linux standard layout

On Mon, Mar 8, 2010 at 10:31 PM, Ben Kim wrote:
> Dear list,
>
> I have about 20 postgresql databases, about 3-4 GB in total.
>
> We are moving them from Solaris/SPARC to a linux based virtual machine.
>
> I don't like the VMWare environment, but it's not my choice, and assuming
> the cpu load is ok, will there be any benefits if I put each database on
> separate partitions, vs. simply using the one data directory?

What reasoning was given for putting your database server in a
virutalizeed environment?

> Also, how is using standard rpm, with its standard layout (/var/lib/pgsql,
> /usr/lib/pgsql, ...), generally regarded? ( vs. compiling everything ?) Does
> anyone think using the rpm is unprofessional or something that only
> beginners will do?
>
> I have someone who opposes the use of standard rpms (even yums) for this
> reason. I thought I'd check out how it is received professionally.

Sounds like a religious argument. I mostly used packages, unless I
can't. (i.e. two different versions on RH at the same time)

> I ask the question because sometimes I feel uneasy mixing rpms and source
> compilation.

Worry more about accidentally having two different versions of the
same lib linked to various executables. It's easy to do with things
like mysql and apache and php and zlib.

> If I compile something from the source, sometimes I see a boundary condition
> - like, if I already have DBI from a standard rpm, it expects postgresql
> library at a certain location - making me wonder whether I should remove the
> DBI rpm and compile it also from the source, or whether I should use
> standard rpms for postgresql as well. (DBI may not be a good example.)
>
> In general I didn't have any problems yet with standard rpms and I can make
> the rpms work if there's a problem, but I may be missing something.

My advice:

put postgresql on its own, powerful, reliable non-virtualized server.
Demand that the person who wants to virtualize it justify their
decision with more than hand-wavy methodologies. Use packages unless
you're on RPM and you need > 1 version of pgsql. Even if you need to
compile some tarball against the packages, it's still easier to
maintain than to install it all from source.

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

Re: linux standard layout

A word of caution for packages/rpms. Beware of admins who apply ALL update=
s that are available to a system. I have seen this happen taking Postgres =
from say vresion 8.3.X to 8.4.X, which as you can imagine, caused problems.


________________________________
From: pgsql-admin-owner@postgresql.org [pgsql-admin-owner@postgresql.org] O=
n Behalf Of Scott Marlowe [scott.marlowe@gmail.com]
Sent: Monday, March 08, 2010 11:48 PM
To: Ben Kim
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] linux standard layout

On Mon, Mar 8, 2010 at 10:31 PM, Ben Kim wrote:
> Dear list,
>
> I have about 20 postgresql databases, about 3-4 GB in total.
>
> We are moving them from Solaris/SPARC to a linux based virtual machine.
>
> I don't like the VMWare environment, but it's not my choice, and assuming
> the cpu load is ok, will there be any benefits if I put each database on
> separate partitions, vs. simply using the one data directory?

What reasoning was given for putting your database server in a
virutalizeed environment?

> Also, how is using standard rpm, with its standard layout (/var/lib/pgsql,
> /usr/lib/pgsql, ...), generally regarded? ( vs. compiling everything ?) D=
oes
> anyone think using the rpm is unprofessional or something that only
> beginners will do?
>
> I have someone who opposes the use of standard rpms (even yums) for this
> reason. I thought I'd check out how it is received professionally.

Sounds like a religious argument. I mostly used packages, unless I
can't. (i.e. two different versions on RH at the same time)

> I ask the question because sometimes I feel uneasy mixing rpms and source
> compilation.

Worry more about accidentally having two different versions of the
same lib linked to various executables. It's easy to do with things
like mysql and apache and php and zlib.

> If I compile something from the source, sometimes I see a boundary condit=
ion
> - like, if I already have DBI from a standard rpm, it expects postgresql
> library at a certain location - making me wonder whether I should remove =
the
> DBI rpm and compile it also from the source, or whether I should use
> standard rpms for postgresql as well. (DBI may not be a good example.)
>
> In general I didn't have any problems yet with standard rpms and I can ma=
ke
> the rpms work if there's a problem, but I may be missing something.

My advice:

put postgresql on its own, powerful, reliable non-virtualized server.
Demand that the person who wants to virtualize it justify their
decision with more than hand-wavy methodologies. Use packages unless
you're on RPM and you need > 1 version of pgsql. Even if you need to
compile some tarball against the packages, it's still easier to
maintain than to install it all from source.

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

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

Re: linux standard layout

Scott Marlowe wrote:
> On Mon, Mar 8, 2010 at 10:31 PM, Ben Kim wrote:
>> I have someone who opposes the use of standard rpms (even yums) for this
>> reason. I thought I'd check out how it is received professionally.
>
> Sounds like a religious argument. I mostly used packages, unless I
> can't. (i.e. two different versions on RH at the same time)

Agreed. This is particularly the case once one starts thinking about
security updates and so on - my experience is that hand-rolling from
source tends to result in patching lagging far behind after a while.

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

Re: linux standard layout

Thanks all.

I cannot change the decision on vmware or layout, but it's great to know
that the rpm way is a valid one.

I appreciate all inputs.



Regards,

Ben Kim


On Mon, 8 Mar 2010, Scott Marlowe wrote:

> On Mon, Mar 8, 2010 at 10:31 PM, Ben Kim wrote:
>> Dear list,
>>
>> I have about 20 postgresql databases, about 3-4 GB in total.
>>
>> We are moving them from Solaris/SPARC to a linux based virtual machine.
>>
>> I don't like the VMWare environment, but it's not my choice, and assuming
>> the cpu load is ok, will there be any benefits if I put each database on
>> separate partitions, vs. simply using the one data directory?
>
> What reasoning was given for putting your database server in a
> virutalizeed environment?
>
>> Also, how is using standard rpm, with its standard layout (/var/lib/pgsql,
>> /usr/lib/pgsql, ...), generally regarded? ( vs. compiling everything ?) Does
>> anyone think using the rpm is unprofessional or something that only
>> beginners will do?
>>
>> I have someone who opposes the use of standard rpms (even yums) for this
>> reason. I thought I'd check out how it is received professionally.
>
> Sounds like a religious argument. I mostly used packages, unless I
> can't. (i.e. two different versions on RH at the same time)
>
>> I ask the question because sometimes I feel uneasy mixing rpms and source
>> compilation.
>
> Worry more about accidentally having two different versions of the
> same lib linked to various executables. It's easy to do with things
> like mysql and apache and php and zlib.
>
>> If I compile something from the source, sometimes I see a boundary condition
>> - like, if I already have DBI from a standard rpm, it expects postgresql
>> library at a certain location - making me wonder whether I should remove the
>> DBI rpm and compile it also from the source, or whether I should use
>> standard rpms for postgresql as well. (DBI may not be a good example.)
>>
>> In general I didn't have any problems yet with standard rpms and I can make
>> the rpms work if there's a problem, but I may be missing something.
>
> My advice:
>
> put postgresql on its own, powerful, reliable non-virtualized server.
> Demand that the person who wants to virtualize it justify their
> decision with more than hand-wavy methodologies. Use packages unless
> you're on RPM and you need > 1 version of pgsql. Even if you need to
> compile some tarball against the packages, it's still easier to
> maintain than to install it all from source.
>

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

Re: linux standard layout

Hi Ben,

If you must use a VMware server for your databases, please run
some "pull-the-power-plug" tests on your system to ensure that
your data integrity is maintained. Virtual machines can sometimes
cache filesystem updates in the name of performance with disasterous
consequences to your filesystems and databases.

Cheers,
Ken

On Tue, Mar 09, 2010 at 08:18:21AM -0600, Ben Kim wrote:
>
> Thanks all.
>
> I cannot change the decision on vmware or layout, but it's great to know
> that the rpm way is a valid one.
>
> I appreciate all inputs.
>
>
>
> Regards,
>
> Ben Kim
>
>
> On Mon, 8 Mar 2010, Scott Marlowe wrote:
>
>> On Mon, Mar 8, 2010 at 10:31 PM, Ben Kim wrote:
>>> Dear list,
>>>
>>> I have about 20 postgresql databases, about 3-4 GB in total.
>>>
>>> We are moving them from Solaris/SPARC to a linux based virtual machine.
>>>
>>> I don't like the VMWare environment, but it's not my choice, and assuming
>>> the cpu load is ok, will there be any benefits if I put each database on
>>> separate partitions, vs. simply using the one data directory?
>>
>> What reasoning was given for putting your database server in a
>> virutalizeed environment?
>>
>>> Also, how is using standard rpm, with its standard layout
>>> (/var/lib/pgsql,
>>> /usr/lib/pgsql, ...), generally regarded? ( vs. compiling everything ?)
>>> Does
>>> anyone think using the rpm is unprofessional or something that only
>>> beginners will do?
>>>
>>> I have someone who opposes the use of standard rpms (even yums) for this
>>> reason. I thought I'd check out how it is received professionally.
>>
>> Sounds like a religious argument. I mostly used packages, unless I
>> can't. (i.e. two different versions on RH at the same time)
>>
>>> I ask the question because sometimes I feel uneasy mixing rpms and source
>>> compilation.
>>
>> Worry more about accidentally having two different versions of the
>> same lib linked to various executables. It's easy to do with things
>> like mysql and apache and php and zlib.
>>
>>> If I compile something from the source, sometimes I see a boundary
>>> condition
>>> - like, if I already have DBI from a standard rpm, it expects postgresql
>>> library at a certain location - making me wonder whether I should remove
>>> the
>>> DBI rpm and compile it also from the source, or whether I should use
>>> standard rpms for postgresql as well. (DBI may not be a good example.)
>>>
>>> In general I didn't have any problems yet with standard rpms and I can
>>> make
>>> the rpms work if there's a problem, but I may be missing something.
>>
>> My advice:
>>
>> put postgresql on its own, powerful, reliable non-virtualized server.
>> Demand that the person who wants to virtualize it justify their
>> decision with more than hand-wavy methodologies. Use packages unless
>> you're on RPM and you need > 1 version of pgsql. Even if you need to
>> compile some tarball against the packages, it's still easier to
>> maintain than to install it all from source.
>>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
>

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

Re: linux standard layout

* Rodger Donaldson wrote:

> Agreed. This is particularly the case once one starts thinking about
> security updates and so on - my experience is that hand-rolling from
> source tends to result in patching lagging far behind after a while.

Depends on whether you have an proper QM and build machinery in the
back. I'm often work in embedded or specific appliance environments
and have developed my several tools which make this easier.
(feel free to contact me personally if you're interested)


cu
--
------------------------------------------------------------ ---------
Enrico Weigelt == metux IT service - http://www.metux.de/
------------------------------------------------------------ ---------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
------------------------------------------------------------ ---------

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

postgres crashes - "not reattach to shared memory "

Hi=20

Postgres crashes with -

PG "FATAL: could not reattach to shared memory (key=3D5432001, addr=3D0210=
0000): Invalid argument.

The version is 8.2.4, the platform is win32

Does someone know the reason/workaround ?=20

Thanks,=20
Yuval Sofer
BMC Software
CTM&D Business Unit
DBA Team
972-52-4286-282
yuval_sofer@bmc.com

-----Original Message-----
From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql=
..org] On Behalf Of Enrico Weigelt
Sent: Saturday, May 01, 2010 7:51 PM
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] linux standard layout

* Rodger Donaldson wrote:

> Agreed. This is particularly the case once one starts thinking about=20
> security updates and so on - my experience is that hand-rolling from=20
> source tends to result in patching lagging far behind after a while.

Depends on whether you have an proper QM and build machinery in the=20
back. I'm often work in embedded or specific appliance environments=20
and have developed my several tools which make this easier.=20
(feel free to contact me personally if you're interested)


cu
--=20
------------------------------------------------------------ ---------
Enrico Weigelt == metux IT service - http://www.metux.de/
------------------------------------------------------------ ---------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
------------------------------------------------------------ ---------

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


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