Thiemo Kellner, NHC Barhufpflege wrote:
> > What do you have your log levels set to?
>
> Thanks for pointing this out. I put client level to debug1. So, I am
> just lucky not to have got flooded with Messages?
Sort of. This is a normal operation and should not worry you.
Yours,
Laurenz Albe
--
Zitat von Adrian Klaver :
What do you have your log levels set to?
Thanks for pointing this out. I put client level to debug1. So, I am
just lucky not to have got flooded with Messages?
--
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu/pks/lookup?op=get&search=0x8F70EFD2D972CBEF
-
Zitat von Paul Jungwirth :
I think you are looking for `WITH ORDINALITY` (in pg 9.4+). For
instance you could rewrite your first CTE like so:
Thanks for the hint.
Kind regards
--
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu/pks/lookup?op=get&search=0x8F70EFD2D972CBEF
-
Zitat von "David G. Johnston" :
?It does not. If the array is not naturally ordered you will want to
attach a "with ordinality" clause to it for performing future ordering.
Thanks for the hints.
Kind regards
--
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu/pks/lookup?op=get&search=0x8F70
On Tue, Apr 17, 2018 at 02:57:03PM -0400, Tom Lane wrote:
> I think possibly the OP doesn't understand why it's designed that way.
> The point is not really to "recycle old WAL files", it's to avoid having
> disk space allocation occur during the critical section where we must
> PANIC on failure.
On Tue, Apr 17, 2018 at 05:11:10PM -0700, David G. Johnston wrote:
> Long-lived non-idle statements would likely be waiting for a lock to be
> released.
Be very careful with transactions marked as "idle in transaction" for a
long time. Long-running transactions prevent VACUUM to do its work as
th
On Tue, Apr 17, 2018 at 5:02 PM, Hans Sebastian wrote:
> Hello group,
>
> We run postgresql 10.3 for a python django app with gunicorn on nginx with
> django version 1.9.5.
>
> Recently, we started noticing there are many active connections from the
> django app server that are more than 1 week
On 04/17/2018 05:02 PM, Hans Sebastian wrote:
Hello group,
We run postgresql 10.3 for a python django app with gunicorn on nginx
with django version 1.9.5.
Recently, we started noticing there are many active connections from the
django app server that are more than 1 week old still showing i
Hello group,
We run postgresql 10.3 for a python django app with gunicorn on nginx with
django version 1.9.5.
Recently, we started noticing there are many active connections from the
django app server that are more than 1 week old still showing in
pg_stat_activity.
Even though the django server
On 04/17/2018 01:14 PM, Thiemo Kellner wrote:
Hi all
When running following query in psql (server and client version 10 with
replication on Debian 9), I get the message mentioned in the subject. I
have not found much searching the internet. There were suggestions on
bloat so I ran "vacuum (ve
On 04/17/2018 01:20 PM, Thiemo Kellner wrote:
I use UNNEST to get rows from array. This works fine but I am
not sure whether the ordering remains in the later use.
I think you are looking for `WITH ORDINALITY` (in pg 9.4+). For instance
you could rewrite your first CTE like so:
SELECT oid
On Tue, Apr 17, 2018 at 1:20 PM, Thiemo Kellner wrote:
> This works fine but I am not sure whether the ordering remains in the
> later use.
It does not. If the array is not naturally ordered you will want to
attach a "with ordinality" clause to it for performing future ordering.
select * fro
Hi all
I have created following statement to get the ordered parameter list of
functions. I use UNNEST to get rows from array. This works fine but I am
not sure whether the ordering remains in the later use. Background is
PL/pgSQL to revoke grants to get a pristine start for granting. As the
Hi all
When running following query in psql (server and client version 10 with
replication on Debian 9), I get the message mentioned in the subject. I
have not found much searching the internet. There were suggestions on
bloat so I ran "vacuum (verbose, full, analyze)" but the message remains.
On Tue, Apr 17, 2018 at 11:57 AM, Tom Lane wrote:
> Alvaro Herrera writes:
> > David Pacheco wrote:
> >> tl;dr: We've found that under many conditions, PostgreSQL's re-use of
> old
> >> WAL
> >> files appears to significantly degrade query latency on ZFS. The
> reason is
> >> complicated and I
Alvaro Herrera writes:
> David Pacheco wrote:
>> tl;dr: We've found that under many conditions, PostgreSQL's re-use of old
>> WAL
>> files appears to significantly degrade query latency on ZFS. The reason is
>> complicated and I have details below. Has it been considered to make this
>> behavior
David Pacheco wrote:
> tl;dr: We've found that under many conditions, PostgreSQL's re-use of old
> WAL
> files appears to significantly degrade query latency on ZFS. The reason is
> complicated and I have details below. Has it been considered to make this
> behavior tunable, to cause PostgreSQL t
tl;dr: We've found that under many conditions, PostgreSQL's re-use of old
WAL
files appears to significantly degrade query latency on ZFS. The reason is
complicated and I have details below. Has it been considered to make this
behavior tunable, to cause PostgreSQL to always create new WAL files
i
On 04/16/2018 11:47 PM, vaibhav zaveri wrote:
Hi,
Yes that is the link.
But is JDK 1.8 supported by PostgreSQL??
I believe it one of those version numbering things, per:
https://en.wikipedia.org/wiki/Java_version_history#Versioning_change
"Versioning change
This version introduced a new ver
On 04/17/2018 12:35 AM, Ron wrote:
On 04/16/2018 11:07 PM, Adrian Klaver wrote:
On 04/16/2018 06:43 PM, Ron wrote:
More promising would be the suggestion from Michael Nolan:
https://www.postgresql.org/message-id/CAOzAqu%2BVpOfzBHwcqptSzm3PkeZAjkqqc0XqB%2BA-jBNioU6x%2Bg%40mail.gmail.com
from the pg_dump docs...
...
-Z 0..9
--compress=0..9
Specify the compression level to use. Zero means no compression. For the
custom archive format, this specifies compression of individual table-data
segments, and the default is to compress at a moderate level. For plain text
output, setti
Zitat von Pavel Stehule :
no. The :xxx is not evaluated inside string. The workaround is using GUC
variables and related functions. Can be used from psql and from plpgsql too.
Hi Pavel, thanks for pointing this out. However, I implemented another
solution with dedicated PostgreSQL user where
Zitat von Adrian Klaver :
In addition to my previous suggestions:
test=# SELECT public.dblink_connect('dbname=production ');
dblink_connect
OK
test=# select * from public.dblink('show search_path') as
t1(search_path text);
search_path
-
main
test=# select
Hi Ron,
I have some pg_dump test result, for reference only 😊
--
[ENV]
Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz | SSD 120GB | 8G memory
(PostgreSQL) 9.6.8
--
[DATA]
my database has 7.2GB of random data:
postgres=# select pg_size_pretty(pg_database_size('postgres'));
pg_size_pretty
-
Bob Jones wrote:
> My current thinking is that the filter is a bit like an "fgrep" and
> the sort actually requires memory allocation and some "real work", and
> thus I've settled on the filter for now pending experiments with a
> larger quantity of data.
That's fine.
A top-1-sort is less work th
On 04/16/2018 11:07 PM, Adrian Klaver wrote:
On 04/16/2018 06:43 PM, Ron wrote:
On 04/16/2018 07:18 PM, Adrian Klaver wrote:
On 04/16/2018 04:58 PM, Ron wrote:
We're upgrading from v8.4 to 9.6 on a new VM in a different DC. The
dump file will be more than 1TB, and there's not enough disk sp
Hi,
yes, supported.
> If you are using Java 8 or newer then you should use the JDBC 4.2
version. <
If you are using Java 7 then you should use the JDBC 4.1 version.
If you are using Java 6 then you should use the JDBC 4.0 version.
If you are using a Java version older than 6 then you w
>
> At a short glance, I'd say that they are pretty much the same.
> The filter and the top-1-sort will both require a single scan through
> the result set and one operation per row found.
> And the recursive queries are pretty similar, right?
>
> Yours,
> Laurenz Albe
> --
> Cybertec | https://www
vaibhav zaveri schrieb am 17.04.2018 um 08:47:
> Hi,
>
> Yes that is the link.
> But is JDK 1.8 supported by PostgreSQL??
>
Postgres itself does not need or "support" Java.
Only the JDBC driver needs that which is a client-side technology.
And yes, the JDBC driver does support Java 8, which
29 matches
Mail list logo
