On Mon, Feb 10, 2020 at 4:35 AM Marc wrote:
> We will keep the 12.1 in place so that we can run additional tests to assist
> to pin-point the issue.
>
> Feel free to ask but allow us to recover from these hectic days ;-)
Here's how to get a stack so we can see what it was doing, assuming
you hav
On 2/10/20 4:07 PM, Rich Shepard wrote:
On Mon, 10 Feb 2020, Adrian Klaver wrote:
What it is saying is -b and -d are pointing at binary and data
directories
that are incompatible. You need to make sure that:
/usr/lib64/postgresql/11/bin/
and
/var/lib/pgsql/11/data
are actually pointing at 11
Marc writes:
> Adrian, Christoph, Tom,
>
> We identified as the problem being persistent on all tables with many
> records ( +600K ) and they all had a JSONB column ( we feel that
> might be related )
Did you remember to re-analyze all tables after importing the data?
Autovac probably will have
On Mon, 10 Feb 2020, Adrian Klaver wrote:
What it is saying is -b and -d are pointing at binary and data directories
that are incompatible. You need to make sure that:
/usr/lib64/postgresql/11/bin/
and
/var/lib/pgsql/11/data
are actually pointing at 11 instances of binaries and data respective
On 2/10/20 3:40 PM, Rich Shepard wrote:
On Mon, 10 Feb 2020, Rich Shepard wrote:
Good advice; I'll do that.
Huh! Not what I expected:
postgres@salmo:~$ pg_upgrade -c -b /usr/lib64/postgresql/11/bin/ -B
/usr/lib64/postgresql/12/bin/ -d /var/lib/pgsql/11/data -D
/var/lib/pgsql/12/data/
(All o
On Mon, 10 Feb 2020, Rich Shepard wrote:
Good advice; I'll do that.
Huh! Not what I expected:
postgres@salmo:~$ pg_upgrade -c -b /usr/lib64/postgresql/11/bin/ -B
/usr/lib64/postgresql/12/bin/ -d /var/lib/pgsql/11/data -D
/var/lib/pgsql/12/data/
(All on one line; wrapped by alpine.)
Performi
On Mon, 10 Feb 2020, Adrian Klaver wrote:
I don't know that the port numbers are required.
They are not: https://www.postgresql.org/docs/12/pgupgrade.html
"Obviously, no one should be accessing the clusters during the upgrade.
pg_upgrade defaults to running servers on port 50432 to avoid uninte
On 2/10/20 1:59 PM, Rich Shepard wrote:
Running Slackware-14.2/x86_64. Current installation is postgres-11.5 and
I'm
upgrading to postgresql-12.1. Both versions are installed and stopped.
If I have correctly read the pg_upgrade manual page this is the command to
use (as user postgres) with line
On Mon, 10 Feb 2020, Rich Shepard wrote:
-B /usr/lib64/postgesql/12/bin/ \
Typo: it should be /usr/lib64/postgresql/12/bin/
Rich
Running Slackware-14.2/x86_64. Current installation is postgres-11.5 and I'm
upgrading to postgresql-12.1. Both versions are installed and stopped.
If I have correctly read the pg_upgrade manual page this is the command to
use (as user postgres) with lines split to fit the message; the command wi
No, as I said, as per my observation your connection will not use your
work mem unless there is a sort happening,
but
Yes, every connection uses certain amount of RAM, some documents say it 5
MB and some say it is 1.9 MB.
Expert review may be needed on my observation.
On Mon, 10 Feb, 2020,
Thanks, for q2 - if work_mem is a limit before spilling onto disk, is there
a min amount of memory which gets allocated to each session when it starts?
On Mon, Feb 10, 2020 at 3:51 AM Naresh g wrote:
> 1. Yes, by default it is advisable to set 25% of RAM to shared buffers
> because community ve
1. Yes, by default it is advisable to set 25% of RAM to shared buffers
because community version postgres highly depends on OS cache, which means
when you fetch something from disk, it is first copied to OS cache (75%)
then to shared buffers(25%).
Two copies of data will be there in your system R
1. shared_buffers - In a regular PostgreSQL installation, say I am
allocating 25% of my memory to shared_buffers that means it leaves 75% for
rest such as OS, page cache and work_mems etc. Is my understanding correct?
If so, AWS Aurora for Postgres uses 75% of memory for shared_buffers,
14 matches
Mail list logo
