Rich Shepard writes:
> On Mon, 19 Feb 2018, Tim Cross wrote:
>
>> It is possible for the target of a symbolic link to be changed, deleted
>> etc (a dangling sym link).
>
> Tim,
>
>Broken symlinks display in a different color, black on a red background if
> I remember correctly, rather than t
On Mon, 19 Feb 2018, Tim Cross wrote:
It is possible for the target of a symbolic link to be changed, deleted
etc (a dangling sym link).
Tim,
Broken symlinks display in a different color, black on a red background if
I remember correctly, rather than the light cyan of a working symlink. I'v
Rich Shepard writes:
> On Sun, 18 Feb 2018, Tim Cross wrote:
>
>>> # ll /usr/bin/postgres
>>> lrwxrwxrwx 1 root root 35 Feb 17 09:30 /usr/bin/postgres ->
>>> ../lib/postgresql/10.2/bin/postgres*
>
>> Try doing an 'll' on the second part of that output i.e.
>> ll /usr//lib/postgresql/10.2/bin/po
Rich Shepard writes:
> On Sun, 18 Feb 2018, Tim Cross wrote:
>
>> This may not be relevant,
>
> Tim,
>
>Nope. Pat goes for stability, not cutting edge. No systemd in the
> forthcoming 15.0, either.
>
> Thanks,
>
> Rich
No worries, though I'm not sure you can call systemd 'cutting edge'
anym
On Sun, 18 Feb 2018, Rich Shepard wrote:
Thanks for confirming
Removed all files in the data/ directory, re-initialized the cluster, and
restored the dumped .sql file (minus three databases and their roles
manually deleted). All works well now.
Thanks, Adrian!
Best regards,
Rich
On Sun, 18 Feb 2018, Adrian Klaver wrote:
Is this appropriate?
Yes.
Adrian,
Thanks for confirming
They could not have been removed as they are in the file. I am guessing
you are saying they are not in use as far as you know. Just a warning(from
experience), memory is a tricky thing and
On 02/18/2018 08:05 AM, Rich Shepard wrote:
On Sat, 17 Feb 2018, Rich Shepard wrote:
That's what I was thinking, too. I can remove the 10.2 package, rebuild
and re-install it. Run initdb, then, as postgres, read in the .sql file.
This is probably the pragmatic thing to do.
Rather than doin
On Sat, 17 Feb 2018, Rich Shepard wrote:
That's what I was thinking, too. I can remove the 10.2 package, rebuild
and re-install it. Run initdb, then, as postgres, read in the .sql file.
This is probably the pragmatic thing to do.
Rather than doing this my reading of the 10.2 initdb pages sug
On Sun, 18 Feb 2018, Tim Cross wrote:
# ll /usr/bin/postgres
lrwxrwxrwx 1 root root 35 Feb 17 09:30 /usr/bin/postgres ->
../lib/postgresql/10.2/bin/postgres*
Try doing an 'll' on the second part of that output i.e.
ll /usr//lib/postgresql/10.2/bin/postgres*
See my message, repeated above
On Sun, 18 Feb 2018, Tim Cross wrote:
This may not be relevant,
Tim,
Nope. Pat goes for stability, not cutting edge. No systemd in the
forthcoming 15.0, either.
Thanks,
Rich
Rich Shepard writes:
> On Sat, 17 Feb 2018, Adrian Klaver wrote:
>
>> Got to thinking that given the issues with the upgrade I would be leery
>> about the state of the new cluster as a whole. Might want to consider
>> doing it over again or just use the pg_dumpall output to recreate the
>> datab
Rich Shepard writes:
> On Sat, 17 Feb 2018, Adrian Klaver wrote:
>
>
> [root@salmo /etc/rc.d]# killall postgres
> [root@salmo /etc/rc.d]# ./rc.postgresql start
> Could not find 'postgres' binary. Maybe PostgreSQL is not installed properly?
>
>Yet,
>
> # ll /usr/bin/postgres
> lrwxrwxrwx 1 r
On Sat, 17 Feb 2018, Adrian Klaver wrote:
Got to thinking that given the issues with the upgrade I would be leery
about the state of the new cluster as a whole. Might want to consider
doing it over again or just use the pg_dumpall output to recreate the
database(s).
Adrian,
That's what I wa
On 02/17/2018 04:44 PM, Rich Shepard wrote:
On Sat, 17 Feb 2018, Adrian Klaver wrote:
From a previous post:
POSTGRES=/usr/lib${LIBDIRSUFFIX}/@PRGNAM@/$PG_VERSION/bin/postgres
From here:
http://slackbuilds.org/slackbuilds/14.1/system/postgresql/postgresql.SlackBuild
The desktop runs 32
On 02/17/2018 04:44 PM, Rich Shepard wrote:
On Sat, 17 Feb 2018, Adrian Klaver wrote:
From a previous post:
POSTGRES=/usr/lib${LIBDIRSUFFIX}/@PRGNAM@/$PG_VERSION/bin/postgres
From here:
http://slackbuilds.org/slackbuilds/14.1/system/postgresql/postgresql.SlackBuild
The desktop runs 32
On Sat, 17 Feb 2018, Adrian Klaver wrote:
From a previous post:
POSTGRES=/usr/lib${LIBDIRSUFFIX}/@PRGNAM@/$PG_VERSION/bin/postgres
From here:
http://slackbuilds.org/slackbuilds/14.1/system/postgresql/postgresql.SlackBuild
The desktop runs 32-bit 14.2.
You could also try using pg_ctl to
On 02/17/2018 03:59 PM, Rich Shepard wrote:
On Sat, 17 Feb 2018, Adrian Klaver wrote:
Did pg_upgrade spit out any warnings/errors?
Adrian,
Yes. The uid and gid were mis-matched and, because of that, the
data/directory and all its files were owned by group user, not group
postgres.
In yo
On Sat, 17 Feb 2018, Adrian Klaver wrote:
Did pg_upgrade spit out any warnings/errors?
Adrian,
Yes. The uid and gid were mis-matched and, because of that, the
data/directory and all its files were owned by group user, not group
postgres.
In your previous post you showed:
# /etc/rc.postgre
On 02/17/2018 02:25 PM, Rich Shepard wrote:
On Sat, 17 Feb 2018, Adrian Klaver wrote:
How did you upgrade, dump/restore or pg_upgrade?
Adrian,
Ran 'pg_dumpall -c -f .sql' prior to doing anything. Then
built,
installed the new version, upgraded rc.postgresql (only differences were
versio
On Sat, 17 Feb 2018, Adrian Klaver wrote:
How did you upgrade, dump/restore or pg_upgrade?
Adrian,
Ran 'pg_dumpall -c -f .sql' prior to doing anything. Then built,
installed the new version, upgraded rc.postgresql (only differences were
version numbers), and ran 'pg_upgrade ...' with the ap
On 02/17/2018 02:00 PM, Rich Shepard wrote:
Hi folks,
Today I upgraded from -9.6.6 to -10.2 on my Slackware-14.2 desktop. The
user and group IDs changed from before, but I have that all fixed now.
Starting postgres (as user postgres) succeeded, but the role for me (as a
use and owner of most
Hi folks,
Today I upgraded from -9.6.6 to -10.2 on my Slackware-14.2 desktop. The
user and group IDs changed from before, but I have that all fixed now.
Starting postgres (as user postgres) succeeded, but the role for me (as a
use and owner of most databases) seems to have become lost during th
22 matches
Mail list logo