On Wed, 31 Oct 2018, Rich Shepard wrote:
I managed to mess up postgresql-10.3 on this Slackware-14.2 desktop
server/workstation. It worked OK until I tried adding access to an another
application.
The problems have been resolved by upgrading 10.3 to 10.5 using the
SlackBuild.org script.
On Wed, 31 Oct 2018, Adrian Klaver wrote:
Even with assurances I would back up that directory(assuming space available)
before proceeding with a rebuild. Or do you have a recent dump of the
cluster?
Adrian,
That's my thinking, too. No, an explicit pg_dumpall is too old to be
useful. I
On Wed, 31 Oct 2018, Adrian Klaver wrote:
Hmm in the build script the difference is:
VERSION=${VERSION:-10.3}
PG_VERSION=${PG_VERSION:-10.3}
--docdir=/usr/doc/$PRGNAM-$VERSION \
--datadir=/usr/share/$PRGNAM-$PG_VERSION \
Wonder where the script is finding PG_VERSION?
Do you have env variable
On 10/31/18 3:19 PM, Rich Shepard wrote:
On Wed, 31 Oct 2018, Adrian Klaver wrote:
Well there is something strange going. From a previous post:
Andrew,
Yet it ran without a whimper from the upgrade last March 1st to this
morning when I modified postgresql.conf.
It's the middle of the
On 10/31/18 3:19 PM, Rich Shepard wrote:
On Wed, 31 Oct 2018, Adrian Klaver wrote:
Well there is something strange going. From a previous post:
Andrew,
Yet it ran without a whimper from the upgrade last March 1st to this
morning when I modified postgresql.conf.
It's the middle of the
On Wed, 31 Oct 2018, Adrian Klaver wrote:
Well there is something strange going. From a previous post:
Andrew,
Yet it ran without a whimper from the upgrade last March 1st to this
morning when I modified postgresql.conf.
It's the middle of the night in central Europe so I expect to hear
On 10/31/18 3:08 PM, Adrian Klaver wrote:
On 10/31/18 3:03 PM, Rich Shepard wrote:
On Wed, 31 Oct 2018, Andrew Gierth wrote:
What this says is that you somehow have a pg 10.3 binary which has been
compiled with ./configure --datadir=/usr/share/postgresql-10.2
which seems, to say the least,
On 10/31/18 3:03 PM, Rich Shepard wrote:
On Wed, 31 Oct 2018, Andrew Gierth wrote:
What this says is that you somehow have a pg 10.3 binary which has been
compiled with ./configure --datadir=/usr/share/postgresql-10.2
which seems, to say the least, somewhat odd.
Andrew,
Quite odd rather
On 10/31/18 2:40 PM, Rich Shepard wrote:
On Wed, 31 Oct 2018, Rich Shepard wrote:
Still bad links remaining.
Every pg_* not in /usr/lib/postgresql/10.3/bin/ now points to its
namesake
there.
Hmm. Grasping at straws. In a previous post you mentioned:
"If it matters, there's no
On Wed, 31 Oct 2018, Andrew Gierth wrote:
What this says is that you somehow have a pg 10.3 binary which has been
compiled with ./configure --datadir=/usr/share/postgresql-10.2
which seems, to say the least, somewhat odd.
Andrew,
Quite odd rather than somewhat odd because the configure
On Wed, 31 Oct 2018, Adrian Klaver wrote:
So no, as I presume you rebooted on the kernel upgrade which caused the
Postgres server to stop/start.
True. It stopped for the time it took the server to reboot.
Rich
On 10/31/18 2:01 PM, Rich Shepard wrote:
Did the server been running continuously from the upgrade to the time you
made the listen_addresses change?
Yes, other than a few kernel upgrades.
So no, as I presume you rebooted on the kernel upgrade which caused the
Postgres server to
> "Rich" == Rich Shepard writes:
Rich> Yes, pg_config is present but pointing to the wrong directory:
Rich> # /usr/lib/postgresql/10.3/bin/pg_config --sharedir
Rich> /usr/share/postgresql-10.2
What this says is that you somehow have a pg 10.3 binary which has been
compiled with
On Wed, 31 Oct 2018, Rich Shepard wrote:
Still bad links remaining.
Every pg_* not in /usr/lib/postgresql/10.3/bin/ now points to its namesake
there.
Question: if pg_dump, pg_dumpall, pg_restore, pg_ctl, and pg_controldata
have symlinks in /usr/bin/ do they also need symlinks in /bin/?
On Wed, 31 Oct 2018, Rich Shepard wrote:
I'll fix those links and report the results of running pg_ctl start.
Still bad links remaining. Some of those symlinks in /usr/bin/ dated back
to versons 9.4 and 9.6. Why they were not removed during upgrades remains a
mystery.
Rich
On Wed, 31 Oct 2018, Rich Shepard wrote:
[1] This prompted me to look for more pg_config files, and I found a symlink
in /usr/bin/ that pointed to /usr/lib/postgresql/10.2/bin/pg_config which
does not exist. I changed that symlink to point to the 10.3/ pg_config
version but there's still a
On Wed, 31 Oct 2018, Adrian Klaver wrote:
Are there actually 10.2/ directories or is that just what you are seeing in
the error messages and the pg_config output?
Adrian,
No 10.2/ directories, only what is shown in the error messages and
pg_config output.
Previously you used:
On 10/31/18 1:09 PM, Rich Shepard wrote:
On Wed, 31 Oct 2018, Adrian Klaver wrote:
What does:
pg_ctl --version
show?
# pg_ctl --version
pg_ctl (PostgreSQL) 10.3
So when you added the new application did you make any other changes?
I did not add another application; grass has been
On Wed, 31 Oct 2018, Adrian Klaver wrote:
What does:
pg_ctl --version
show?
# pg_ctl --version
pg_ctl (PostgreSQL) 10.3
So when you added the new application did you make any other changes?
I did not add another application; grass has been installed here for
decades. Because I could not
On 10/31/18 12:14 PM, Rich Shepard wrote:
On Wed, 31 Oct 2018, Adrian Klaver wrote:
listen_addresses = ''
Adrian,
#listen_addresses = ''
$ pg_ctl start -D /var/lib/pgsql/10.3/data/
waiting for server to start2018-10-31 12:12:39.530 PDT [4398]
FATAL: could not open directory
On Wed, 31 Oct 2018, Adrian Klaver wrote:
listen_addresses = ''
Adrian,
#listen_addresses = ''
$ pg_ctl start -D /var/lib/pgsql/10.3/data/
waiting for server to start2018-10-31 12:12:39.530 PDT [4398] FATAL: could not open
directory "/usr/share/postgresql-10.2/timezonesets": No such
On 10/31/18 11:48 AM, Rich Shepard wrote:
On Wed, 31 Oct 2018, Andrew Gierth wrote:
Is there a pg_config binary in /usr/lib/postgresql/10.3/bin/ and if so,
what is the output of /usr/lib/postgresql/10.3/bin/pg_config --sharedir
Andrew,
Yes, pg_config is present but pointing to the wrong
On 10/31/18 11:33 AM, Rich Shepard wrote:
On Wed, 31 Oct 2018, Adrian Klaver wrote:
If you refuse to implement the suggestions I asked for then I cannot
help you, as you are now off on a different tangent. One that on the
face of it is dangerous.
In
On Wed, 31 Oct 2018, Andrew Gierth wrote:
Is there a pg_config binary in /usr/lib/postgresql/10.3/bin/ and if so,
what is the output of /usr/lib/postgresql/10.3/bin/pg_config --sharedir
Andrew,
Yes, pg_config is present but pointing to the wrong directory:
#
> "Rich" == Rich Shepard writes:
Rich> I managed to mess up postgresql-10.3 on this Slackware-14.2
Rich> desktop server/workstation. It worked OK until I tried adding
Rich> access to an another application.
Rich> waiting for server to start2018-10-31 10:02:01.312 PDT [1285] FATAL:
On Wed, 31 Oct 2018, Adrian Klaver wrote:
If you refuse to implement the suggestions I asked for then I cannot help
you, as you are now off on a different tangent. One that on the face of it is
dangerous.
In var/lib/pgsql/10.3/data/postgresql.conf:
# - Connection Settings -
_addresses =
On 10/31/18 11:15 AM, Rich Shepard wrote:
On Wed, 31 Oct 2018, Adrian Klaver wrote:
You said it made a difference when you added it, just trying to figure
out if removing it also makes a difference. If not then we need to
look elsewhere for an explanation.
Adrian,
Each time I hit a
On Wed, 31 Oct 2018, Adrian Klaver wrote:
You said it made a difference when you added it, just trying to figure out if
removing it also makes a difference. If not then we need to look elsewhere
for an explanation.
Adrian,
Each time I hit a broken symlink pg_ctl told me which link was
On 10/31/18 10:55 AM, Rich Shepard wrote:
On Wed, 31 Oct 2018, Adrian Klaver wrote:
What was the listening address you added?
Adrian,
I added the host name.
What happens if you remove the listening address?
I don't think this makes a difference. pg_ctl is calling a program that
On Wed, 31 Oct 2018, Adrian Klaver wrote:
What was the listening address you added?
Adrian,
I added the host name.
What happens if you remove the listening address?
I don't think this makes a difference. pg_ctl is calling a program that
looks for timezonesets in the wrong directory
On 10/31/18 10:18 AM, Rich Shepard wrote:
I managed to mess up postgresql-10.3 on this Slackware-14.2 desktop
server/workstation. It worked OK until I tried adding access to an another
application.
For a reason I don't know, adding that listening address revealed that
many sym links are
31 matches
Mail list logo
