Re: [GENERAL] Using cp to back up a database?

On 10/09/2017 01:02 PM, Scott Mead wrote: On Mon, Oct 9, 2017 at 1:19 PM, Ron Johnson <ron.l.john...@cox.net <mailto:ron.l.john...@cox.net>> wrote: Maybe my original question wasn't clear, so I'll try again: is it safe to do a physical using cp (as opposed to r

[GENERAL] Finally upgrading to 9.6!

Where can I look to see (roughly) how much more RAM/CPU/disk needed when moving from 8.4 and 9.2? Thanks -- World Peace Through Nuclear Pacification -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription:

[GENERAL] WAL & ready files retained after turning off log shipping

Hi, v8.4 (and there's nothing I can do about it). After disabling log shipping via setting "archive_mode = off", and then running, "pg_ctl reload", old WAL files and their associated .ready files aren't being deleted. Is there any document you can point me to as to why this is happening,

Re: [GENERAL] WAL & ready files retained after turning off log shipping

On 09/07/2017 09:08 AM, Tom Lane wrote: Ron Johnson <ron.l.john...@cox.net> writes: After disabling log shipping via setting "archive_mode = off", and then running, "pg_ctl reload", old WAL files and their associated .ready files aren't being deleted. Hmm. I migh

Re: [GENERAL] WAL & ready files retained after turning off log shipping

On 09/07/2017 05:07 PM, Michael Paquier wrote: On Thu, Sep 7, 2017 at 11:08 PM, Tom Lane wrote: Manual cleanup shouldn't be very hard, fortunately. Run pg_controldata to see where the last checkpoint is, and delete WAL files whose names indicate they are before that (but

[GENERAL] B-tree index on a VARCHAR(4000) column

Hi, v 9.2.7 Based on LENGTH(offending_column), none of the values are more than 144 bytes in this 44.2M row table. Even though VARCHAR is, by definition, variable length, are there any internal design issues which would make things more efficient if it were dropped to, for example,

Re: [GENERAL] WAL & ready files retained after turning off log shipping

On 09/07/2017 09:32 AM, Tom Lane wrote: Ron Johnson <ron.l.john...@cox.net> writes: On 09/07/2017 09:08 AM, Tom Lane wrote: Manual cleanup shouldn't be very hard, fortunately. Run pg_controldata to see where the last checkpoint is, and delete WAL files whose names indicate they are

Re: [GENERAL] Joining 16 tables seems slow

On 09/12/2017 01:45 AM, Frank Millman wrote: Hi all I am using 9.4.4 on Fedora 22. I am experimenting with optimising a SQL statement. One version uses 4 LEFT JOIN’s and a 5-way CASE statement in the body. The second moves the filtering into the JOIN section, and I end up with 16 LEFT JOIN’s

Re: [GENERAL] Log shipping in v8.4.7

On 08/27/2017 02:23 PM, Christoph Moench-Tegeder wrote: ## Ron Johnson (ron.l.john...@cox.net): Everything I've read says that you should use "rsync -a". Is there any reason why we can't/shouldn't use "rsync -az" so as to reduce transfer time? On today's LANs,

[GENERAL] Log shipping in v8.4.7

Hi, (Yes, its old. Nothing I can do about that.) Everything I've read says that you should use "rsync -a". Is there any reason why we can't/shouldn't use "rsync -az" so as to reduce transfer time? Also, does that change require a full restart (difficult with production systems)? Thanks

[GENERAL] Logging the fact that a log was shipped

Hi, How is this done in v8.4? (I tried adding "date; rsync ..." but pg didn't like that *at all*.) Thanks -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Logging the fact that a log was shipped

On 08/28/2017 06:06 AM, Christoph Moench-Tegeder wrote: ## Ron Johnson (ron.l.john...@cox.net): How is this done in v8.4? (I tried adding "date; rsync ..." but pg didn't like that *at all*.) There's a DEBUG1-level log message on successful archive_command completion - that woul

Re: [GENERAL] Logging the fact that a log was shipped

On 08/28/2017 08:22 AM, Stephen Frost wrote: * Christoph Moench-Tegeder (c...@burggraben.net) wrote: ## Ron Johnson (ron.l.john...@cox.net): How is this done in v8.4? (I tried adding "date; rsync ..." but pg didn't like that *at all*.) There's a DEBUG1-level log message on

[GENERAL] Veritas cluster management

Hi, For any of you with those failover clusters, do you know if "pg_ctl reload" works (for compatible config file changes), or must we bounce the database using "hares -offline" then "hares -online"? Thanks -- World Peace Through Nuclear Pacification -- Sent via pgsql-general mailing

Re: [GENERAL] Veritas cluster management

On 08/30/2017 08:48 AM, Scott Mead wrote: On Wed, Aug 30, 2017 at 9:43 AM, Ron Johnson <ron.l.john...@cox.net <mailto:ron.l.john...@cox.net>> wrote: Hi, For any of you with those failover clusters, do you know if "pg_ctl reload" works (for compatib

Re: [GENERAL] Finally upgrading to 9.6!

On 10/17/2017 11:17 AM, Tom Lane wrote: Ron Johnson <ron.l.john...@cox.net> writes: Where can I look to see (roughly) how much more RAM/CPU/disk needed when moving from 8.4 and 9.2? It's entirely possible you'll need *less*, as you'll be absorbing the benefit of several years'

Re: [GENERAL] Finally upgrading to 9.6!

On 10/18/2017 10:16 AM, Igal @ Lucee.org wrote: On 10/18/2017 7:45 AM, Ron Johnson wrote: On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote: A bit off-topic here, but why upgrade to 9.6 when you can upgrade to 10.0? There's no way we're going to put an x.0.0 version into production

Re: [GENERAL] Finally upgrading to 9.6!

On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote: On 10/18/2017 6:24 AM, Ron Johnson wrote: On 10/17/2017 11:17 AM, Tom Lane wrote: Ron Johnson <ron.l.john...@cox.net> writes: Where can I look to see (roughly) how much more RAM/CPU/disk needed when moving from 8.4 and 9.2? It's en

Re: [GENERAL] mild modification to pg_dump

What about the pgpass file? https://www.postgresql.org/docs/9.2/static/libpq-pgpass.html On 11/17/2017 03:06 PM, marcelo wrote: I need to "emulate" the pg_dump code because the password prompt. Years ago I write a program (for the QnX environment) that catched some prompt and emulates the

Re: [GENERAL] mild modification to pg_dump

On 11/17/2017 02:23 PM, John R Pierce wrote: On 11/17/2017 12:19 PM, marcelo wrote: Sorry, I was not exact. I don't need nor like to change pg_dump. Rather, based on pg_dump code, I need to develop a daemon which can receive a TCP message (from a privileged app) containing some elements: the

[GENERAL] pg_restore load data

Hi, v9.2.7  (Yes, I know, it's old.  Nothing I can do about it.) During a "whole database" restore using pg_restore of a custom dump, when is the data actually loaded?  I've looked in the list output and don't see any "load" statements. Thanks -- World Peace Through Nuclear Pacification

Re: [GENERAL] pg_restore load data

On 11/16/2017 03:13 PM, bricklen wrote: On Thu, Nov 16, 2017 at 1:07 PM, Ron Johnson <ron.l.john...@cox.net <mailto:ron.l.john...@cox.net>> wrote: v9.2.7  (Yes, I know, it's old.  Nothing I can do about it.) During a "whole database" restore using pg_re

[GENERAL] Converting AGE() to something human readable

Hi, How is this done in v8.4? postgres=# SELECT datname, datfrozenxid, age(datfrozenxid) postgres-# FROM pg_database;   datname  | datfrozenxid |    age ---+--+--- template1 |   3603334165 |  25735089 template0 |   3603470462 |  25598792 postgres  |   3576970250 | 

[GENERAL] Old pg_clog files

Hi, v8.4.17 http://www.postgresql-archive.org/pg-clog-questions-td2080911.html According to this old thread,  doing a VACUUM on every table in the postgres, template1 and TAPd databases should remove old pg_clog files. postgres=# SELECT datname, age(datfrozenxid) FROM pg_database;   datname 

Re: [GENERAL] Old pg_clog files

On 10/29/2017 03:37 PM, David G. Johnston wrote: On Sunday, October 29, 2017, Ron Johnson <ron.l.john...@cox.net <mailto:ron.l.john...@cox.net>> wrote: Hi, v8.4.17 http://www.postgresql-archive.org/pg-clog-questions-td2080911.html <http://www.postgresql-arch

<    2   3   4   5   6   7