Dear community
I write as I am not sure if the issue I report is caused by Debian.
On 23-10-10 we upgraded our Debian bullseye servers to version 11.8. Along came
a new version of postgresql-12-cron:
postgresql-12-cron 1.6.0-1.pgdg110+1
pg_cron executes jobs one day too early since
Hi Testler,
On Wed, Aug 24, 2022 at 07:54:03AM +0300, Testler Test wrote:
> > Let's see the output of "cat /proc/mdstat".
>
> The raid status is as follows. No problem appears.
>
> # cat /proc/mdstat
> Personalities : [raid1]
> md2 : active raid1 sdb3[1] sda3[0]
> 232623424 blocks super 1.
On Sun, Sep 26, 2021 at 12:10:39AM +0200, Pierre Couderc wrote:
>
> On 9/25/21 3:46 PM, Henning Follmann wrote:
> >
> > have you tried to use the odbc lib from unixodbc instead of
> > libiodbc?
> >
>
> I think you are right on many other points...
>
> But particularly on this one !
>
> I did
On 9/25/21 3:46 PM, Henning Follmann wrote:
have you tried to use the odbc lib from unixodbc instead of
libiodbc?
I think you are right on many other points...
But particularly on this one !
I did remove libodbc2-dev and install unixodbc-dev and now it is OK...!!
Wow !
Thank you very mu
On Sat, Sep 25, 2021 at 09:16:33AM +0200, Pierre Couderc wrote:
>
> On 9/24/21 5:31 PM, Henning Follmann wrote:
> >
> > and I see you do not do any error checking.
> > This would be a first step to find out where it fails.
> >
> > I added some code...
> >
>
> You hare fully right, I have corre
On 9/24/21 5:31 PM, Henning Follmann wrote:
and I see you do not do any error checking.
This would be a first step to find out where it fails.
I added some code...
You hare fully right, I have corrected, but I have the same result and
no more idea.. :
nous@pcouderc:~/projets//build$
On Thu, Sep 23, 2021 at 11:55:00PM +0200, Pierre Couderc wrote:
> Thenk you, Henning, thank you Gregory .
>
> On 9/23/21 5:49 PM, Gregory Seidman wrote:
> > On Thu, Sep 23, 2021 at 08:18:45AM -0400, Henning Follmann wrote:
> > >
> > I don't see where you ask fo
Thenk you, Henning, thank you Gregory .
On 9/23/21 5:49 PM, Gregory Seidman wrote:
On Thu, Sep 23, 2021 at 08:18:45AM -0400, Henning Follmann wrote:
I don't see where you ask for the PostgreSQL ODBC connection in particular.
Maybe I'm the one missing something?
You are right, I am
driver, sizeof(driver),
> > > > &driver_ret,
> > > > attr, sizeof(attr),
> > > > &attr_ret))) {
> > > > direction = SQL_FETCH_NEXT;
> > > > printf("%s - %s\n&qu
is written in c (c++ in fact but I have simplified).
That is not c code. This does not compile.
Provide a minimum example which compiles, at least.
> >Did you compile it? And if so, how?
> Yes, with default tools (gcc under debian bulllseye linked with libodbc)
Are you kidding me?
e it? And if so, how?
Yes, with default tools (gcc under debian bulllseye linked with libodbc)
You installed odbcunix I assume.
How did you configure it?
Correctly.
What is the output of "odbcinst -q -d"?
Correct :
[PostgreSQL ANSI]
[PostgreSQL Unicode]
What did you expect?
On Wed, Sep 22, 2021 at 11:07:28AM +0200, Pierre Couderc wrote:
> It is here I see it/them with:
>
> odbcinst -q -d
>
> but not with :
>
> SQLHENV env;
> SQLCHAR driver[256];
> SQLCHAR attr[256];
> SQLSMALLINT driver_ret;
> SQLSMALLINT attr_ret;
> SQLUSMALLINT direction;
> SQLRETUR
It is here I see it/them with:
odbcinst -q -d
but not with :
SQLHENV env;
SQLCHAR driver[256];
SQLCHAR attr[256];
SQLSMALLINT driver_ret;
SQLSMALLINT attr_ret;
SQLUSMALLINT direction;
SQLRETURN ret;
SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &env);
SQLSetEnvAttr(env, SQL_
Solved: changing the ownership of the custom log in conf.d solved the
problem.
Regards
Johann
On Tue, 3 Dec 2019 at 17:14, Johann Spies wrote:
> We have upgraded two servers by installing postgresql(pgpd) 12. Both
> servers are running Debian Stable.
>
> On the problem se
We have upgraded two servers by installing postgresql(pgpd) 12. Both
servers are running Debian Stable.
On the problem server we have:
pg_lsclusters
Ver Cluster Port Status OwnerData directory Log file
11 main5432 online postgres /var/lib/postgresql/11/main
/var/log
On Di, Nov 05, 2019 at 10:42:28 +0100, Kamil Jońca wrote:
I migrate databases, and during last few days I have had 2 server
crashes.
I have similiar signal 11 crashes after the upgrade (pg_upgradecluster).
Maybe you should keep your hands from version 12.
Shade and sweet water!
Steph
deloptes writes:
> Kamil Jońca wrote:
>
[...]
>
> also perhaps consider contacting application maintenance
I did. Issued bug at postgres.
>
> why do you write here? Isn't there a postgres mailing list?
To warn someone before premature upgrading :-P
KJ
--
http://wolnelektury.pl/wesprzyj/ter
Kamil Jońca wrote:
> Today was another crash.
> Another piece of a puzzle: There is (unlogged) table with 70M+
> rows. After crash this table is empty (but table itself exists.)
read documentation
fine tune postgres
be happy
also perhaps consider contacting application maintenance
why do you wr
kjo...@poczta.onet.pl (Kamil Jońca) writes:
> It is home PC box with debian sid.
> Recently my postgres was upgraded from version 11 to 12.
> I migrate databases, and during last few days I have had 2 server
> crashes.
> Crashes were during different statements. And after crash these
> statements
It is home PC box with debian sid.
Recently my postgres was upgraded from version 11 to 12.
I migrate databases, and during last few days I have had 2 server
crashes.
Crashes were during different statements. And after crash these
statements executed successfully.
In log I have:
=
Hi Phil,
> Thanks Richard, that looks like the best solution. They even
> have a mailing list.
I have have really enjoyed using docker for such issues - mix&match
useland as you like it - without interfering with you "main"
distribution and without any performance overhead.
Br, Clemens
Br, Cle
Richard Hector wrote:
Another option is to switch to using the pgdg repo for 9.6:
https://wiki.postgresql.org/wiki/Apt
Thanks Richard, that looks like the best solution. They even
have a mailing list.
Cheers, Phil.
Phil Endecott [2019-07-08T22:24:17+01] wrote:
> Indeed, not upgrading to Buster is a possibility. Also upgrading
> PostgreSQL to version 11 is a possibility. I think I understand the
> issues with each of those options, but I don't have a good
> understanding of the issues with
ossibility. Also upgrading PostgreSQL
> to version 11 is a possibility. I think I understand the issues with each
> of those options, but I don't have a good understanding of the issues with
> trying to keep pg-9.6 on Buster.
You can test that yourself as follows:
1. debootstrap buster in an
On 9/07/19 9:24 AM, Phil Endecott wrote:
> Andrei POPESCU wrote:
>> On Lu, 08 iul 19, 20:02:36, Phil Endecott wrote:
>>> Dear Experts,
>>>
>>> Does anyone have any advice about the possibility of upgrading
>>> systems from Stretch to Buster, but
Andrei POPESCU wrote:
On Lu, 08 iul 19, 20:02:36, Phil Endecott wrote:
Dear Experts,
Does anyone have any advice about the possibility of upgrading
systems from Stretch to Buster, but keeping Postgresql-9.6 for
the time being?
Is upgrading to buster a necessity? Stretch will be supported by
On Lu, 08 iul 19, 20:02:36, Phil Endecott wrote:
> Dear Experts,
>
> Does anyone have any advice about the possibility of upgrading
> systems from Stretch to Buster, but keeping Postgresql-9.6 for
> the time being?
Is upgrading to buster a necessity? Stretch will be supported by
Phil Endecott:
>
> Does anyone have any advice about the possibility of upgrading
> systems from Stretch to Buster, but keeping Postgresql-9.6 for
> the time being?
With previous Debian releases you always had to migrate your cluster to
the new Postgres version manually. The new
Dear Experts,
Does anyone have any advice about the possibility of upgrading
systems from Stretch to Buster, but keeping Postgresql-9.6 for
the time being?
This is for a couple of cloud servers that are running Postgresql
with streaming replication from one to the other. I guess my
questions
n'
> > respectively ?
>
> default cluster name for both clusters should be "main".
yes I got there eventually
You could also try reading the README.Debian.gz file in
/usr/share/doc/postgresql-*/
In stretch, this is /usr/share/doc/postgresql-9.6/README.Debian.gz
and it co
ctively ?
> >
> > default cluster name for both clusters should be "main".
> yes I got there eventually
You could also try reading the README.Debian.gz file in
/usr/share/doc/postgresql-*/
In stretch, this is /usr/share/doc/postgresql-9.6/README.Debian.gz
and it contains the exact steps needed to upgrade from 9.1 to 9.4.
Just replace the version numbers with whatever you have.
decluster oldversion name [newdatadir]" ?
OK from the conf files assume cluster-name is '10/main' and '11/main'
respectively ?
default cluster name for both clusters should be "main".
yes I got there eventually
so is
"pg_ctlcluster 11 main stop"
"pg_
On 11/11/18 1:00 PM, mick crane wrote:
>
>> but how to find out what is this "cluster-name" for pg_ctlcluster,
>> pg_dropcluster and pg_upgradecluster ?
>>
>> "pg_dropcluster [--stop] cluster-version cluster-name"
>>
>> "pg_upgradecluster oldversion name [newdatadir]" ?
>>
>
> OK from the conf
but how to find out what is this "cluster-name" for pg_ctlcluster,
pg_dropcluster and pg_upgradecluster ?
"pg_dropcluster [--stop] cluster-version cluster-name"
"pg_upgradecluster oldversion name [newdatadir]" ?
OK from the conf files assume cluster-name is '10/main' and '11/main'
respect
On 2018-11-11 10:00, Georgi Naplatanov wrote:
On 11/11/18 11:52 AM, mick crane wrote:
hello
this last upgrade buster upgraded postgresql-10 to 11
I'm not sure what uses postgresql.
during upgrade think there was a message about pg_upgradecluster or I
may have read that in manpage.
:~# p
On 11/11/18 11:52 AM, mick crane wrote:
> hello
>
> this last upgrade buster upgraded postgresql-10 to 11
> I'm not sure what uses postgresql.
> during upgrade think there was a message about pg_upgradecluster or I
> may have read that in manpage.
>
> :~# ps -ef |
hello
this last upgrade buster upgraded postgresql-10 to 11
I'm not sure what uses postgresql.
during upgrade think there was a message about pg_upgradecluster or I
may have read that in manpage.
:~# ps -ef | grep postgre
postgres 599 1 0 09:36 ?00:00:00
/usr/lib/postgres
I've had good experiences running RedHat Cluster Services (corosync,
pacemaker) for the GFS2 filesystem
and databases on top of it. It performed and recovered well. However
that was not with Postgresql. Most of
my database work is with Oracle and mysql, but I have found Postgres
separately
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 17, 2018 at 09:01:45AM +0300, Veli Cakmak wrote:
> Hello dear liste,
>
> I have really important database and it should not lost any data. Is it
> safe Postgresql, DRBD, Pacemaker, Corosyn structure. ?
PostgreSQL has its own
Hello dear liste,
I have really important database and it should not lost any data. Is it
safe Postgresql, DRBD, Pacemaker, Corosyn structure. ?
Thanks, Best.
When I upgraded from postgresql 9.6 to 10, the postgres server failed to
start. Error message: 'max_wal_senders must be less than
max_connections'. The configuration file
/etc/postgresql/10/main/postgresql.conf has the line
#max_wal_senders = 0
suggesting that 0 is a default val
Tried to solve it by looking at the configuration script but with no
success. I gave up and, after securing my database and configuration
file, I did an apt-get purge of all postgresql. Then I re-installed it
again.
Unfortunately the purge had left the /var/lib/postgres/9.6 and this
The script stops at: invoke-rc.d postgresql start $VERSION #
systemd: argument ignored, starts all versions
This is the last step in the configure_version() function. Is this
really necessary when you use systemctl? Can I comment it safely just to
finish the configuration?
The server
The dpkg --configure -a gives the same result. I will look into the
scripts that you included and try them since I am on jessie. I will go
to stretch as soon as this problem is solved. Do not think that it is
not a good idea to do this now.
BTW Postgresql 9.6 is running well.
Marco
Op 23
On Wed, Aug 23, 2017 at 11:28:14AM -0400, Cindy-Sue Causey wrote:
> On 8/23/17, Marco DE BOOIJ wrote:
> > root:~# dpkg --configure postgresql-9.6
> > Setting up postgresql-9.6 (9.6.4-1.pgdg80+1) ...
> > dpkg: error processing package postgresql-9.6 (--configure):
> >
On 8/23/17, Marco DE BOOIJ wrote:
> I recently did an apt-get upgrade and it did not want to install a newer
> version of postgresql-contrib-9.6. I searched the web and tried to
> reinstall it (with remove and install because I did not want to loose my
> database) but did did not solv
I recently did an apt-get upgrade and it did not want to install a newer
version of postgresql-contrib-9.6. I searched the web and tried to
reinstall it (with remove and install because I did not want to loose my
database) but did did not solve it. Before I will try to purge and
install it I
On Sun, 16 Jul 2017, Erwan David wrote:
> Le 07/16/17 à 18:32, Don Armstrong a écrit :
> > If you don't care about this in your log, then you can either filter it,
> > or comment out pam_unix in /etc/pam.d/common-session-noninteractive.
>
> Commenting it will remove authentication methods ?
No. Th
On Sun, Jul 16, 2017 at 12:32:22PM +0200, Václav Ovsík wrote:
>...
> With su is /var/log/auth.log flooded too, I didn't noticed
> before :-/ (logcheck was filtering this). So the last chance is probably
> the utility setpriv mentioned in the runuser manpage. Unfortunately the
> utility is in the o
Le 07/16/17 à 18:32, Don Armstrong a écrit :
> On Sun, 16 Jul 2017, Václav Ovsík wrote:
>> On Sun, Jul 16, 2017 at 12:01:56PM +0200, Václav Ovsík wrote:
>>> OMG, I don't looked into /var/log/auth.log :(
>>>
>>> Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for
>>> user pos
On Sun, 16 Jul 2017, Václav Ovsík wrote:
> On Sun, Jul 16, 2017 at 12:01:56PM +0200, Václav Ovsík wrote:
> > OMG, I don't looked into /var/log/auth.log :(
> >
> > Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for
> > user postgres
> > Jul 16 11:57:57 rt2 runuser: pam_unix
On Sun, Jul 16, 2017 at 12:01:56PM +0200, Václav Ovsík wrote:
> OMG, I don't looked into /var/log/auth.log :(
>
> Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for
> user postgres
> Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session opened for
> user postgre
On Sun, Jul 16, 2017 at 12:32:22AM +0200, Václav Ovsík wrote:
> Bingo! This helped runuser instead of su.
>
> su - $DBUSER -c [...]
> to
> runuser -c [...] $DBUSER
OMG, I don't looked into /var/log/auth.log :(
Jul 16 11:57:57 rt2 runuser: pam_unix(runuser:session): session closed for user
On Fri, Jul 14, 2017 at 05:07:22PM -0500, Don Armstrong wrote:
>...
> This plugin is horribly designed, and runs su - $DBUSER -c [...] for its
> functioning.
>
> It should instead just su $DBUSER -c [...]; or better yet, not actually
> su to the database user, and instead run as a user which only
On Fri, 14 Jul 2017, Jonathan de Boyne Pollard wrote:
> Don Armstrong:
> > Something like this (untested)
>
> When you do test it (-: you will discover the rather drastic
> side-effect on all of the repeated SSH logins of suddenly running them
> in a completely different control group with comple
Am 15.07.2017 um 00:07 schrieb Don Armstrong:
> This plugin is horribly designed, and runs su - $DBUSER -c [...] for its
> functioning.
Indeed.
> It should instead just su $DBUSER -c [...]; or better yet, not actually
> su to the database user, and instead run as a user which only has the
> abili
On Sat, 08 Jul 2017, Václav Ovsík wrote:
> On Fri, Jul 07, 2017 at 10:34:20PM +0200, Michael Biebl wrote:
> >...
> > You create 19 PAM sessions for the postgres user per minute. What
> > exactly are you doing here?
>
> This morning refreshed my mind :)
> I completely forget about monitoring of th
Don Armstrong:
> Something like this (untested)
When you do test it (-: you will discover the rather drastic side-effect on all
of the repeated SSH logins of suddenly running them in a completely different
control group with completely different settings. The systemd PAM hook does
quite a lot of
On Fri, 14 Jul 2017, Jonathan de Boyne Pollard wrote:
> There's no way to actually turn the per-user instance off, for
> accounts that should *never* have per-user service managers.
Something like this (untested) in /etc/pam/common-session would do the
trick:
session [success=2 default=ignore] pa
Václav Ovsík:
> How I should get rid of this session management the right way?
I have seen this systemd problem myself.
What is happening is that every time something SSHes in as user postgres,
systemd-logind is starting up a per-user instance of systemd along with with a
whole bunch of per-user
On Fri, Jul 07, 2017 at 10:34:20PM +0200, Michael Biebl wrote:
>...
> You create 19 PAM sessions for the postgres user per minute. What
> exactly are you doing here?
This morning refreshed my mind :)
I completely forget about monitoring of the host yesterday.
There was installed plugin for Postgre
Am 07.07.2017 um 16:03 schrieb Václav Ovsík:
> Jul 7 15:42:35 rt2 systemd[1]: Started Session c4504 of user postgres.
> Jul 7 15:42:35 rt2 systemd[1]: Started Session c4505 of user postgres.
> Jul 7 15:42:35 rt2 systemd[1]: Started Session c4506 of user postgres.
> Jul 7 15:42:35 rt2 s
Hi,
I'm running Debian server hosting Request Tracker with Postgresql as
database back-end. There is also gnupg-agent & dirmngr installed
(because of SMIME/GPG mail support). Systemd logs about starting user
sessions and Postgresql for some reason starts user sessions internally
frequen
(Sorry if this is a duplicate message, I tried to post this
an hour or so ago, but saw nothing on the list.)
I want to install bareos, the bacula derived backup software
with a PostgreSQL/dbconfig setup on a sid/amd64 system. I am
stuck at the following error:
An error occurred while installing
On the Debian bug reporting page it said that I should ask here if I wasn't
sure where to report a bug.
The problem is that the file /usr/share/hunspell/nl.aff (part of the
myspell-nl package) gives errors if you construct a ispell Dictionary with
it in PostgreSQL as follow:
CREATE TEXT S
On Wed, Aug 06, 2014 at 05:19:14PM +0100, Glyn Astill wrote:
> > From: B
> >To: debian-user@lists.debian.org Sent: Wednesday, 6 August 2014,
> >15:58 Subject: postgresql doesn't start at boot
> >
> >
> >sid amd64
> >
> >
> From: B
>To: debian-user@lists.debian.org
>Sent: Wednesday, 6 August 2014, 15:58
>Subject: postgresql doesn't start at boot
>
>
>sid
>amd64
>
>
>Hi mailing-listers,
>
>since the upgrade from 9.3 to 9.4, postgresql doesn't
Maybe the link was created in a wrong directory
2014-08-06 17:34 GMT+02:00 Michael Biebl :
>
>
> On 6. August 2014 17:17:22 MESZ, B wrote:
>>On Wed, 6 Aug 2014 17:07:56 +0200
>>emmanuel segura wrote:
>>
>>> Have you try systemctl enable postgresql.service ?
>>
>>Done (and quite different
On 6. August 2014 17:17:22 MESZ, B wrote:
>On Wed, 6 Aug 2014 17:07:56 +0200
>emmanuel segura wrote:
>
>> Have you try systemctl enable postgresql.service ?
>
>Done (and quite different from a symlink:(
Funny, because all systemctl enable does is create a symlink
>
>As I'm working, I'll t
On Wed, 6 Aug 2014 17:07:56 +0200
emmanuel segura wrote:
> Have you try systemctl enable postgresql.service ?
Done (and quite different from a symlink:(
As I'm working, I'll test it tonight; thanks.
--
is gogaz an anti jew nick?
NO
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.de
Have you try systemctl enable postgresql.service ?
2014-08-06 16:58 GMT+02:00 B :
> sid
> amd64
>
>
> Hi mailing-listers,
>
> since the upgrade from 9.3 to 9.4, postgresql doesn't automatically start
> at boot anymore.
> I added
sid
amd64
Hi mailing-listers,
since the upgrade from 9.3 to 9.4, postgresql doesn't automatically start
at boot anymore.
I added a symlink to /lib/systemd/system/postgresql.service
into /etc/systemd/system but I'm not sure this will be enough; is it?
(3.5 pages of l
ll have
> multiple levels of users and has a web page access system. Python, Django,
> html and javascript will take care of most of the project. I just need to
> get the permissions setup for Postgresql. Thanks for pointing out Chapter
> 19 of the manual. I haven’t read it yet but w
On 12/10/2013 11:13 PM, Raffaele Morelli wrote:
2013/12/11 Gary Roach <mailto:gary719_li...@verizon.net>>
I just switched from using PHP and Mysql to Python / Django and
Postgresql. I am having trouble with the setup of Postgresql
permissions. I am locked out of some par
On Tue, Dec 10, 2013 at 06:25:16PM -0800, Gary Roach wrote:
> automatically (I think). I found the Debian README confusing,
> especially in regards to setting up a special shell that I don't
> think I need.
Are you referring to the postgres user?
--
"If you're not careful, the newspapers will h
2013/12/11 Gary Roach
> I just switched from using PHP and Mysql to Python / Django and
> Postgresql. I am having trouble with the setup of Postgresql permissions. I
> am locked out of some parts of the system and am unsure when to use
> postgres login vs user login. Most of th
I just switched from using PHP and Mysql to Python / Django and
Postgresql. I am having trouble with the setup of Postgresql
permissions. I am locked out of some parts of the system and am unsure
when to use postgres login vs user login. Most of the Postgresql
instructions are written for non
On Tue, Nov 26, 2013 at 08:43:51PM -0600, John Hasler wrote:
Hi,
> It is always best to stick to the official Debian package when possible.
> Upstream debs are sometimes not very high quality. 9.3 is now in
In this special case https://wiki.postgresql.org/wiki/Apt / apt.postgresql.org
is backed
On 27/11/13 12:45, Jonathan Fortin wrote:
> Hi,
>
> The latest stable release of Debian contains PostgreSQL 9.1. But, on the
> PostgreSQL web-site the version 9.3 is available for Debian.
>
> So, I would like to know if is a good practice or not to install a new
> versi
nstable: is there a backport? If not, and you need 9.3 functionality,
you might want to contact the Postgresql maintainer about doing one.
--
John Hasler
jhas...@newsguy.com
Elmwood, WI USA
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe&qu
On Tue, Nov 26, 2013 at 08:45:27PM -0500, Jonathan Fortin wrote:
> Hi,
>
> The latest stable release of Debian contains PostgreSQL 9.1. But, on the
> PostgreSQL web-site the version 9.3 is available for Debian.
>
> So, I would like to know if is a good practice or no
Hi,
The latest stable release of Debian contains PostgreSQL 9.1. But, on the
PostgreSQL web-site the version 9.3 is available for Debian.
So, I would like to know if is a good practice or not to install a new version
which doesn't come from the release.
Note: we want to keep the stab
I solved this way:
1 - postgres installation package from official (not debian) in / opt
2 - install debian lenny and old postgres on the virtual machine
3 - copy directory postgres-data from backup in virtual machine
4 - recovered data dump
5- install dump data on new postgres
6- create user e pas
Fernando ff77, 20.05.2013:
> Update:
>
> I tried to install all the packages postgresql from SID. I have not solved.
>
> I can not understand where is the problem.
I don't know what the problem is either, since I don't use postgresql,
but I noticed the following in the
On Mon, May 20, 2013 at 10:38:25AM +0200, Fernando ff77 wrote:
> Update:
>
> I tried to install all the packages postgresql from SID. I have not solved.
Ouch! Sid is likely to be in a bit of a chaotic state at the moment.
> I can not understand where is the problem.
Then you s
Update:
I tried to install all the packages postgresql from SID. I have not solved.
I can not understand where is the problem.
Thanks.
ff77
> > invoke-rc.d: initscript postgresql, action "start" failed.
> > dpkg: errore nell'elaborare postgresql-9.1 (--configure):
> > il sottoprocesso installato script di post-installation ha restituito lo
> > stato di errore 1
> > Si sono verificat
Fernando ff77, 17.05.2013:
> hello,
> i update my server from sarge to wheezy (stable). (dist-upgrade)
Are you really trying to go from *sarge* to wheezy? Sounds like asking
for trouble.
> All package is ok... thanks aptitude !!!
>
> The problem is postgresql-9.1, during the
2013/5/17 Lisi Reisz
> On Friday 17 May 2013 17:54:01 Fernando ff77 wrote:
> > hello,
> >
> > ps: Today is Friday 17 !!! ARGHHH.
>
> What is wrong with Friday 17 ???
>
> Lisi
sorry but is only in italian.
http://it.wikipedia.org/wiki/Venerd%C3%AC_17
On Friday 17 May 2013 17:54:01 Fernando ff77 wrote:
> hello,
>
> ps: Today is Friday 17 !!! ARGHHH.
What is wrong with Friday 17 ???
Lisi
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: htt
hello,
i update my server from sarge to wheezy (stable). (dist-upgrade)
All package is ok... thanks aptitude !!!
The problem is postgresql-9.1, during the installation i read this error...
Configurazione di postgresql-9.1 (9.1.9-1)...
[] Starting PostgreSQL 9.1 database server: main
On Wed, Jul 25, 2012 at 06:25:45AM -0400, Jude DaShiell wrote:
> Files from previous versions of postgresql are on the system and I found
> it impossible to remove those packages with aptitude after several
> attempts. For that reason I will be reinstalling debian and not
>
On Wed, 25 Jul 2012 06:25:45 -0400, Jude DaShiell wrote:
Jude, if you open a new thread just for adding new info on the same
problematic, your posts will remain unconnected (out of context) and thus
very hard to follow...
> Files from previous versions of postgresql are on the system an
Files from previous versions of postgresql are on the system and I found
it impossible to remove those packages with aptitude after several
attempts. For that reason I will be reinstalling debian and not
reinstalling postgresql later
Apparently the installation of the packages failed to make any cluster so
pg_lscluster had nothing to show when it was run other than its heading
line.
Hardware
eventually fails; software eventually works, no amount of band widt
the steps outlined in /usr/share/doc/postgresql-common/README.Debian.gz
with regard to createuser to create a database on my system only generate
a message informing me that createuser couldn't connect to the database
and asking me if the communication is happening locally on port 543
hat it should be.
> change value that postgresql was using before and that would explain why
> this failure happened. However, it will be a good idea to fix the
> postgresql 9.1 packages so they increase that shm value for installs
I'm fairly sure that a package shouldn't go
I was fortunate in that I hadn't put any data into that database system
yet. The 40,000,000 value for shm is higher than the 34 million and
change value that postgresql was using before and that would explain why
this failure happened. However, it will be a good idea to fix the
postg
On Sun, Jul 01, 2012 at 04:49:32AM -0400, Jude DaShiell wrote:
> The transition from postgresql 8.4 to postgresql 9.1 almost worked over
> here except for a little matter of the linux kernel's shm value. This
> broke when I was involved with pg_upgradecluster and afterwards 9
The transition from postgresql 8.4 to postgresql 9.1 almost worked over
here except for a little matter of the linux kernel's shm value. This
broke when I was involved with pg_upgradecluster and afterwards 9.1
wouldn't start. End result, all of postgresql has been removed from thi
1 - 100 of 1121 matches
Mail list logo
