PostgreSQL on Solaris future

   As I know Solaris packages were maintained by Sun but I'm not sure
about the future after recent buildfarm problems.
   Does the community plans to maintain Solaris packages or it will be
Oracle dependent?
   Are there any alternative packages for Solaris I'm not aware of
(except building from sources of course)?

--

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

Re: PostgreSQL on Solaris future

wstrzalka <wstrzalka <at> gmail.com> writes:
>    As I know Solaris packages were maintained by Sun but I'm not sure
> about the future after recent buildfarm problems.
>    Does the community plans to maintain Solaris packages or it will be
> Oracle dependent?

When and if Bjorn stops building packages, we'll look for a replacement.
Presumably somebody will be willing to do it, unless Oracle has managed
to drive open source users away from Solaris completely by then.

			regards, tom lane

--

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

Re: PostgreSQL on Solaris future

Re: PostgreSQL on Solaris future

On Sun, Aug 1, 2010 at 8:12 AM, Lou Picciano <loupicciano <at> comcast.net> wrote:
> I'd be happy to offer Solaris build services, as well, should this become an
> issue - for as long as we can maintain our loyalty to Solaris.  We are
> dependent now on the same set of variables to which Tom alludes.  I think
> the inference must be: That a company wielding the resources of an Oracle
> could have long ago made a clear commitment to its de facto (if inherited)
> opensource community, if such a commitment had been its intention.
> We're now all in limbo on this...
> And don't forget the hard work of Steve Christensen; Steve continues to
> offer builds of PostgreSQL - and loads of other immensely useful packages -
> on SunFreeware, even in the face of tenuous support from Sun.  Thank You,
> Steve!

Last company I worked at we used Oracle and the instant client had an
RPM version for RHEL4.  It was something like 3 versions behind.
Oracle's answer to my queries to have a new version made?  "Why don't
you make it?"

Wow, that's some support there...  I have no great hopes for Sun under
Oracle management.

--

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

Re: PostgreSQL on Solaris future

Scott Marlowe wrote:
> Oracle's answer to my queries to have a new version made?  "Why don't
> you make it?"
>   

While I'm sure someone will step in to help out if this gets botched on 
Oracle's side, I know if I were running any production Solaris installs 
that counted on packaged builds of PostgreSQL I'd be leaning how to do 
that myself fast--before they just remove resources related to it 
without warning anyone (again).

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg <at> 2ndQuadrant.com   www.2ndQuadrant.us

--

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

Re: [GENERAL] Pglesslog issue

Hi,

pglesslog needs makefile, header files and .o files of PostgreSQL itself.

To build pglesslog, you need PostgreSQL source code as well.    Please
unpack the source at "contrib" directory of PostgreSQL 8.3 source.
Run ./configure and make for PostgreSQL 8.3 first (I hope you already
did them) and then "make" pglesslog.

I hope they work fine.

Regards;
---
Koichi Suzuki

2010/7/29 raghu ram <raghuchennuru <at> gmail.com>:
> Hi,
> I was installed the Postgresql 8.3 and trying the use the
> "pg_lesslog_1.4.1_pg83" to reduce the size of WAL file when the WAL file is
> archived.
> 1. Download the "pg_lesslog_1.4.1_pg83.tar.gz" file from pgfoundry.
> 2. unpacked the pglesslog source.
> 3. trying to run the "make"...facing below issue::
> edbs-MacBook-4:pg_lesslog_1.4.1_pg83 root# make
> make -f Makefile.pg_compresslog all
> Makefile.pg_compresslog:21: ../../src/Makefile.global: No such file or
> directory
> Makefile.pg_compresslog:22: /contrib/contrib-global.mk: No such file or
> directory
> make[1]: *** No rule to make target `/contrib/contrib-global.mk'.  Stop.
> make: *** [all] Error 2
>
> could you please guide me the installation steps...
>
> Regards
> Raghu
>

-- 
------
Koichi Suzuki

--

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

Re: Statistics Collector not collecting server activities

>> Does stats collector process need any other special
>> resource/privilege/operations/port to start?

> If I understand correctly, it uses UDP.  I don't think PostgreSQL
> uses UDP outside of that.

Still I'm not able to resolve/fix this statistics collector (not
starting/working) in one of our customer production server and because of
this autovacuum daemon is also not able to perform its job effectively,
thereby it is indirectly impacting on the disk space growth.

There are no anti-virus program running, no SE-Linux, etc.  I've pasted
below my "/etc/sysconfig/iptables" to reveal my firewall rules.

Does PostgreSQL establish working UDP sockets on some specific defined port
or it chooses the port randomly?

Looking at experts guidance to resolve my issue.

=================================
[root <at> dbserver ~]# more /etc/sysconfig/iptables
# Generated by iptables-save v1.3.5 on Mon Sep 14 20:04:30 2009
*nat
:PREROUTING ACCEPT [10934:1556118]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [111392:6686084]
-A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 5050
-A POSTROUTING -j MASQUERADE
-A OUTPUT -d 192.168.0.200 -p tcp -m tcp --dport 80 -j DNAT --to-destination
192.168.0.200:5050
-A OUTPUT -d 127.0.0.1 -p tcp -m tcp --dport 80 -j DNAT --to-destination
127.0.0.1:5050
COMMIT
# Completed on Mon Sep 14 20:04:30 2009
# Generated by iptables-save v1.3.5 on Mon Sep 14 20:04:30 2009
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -j ACCEPT
-A FORWARD -j ACCEPT
-A OUTPUT -j ACCEPT
COMMIT
# Completed on Mon Sep 14 20:04:30 2009
=================================

--

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

performance problems on Delete

Hi alls,

we have a performance issue on deleting data from a table.

the delete  is on the index key so should be very fast but the table 
have 13 contraints of type foreign keys and the slowness seems due to 
all the works done with the constraint.
Trying to drop the constraint and execute the delete the result is 
immediate.

Is there a way to speed up this type of operations??

Any suggestion higly appreciated

Silvio

---

Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e
contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo
diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html
Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo
assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html
L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo
messaggi estranei all'attività lavorativa o contrari a norme.
--

--

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

Re: performance problems on Delete

Silvio Brandani  wrote:

> we have a performance issue on deleting data from a table.
>
> the delete is on the index key so should be very fast but the table
> have 13 contraints of type foreign keys and the slowness seems due
> to all the works done with the constraint.
> Trying to drop the constraint and execute the delete the result is
> immediate.

The usual reason for this is that you don't have indexes on the
referencing columns, so to check whether the delete is OK it has to
scan the related tables.  Think about what rows need to be checked to
determine whether the delete is allowed and index the columns which
will allow fast access to them.

-Kevin

--

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

Re: Statistics Collector not collecting server activities

"Gnanakumar" <gnanam <at> zoniac.com> writes:
> Does PostgreSQL establish working UDP sockets on some specific defined port
> or it chooses the port randomly?

The stats collector socket is opened on whatever port bind() chooses to
assign.

			regards, tom lane

--

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