Hi All,
We've decided to upgrade our PostgreSQL production servers. First task
is remove an old v7.14 version. It was supposed to be upgraded to a v8.4
server. The server was installed, several databases where released here
but v7.4 was never migrated. The plan is pg_dump this database and psq
El 25/9/19 a las 20:21, Adrian Klaver escribió:
On 9/25/19 9:00 AM, Tom Lane wrote:
Ron writes:
On 9/25/19 9:29 AM, Christoph Berg wrote:
Re: Ekaterina Amez 2019-09-25
<8818b028-bd2d-412e-d4e3-e29c49ffe...@zunibal.com>
We've decided to upgrade our PostgreSQL production servers.
Good afternoon,
We've finally made the migration+upgrade from old server with v7.14 to
new server with v8.4 and, before test and plan an upgrade to v9.6, I'm
checking logs to find out if there's any problem with this upgrade.
We've been fixing things and in only remains one problem in the log
El 17/10/19 a las 16:12, Andreas Joseph Krogh escribió:
But I don't understand why I'm getting those messages about autovacuum
blocking db restore process. I guess that after one table is created
with COPY sentence, as many rows have been inserted, autoanalyze
process
runs
El 21/11/19 a las 15:21, Jason L. Amerson escribió:
I am at a loss for what to do. I have read article after article about
how to allow remote connections on my PostgreSQL server and none of
what the articles say do, worked for me. I have edited the
“postgresql.conf” file and changed “listen_
El 6/12/19 a las 23:07, Alan Hodgson escribió:
On Fri, 2019-12-06 at 21:38 +, Julie Nishimura wrote:
I'd like to copy one single database from 9.4 cluster to a new 9.6
cluster (migration with the upgrade), to the different host
Put 9.4 on the new server. Replicate the db to it. When you
Hi all,
After your comments about how to upgrade postgres from 9.2 to 9.6 in an
overloaded server I've been learning and testing streaming replication.
But the info I've found about this topic is not enough for me (or I'm
not able to completely understand it).
(I'm bad with terminology as I'
El 21/1/20 a las 10:14, Laurenz Albe escribió:
On Mon, 2020-01-20 at 14:59 +0100, Ekaterina Amez wrote:
PS: Just in case anyone wants to know, this is part of the process of upgrade a
server with 9.2 version
that has no free space in PGDATA and that can't be stopped for much time.
Hi List,
I'm used to make my own scripts in Oracle plsql, Sql Server tsql... but
I'm unable to make one simple script in Postgres.
Objective version is 8.4 (I know, I know... it's a legacy server, I'm
planning upgrade this server as soon as I can).
I have a test server with 9.2 version wher
El mié., 25 mar. 2020 a las 13:42, Pavel Stehule ()
escribió:
>
> just this is not supported feature.
>
I was affraid this was going to be the answer.. sigh
> You have some special reason why you use 8.4? It's pretty old unsupported
> version.
>
As I said: legacy server. I'm planning upgrade i
El mié., 25 mar. 2020 a las 13:54, David G. Johnston (<
david.g.johns...@gmail.com>) escribió:
> On Wednesday, March 25, 2020, Ekaterina Amez
> wrote:
>>
>> What's wrong with the syntax? Or is not possible to make a script and I
>> have to create a function to
Remote SQL: SELECT , btatpd_aaaa, ffff FROM
public.table2 WHERE ((btatpd_fecha = '2022011912'::text))
Planning time: 2.137 ms
Execution time: 123.077 ms
Anyone can tell me why is this happening and if is there a solution to this?
Thank you for your time.
--
El vie, 21 ene 2022 a las 5:04, Michael Lewis ()
escribió:
> When dealing with foreign tables, I believe planning is not the same
> because of access to statistics (maybe has improved since 9.6 though). I
> just wonder... Would it be a viable option to create a materialized view
> using the FDW bu
Hi List,
I'm making some tests in order to prepare a db migration. We have version
9.6 over CentOS 7 and we're going to migrate to version 15 over Rocky Linux
9. Of course there is a no downtime requirement or I wouldn't be here
asking.
I was previously aware of the problem with different glibc v
14 matches
Mail list logo
