If anyone hits this it is an issue with using the Geography type with a non
4326 SRID on a table and pg_upgrade.
It should be fixed (the check dropped as it's something of a relic) in the
next version of PostGIS. In the meantime you would have to patch it out
yourself.
(
https://github.com/postgi
Julie Nishimura writes:
> Thank you Tom. I can see bunch of old processes running ROLLBACK... Should I
> kill them or they only way to clear those is to restart the server?
As Ron pointed out, those processes aren't actually running ROLLBACK;
that was just their last query. They're idle (and no
On Wed, 4 Sep 2019 at 5:47 am, Adrian Klaver
wrote:
> On 9/2/19 5:52 PM, Adrian Klaver wrote:
>
> >> It's still creating the schema elements when it fails, it hasn't
> >> started linking yet
> >
> > Alright at least you still a working 9.6 cluster .
> >
> > Not sure where to go from here. Like yo
Those are all idle. I've got a cron job to kill all idle processes more
than 60 (or 30, I don't remember) minutes old.
On 9/3/19 6:29 PM, Julie Nishimura wrote:
Thank you Tom. I can see bunch of old processes running ROLLBACK... Should
I kill them or they only way to clear those is to restart
On 9/3/19 3:45 PM, James Sewell wrote:
-- For binary upgrade, create an empty extension and insert objects
into it
DROP EXTENSION IF EXISTS tablefunc;
SELECT pg_catalog.binary_upgrade_create_empty_extension('tablefunc',
'public', true, '1.0', NULL, NULL, ARRAY[]::pg_cata
On Sun 2019-09-01 20:58:30 -0400, Tom Lane wrote:
> >> A separate question is how come the particular query you're complaining
> >> about has (seemingly) a fairly wide window where it never does any
> >> CHECK_FOR_INTERRUPTS call before terminating. Perhaps there's someplace
> >> we need to sprink
Thank you Tom. I can see bunch of old processes running ROLLBACK... Should I
kill them or they only way to clear those is to restart the server?
postgres=# select * from pg_stat_activity where datname ='symphony_middleware'
and query_start < '08/20/2019' and query like '%ROLLBACK%';
datid |
Julie Nishimura writes:
> PostgreSQL 9.6.2 on x86_64-pc-linux-gnu
> It seems like we have one process running since 8/19. Is it any repercussion
> if we kill it?
> postgres=# select * from pg_stat_activity where pid = '18986';
> -[ RECORD 1
> ]+--
Hello there,
PostgreSQL 9.6.2 on x86_64-pc-linux-gnu
It seems like we have one process running since 8/19. Is it any repercussion if
we kill it?
postgres=# select * from pg_stat_activity where pid = '18986';
-[ RECORD 1
]+--
Hi Tom,
Sincere apologies for that privacy notice in email, this company policy which I
cannot skip.
Adrian,
The function is really simple. I’ll share the code as soon as I can.
Regards,
Virendra
> On Sep 3, 2019, at 5:41 PM, Tom Lane wrote:
>
> Adrian Klaver writes:
>>> On 9/3/19 1:56 PM,
Adrian Klaver writes:
> On 9/3/19 1:56 PM, Kumar, Virendra wrote:
>> Here is simple query, I am running via function call. This statement
>> runs fine as SQL but when put in function as plpgsql it failes with
>> error below, when I ran second times in same session it succeeds:
> We will need to
On 9/3/19 1:56 PM, Kumar, Virendra wrote:
Here is simple query, I am running via function call. This statement
runs fine as SQL but when put in function as plpgsql it failes with
error below, when I ran second times in same session it succeeds:
We will need to see the function definition.
-
Type ID doesn't seem to be existing:
product_master_fdw=> select * from pg_type where oid=196609;
typname | typnamespace | typowner | typlen | typbyval | typtype | typcategory |
typispreferred | typisdefined | typdelim | typrelid | typelem | typarray |
typinput | typoutput | typreceive | t
ypsen
Here is simple query, I am running via function call. This statement runs fine
as SQL but when put in function as plpgsql it failes with error below, when I
ran second times in same session it succeeds:
--
product_master_fdw=> \set VERBOSITY verbose
product_master_fdw=>
select sddf_update.tps_upd
On 9/2/19 5:52 PM, Adrian Klaver wrote:
It's still creating the schema elements when it fails, it hasn't
started linking yet
Alright at least you still a working 9.6 cluster .
Not sure where to go from here. Like you I am not sure how it can CREATE
EXTENSION and not actually follow through o
I think I would expect this behavior with how you have defined the
constraints as the function results rather than just being strict
comparisons to the timestamp field.
Instead of this-
Check constraints:
> "y2018_mis_ora_check" CHECK (date_part('year'::text, mis_ora) =
> 2018::double precisio
>
> CREATE STATISTICS MT_ReservationDepartureUtc (ndistinct) on "AccountCode",
> "DepartureUtc" from "Reservation"."Reservation";
> CREATE STATISTICS MT_ReservationArrivalUtc (ndistinct) on "AccountCode",
> "ArrivalUtc" from "Reservation"."Reservation";
> CREATE STATISTICS MT_ReservationNoShowFeeId
> On Sep 3, 2019, at 7:06 AM, Arnaud L. wrote:
>
> Le 03/09/2019 à 15:43, Tom Lane a écrit :
>> "Arnaud L." writes:
>>> We have upgraded our database from 9.6 to 11 (and updated PostGIS from 2.3
>>> to 2.5 as well).
>>> ...
>> Have you re-ANALYZEd the database? The problem with this query
>
Hi Jehan,
Thanks for your quick response.
Standby is built from the primary using pg_basebackup. i.e. Initial copy of
the primary database is taken with pg_basebackup command and then restarted
the server.
Regards,
Nagendra
On Tue, Sep 3, 2019 at 8:43 PM Jehan-Guillaume (ioguix) de Rorthais <
iog.
> We have upgraded our database from 9.6 to 11
This is now the latest PG ? PG11.5?
( for example - in PG11.5 fixed: * "Fix failure to resolve deadlocks
involving multiple parallel worker processes"*
https://www.postgresql.org/docs/current/release-11-5.html )
> populated by the osm2pgsql program
On Tue, 3 Sep 2019 20:27:37 +0530
Nagendra Bandi wrote:
...
> *Problem Description :*
>
> PostgreSQL database is set up for High Availability and *asynchronous
> streaming replication* with *hot standby* as described in
> https://www.postgresql.org/docs/9.4/warm-standby.html#STREAMING-REPLICATION
Le 03/09/2019 à 17:02, Imre Samu a écrit :
> We have upgraded our database from 9.6 to 11
This is now the latest PG ? PG11.5?
Yes, PostgreSQL 11.5, compiled by Visual C++ build 1914, 64-bit.
- the osm2pgsql has an own parallelizations ... ( osm2pgsql
--number-processes .. )
so be c
Le 03/09/2019 à 16:39, Paul Ramsey a écrit :
On Sep 3, 2019, at 7:06 AM, Arnaud L. wrote:
I've setup parallel_tuple_cost to 1.0 parallel_setup_cost to 5000.0 for the
time being which solves this specific problem. These value don't look very
sensible though, they are very high compared to the d
Le 03/09/2019 à 15:43, Tom Lane a écrit :
"Arnaud L." writes:
We have upgraded our database from 9.6 to 11 (and updated PostGIS from
2.3 to 2.5 as well).
...
Have you re-ANALYZEd the database? The problem with this query
seems to be the spectacularly awful rowcount estimate here:
You mean
"Arnaud L." writes:
> We have upgraded our database from 9.6 to 11 (and updated PostGIS from
> 2.3 to 2.5 as well).
> ...
Have you re-ANALYZEd the database? The problem with this query
seems to be the spectacularly awful rowcount estimate here:
>-> Bitmap Index Scan on planet_osm_ways_nod
Hi list
We have upgraded our database from 9.6 to 11 (and updated PostGIS from
2.3 to 2.5 as well).
We are using it among other things to store an OpenStreetMap database,
populated by the osm2pgsql program and updated on a daily basis.
The process used to take ~1h30 minutes before the upgrade
<<
On Sun, 1 Sep 2019 at 13:45, Thiemo Kellner
wrote:
> Quoting Olivier Gautherot :
>
> This is the specific error message:
>
>>
>> Could not execute the SQL command.
>> Message returned: ERROR: column pr.proisagg does not exist
>> LINE 1: ...namespace AS ns ON pr.pronamespace
On Tue, Sep 3, 2019 at 9:57 AM Matthias Apitz wrote:
> 2019-09-03 09:18:46.024 CEST [25388] LOG: Logdatei
> »00010001008F« aus Archiv wiederhergestellt
> ***> cp: der Aufruf von stat für
> '/data/postgresql11/wal_archive/000100010090' ist nicht möglich:
> Datei ode
Thank you so much, the "stable" thing was it.
I'm not sure if it is underdocumented, i clearly didn't adhere to the rule
that a stable function " is guaranteed to return the same results given the
same arguments for all rows within a single statement".
BTW in my example i made a mistake too, but th
Now we backup the cluster:
$ pg_basebackup -Usisis -Ft -D /data/postgresql11/backup-20190903-1
$ ls -l /data/postgresql11/backup-20190903-1
insgesamt 6379972
-rw--- 1 postgres postgres 6509913088 3. Sep 09:02 base.tar
-rw--- 1 postgres postgres 16779264 3. Sep 09:02 pg_wal.tar
$ ls -l /data/postgresql
30 matches
Mail list logo
