On Sat, Mar 23, 2019 at 9:40 AM Andy Colson wrote:
> On 3/23/19 7:09 AM, Rory Campbell-Lange wrote:
> > On 17/03/19, Rory Campbell-Lange (r...@campbell-lange.net) wrote:
> >> We aren't sure whether to use software MDRaid or a MegaRAID card.
> >>
> >> We're buying some new Postgres servers with
>
On Sat, Jan 26, 2019 at 6:30 PM Ron wrote:
> On 1/26/19 5:04 PM, Chuck Martin wrote:
>
> I'm having trouble formulating a query. This is a simplified version of
> the tables:
>
> ombcase
>
> case_pkey integer, primary key
> casename varchar
> insdatetime timestamp w/o time zone
> sta
, that which can be adequately explained by
> stupidity"
> - Hanlon's Razor
>
>
> Original Message
> Subject: Re: Trouble Upgrading Postgres
> From: Tom Lane
> Date: Tue, November 06, 2018 11:53 am
> To: Adrian Klaver
> Cc: Daniel Verite , Charl
I've
Adrian, I'll try changing shared_buffers the next time I can restart
postgres, at least if deleting the largest records and adding VM hasn't
worked.
On Tue, Nov 6, 2018 at 6:47 AM Daniel Verite
wrote:
> Charles Martin wrote:
>
> > but the second one
, I might be able to delete them. If I can find them.
On Mon, Nov 5, 2018 at 12:54 PM Daniel Verite
wrote:
> Charles Martin wrote:
>
> > SELECT max(length(docfilecontents::text)) FROM docfile;
> > and after a very long time, got:
> > ERROR: invalid memory alloc
7;d have made a 4GB swap file.)
I have a spare drive that is 230G, so I have enough space. I suppose I can
set swapoff, delete the swapfile, create a new 4G one, and set swapon. Or
is there a better way?
On Mon, Nov 5, 2018 at 11:56 AM Ron wrote:
> On 11/05/2018 10:50 AM, Charles Martin w
l, that's 1GB, which might be ambitious inside a VM with a hard
restriction to 4GB total RAM. Postgres can get by with a *lot* less.
>Try knocking it down to a tenth of that and see if it makes a difference
I think I also based this on a rule-of-thumb that it should be no more than
25%
gresql.org/docs/10/static/runtime-config-resource.html
>set to?
Ok, thanks for explaining this. Here is the current value:
"shared_buffers" "131072" "8kB"
On Mon, Nov 5, 2018 at 9:06 AM Adrian Klaver
wrote:
> On 11/5/18 5:56 AM, Charles Martin wrote:
> &
Sun, Nov 4, 2018 at 8:16 PM Adrian Klaver
wrote:
> On 11/4/18 2:55 PM, Charles Martin wrote:
> > Yep, you called it:
> >
> > Nov 2 20:30:45 localhost kernel: Out of memory: Kill process 30438
> > (postmaster) score 709 or sacrifice child
> > Nov 2 20:30:45 localhost
emory when trying to dump this table. The "old"
server has 4GB of ram, the "new" server 20GB.
On Sun, Nov 4, 2018 at 3:13 PM Adrian Klaver
wrote:
> On 11/4/18 8:38 AM, Charles Martin wrote:
> >
> > Adtrian said:
> >>> pg_dump: Error message from ser
Adtrian said:
>> pg_dump: Error message from server: server closed the connection
>> unexpectedly
>Is this error the client reporting?
>Is this the same that is showing up in the server log?
Yes, that's the client message, i.e. what appeared in the terminal window
that gave the command. The serve
e to find where Centos 7, or Postgres 9.6, stores
the path to the config/data directory outside the data/postgresql.conf
file. But I agree there must be something somewhere.
Chuck
On Sat, Nov 3, 2018 at 6:06 PM Adrian Klaver
wrote:
> On 11/3/18 2:56 PM, Charles Martin wrote:
>
> P
I'd be grateful for some help. I am trying to move a large database from
PostgreSQL 9.6 on Centos 6 to a different server using PostgreSQL 11 on
Centos 7. I can't do a pg_dump because it always fails on the largest
table. So tried to do pb_basebackup and copy that to the new PG 11 server.
Except th
13 matches
Mail list logo
