Hello,
The problem Joe spotted is that a variable name is misspelled in one
> place. It should (probably) be external_complete_id, not
> _external_complete_id).
Oh, copy-paste issue :-)
> > better solution proposal?
>
> I think you can make that clearer by using IS [NOT] DISTINCT FROM:
>
>
is the issue/better solution proposal?
Kind regards Ales Zeleny
čt 4. 8. 2022 v 23:15 odesílatel Joe Conway napsal:
> On 8/4/22 08:34, Aleš Zelený wrote:
> >> SELECT ... simple join of two tables...
> >> WHERE opd.id_data_provider = _id_data_provider
> >>AND
Hello,
thanks for the information and the link!
Ales
čt 4. 8. 2022 v 1:05 odesílatel Tom Lane napsal:
> =?UTF-8?B?QWxlxaEgWmVsZW7DvQ==?= writes:
> > CREATE OR REPLACE FUNCTION tescase (_id_data_provider integer,
> _external_id
> > bigint DEFAULT NULL::bigint, _external_complete_id character
Hello,
I did some testing and the result is that on pg12 there are no such
problems. Pg13 and Pg 14.3 tests will follow but based on monitoring
processed RssAnon memory, I've found a correlation that only processes by a
single user are suffering from the memory allocation (it looks to be a
memory
Hello,
po 18. 7. 2022 v 21:04 odesílatel Tom Lane napsal:
> =?UTF-8?B?QWxlxaEgWmVsZW7DvQ==?= writes:
> > postgres=# show shared_buffers ;
> > shared_buffers
> >
> > 10GB
> > (1 row)
>
> Oh! In that case, there is absolutely nothing to see here.
> This chunk:
>
> >
po 18. 7. 2022 v 16:25 odesílatel Tom Lane napsal:
> =?UTF-8?B?QWxlxaEgWmVsZW7DvQ==?= writes:
> > after some time, I've found a process consuming over 1GB of memory"
> > -bash-4.2$ grep RssAnon /proc/*/status | sort -nk2 | tail
> > /proc/17048/status:RssAnon: 1053952 kB
>
> > Here are memory
Hello,
čt 14. 7. 2022 v 23:31 odesílatel Aleš Zelený
napsal:
>
>
> Dne čt 14. 7. 2022 23:11 uživatel Tomas Vondra <
> tomas.von...@enterprisedb.com> napsal:
>
>>
>>
>> On 7/14/22 21:25, Aleš Zelený wrote:
>> >
>> > st 13. 7
Dne čt 14. 7. 2022 23:11 uživatel Tomas Vondra <
tomas.von...@enterprisedb.com> napsal:
>
>
> On 7/14/22 21:25, Aleš Zelený wrote:
> >
> > st 13. 7. 2022 v 2:20 odesílatel Michael Paquier > <mailto:mich...@paquier.xyz>> napsal:
> >
> > On
st 13. 7. 2022 v 2:20 odesílatel Michael Paquier
napsal:
> On Mon, Jul 11, 2022 at 10:50:23AM +0200, Aleš Zelený wrote:
> > So far, it has happened three times (during a single week) from the 14.3
> ->
> > 14.4 upgrade, before 14.4 we haven't suffered from such an issue.
>
Hello,
po 11. 7. 2022 v 14:47 odesílatel Pavel Stehule
napsal:
> Hi
>
> It's looks like memory leak
>
As we are collecting some data for Postgres processes, I've found processes
using Rss Anonymous memory allocations:
Some examples:
2022-07-08T14:50:24+0200 Name: postmaster Pid: 31522
Hello,
we are experiencing out-of-memory issues after Postygres upgrade from 14.3
to 14.4 on CentOS7.
OS: CenotOS7
No OOM killer messages in the syslog. SWAP is disabled.
-bash-4.2$ sysctl -q vm.overcommit_memory
vm.overcommit_memory = 2
[root@sts-uat-pgsql100 ~]# swapon -vs
Hello,
we have suffered from BUG #17485, so we have upgraded our databases to 14.4.
When (on 14.3 we discovered the issue all affected indexes were rebuilt
[not concurrently]), so subsequent pg_amcheck --heapallindexed was without
errors or warnings.
After the upgrade to 14.4, we run pg_amcheck
e, is there a way to fix it?
Thanks Ales
út 24. 5. 2022 v 21:58 odesílatel Thomas Munro
napsal:
> On Wed, May 25, 2022 at 6:17 AM Aleš Zelený wrote:
> > SELECT format('REINDEX SCHEMA CONCURRENTLY %I;', n.nspname)
>
> This may be related to bug #17485, discussed at:
>
>
> https://www.postgresql.org/message-id/flat/17485-396609c6925b982d%40postgresql.org
>
Thanks for the bug link, I haven't found it.
Ales
út 24. 5. 2022 v 21:58 odesílatel Thomas Munro
napsal:
> On Wed, May 25, 2022 at 6:17 AM Aleš Zelený wrote:
> > SELECT format('REINDEX SCHEMA CONCURRENTLY %I;', n.nspname)
>
> This may be related to bug #17485, discussed
Hello,
we have a problem with an index on a database we recently upgraded from
PG13 to Pg14.3 using pg_upgrade. After all the upgrade steps including
analyze in stages, we run "vacuumdb -Fvaz -j 8" and the user workload was
started afterward.
In order to get one of the Pg14 benefits (b-tree
Hello,
I've found in our server ( PostgreSQL 13.5 on x86_64-pc-linux-gnu, compiled
by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit ) following error:
2022-03-31 09:29:58 CEST [15490]: [1-1]
user=app,db=main,host=192.168.1.231,app=[unknown] ERROR: could not access
status of transaction
Hi Adrian,
thanks for the hint!
Ales
st 24. 11. 2021 v 18:16 odesílatel Adrian Klaver
napsal:
> On 11/24/21 08:47, Aleš Zelený wrote:
> > Hello all,
> >
> > I've found on the wiki ( https://wiki.postgresql.org/wiki/Packagers
> > <https://wiki
Hello all,
I've found on the wiki ( https://wiki.postgresql.org/wiki/Packagers ) that
the packagers list Is closed, so the first question is how to properly
report a package issue?
Particularly I've realized, that in the repository list
/etc/yum.repos.d/pgdg-redhat-all.repo provided by
Hello,
we are using PostgreSQL 12.4 on CentOS 7. The hot standby failed:
2021-04-24 09:19:27 CEST [20956]: [747-1] user=,db=,host=,app= LOG:
recovery restart point at 3D8C/352B4CE8
2021-04-24 09:19:27 CEST [20956]: [748-1] user=,db=,host=,app= DETAIL:
Last completed transaction was at log time
Thanks for the explanation!
We are still not using ICU, so the reindex (endians - based on what I've
found about Graviton ARM64 cpu are same, but no information about datatype
alignment) will be a pain, so if we really opt for the platform we can give
it a try, but generally I'll expect restoring
Hello,
is it supported to restore binary backup (pg_basebackup) taken on an amd64
platform on arm64 while using the same PostgreSQL version?
I'd like to know, whether there is binary file compatibility to save time
needed for dump & restore migration scenario or all the complexity of using
to build reproducible testcase.
Thanks Ales
po 8. 6. 2020 v 8:41 odesílatel Michael Paquier
napsal:
> On Fri, Jun 05, 2020 at 10:57:46PM +0200, Aleš Zelený wrote:
> > we are using logical replication for more than 2 years and today I've
> found
> > new not yet know error message
Hello,
we are using logical replication for more than 2 years and today I've found
new not yet know error message from wal receiver. The replication was in
catchup mode (on publisher side some new tables were created and added to
publication, on subscriber side they were missing).
RDBMS
Hello,
we are using logical replication from PostgreSQL 10.8 (Ubuntu
10.8-1.pgdg14.04+1) to PostgreSQL 11.3 (Ubuntu 11.3-1.pgdg18.04+1). Thre
are 1305 replicated tables within 3 schemas. The tables are from small
almost static lookup tables to larger tables up to ~40GB holding 44
millions of
Hello,
we run out of disk space on our production primary database on file system
dedicated for WALs (one of our logical replica died and thus WALs were
accumulated).
As expeced, primary instance shuts down:
Primary instance:
PostgreSQL 11.3 (Ubuntu 11.3-1.pgdg18.04+1) on x86_64-pc-linux-gnu,
Hello,
I've learned that logical replication might have performance problem if
there are lot of sub transactions within transaction (at least because it
enforces spill files in pg_replslot and if there are many - like 80mio,
EXT4 did not perform well - in my case it was caused bu misuse of
Hello,
I've found an issue with logical replication causing
1) large memory allocation by wal sender process (RSS 60GB)
2) large amount of "xid" files in $PGDATA/pg_replslot/
directory - seems to be amount of rows handled by trigger + few more
Having several millions of files in a single
Hello,
we are using logical replication for half a year and now, when we were
adding new tables to replication, we have found a unexpected issue in log
file.
New tables were created on publication database (Ubuntu 16.04, PG 10.6) ,
subscription side is PostgreSQL 10.4 (Ubuntu 10.4-2.pgdg16.04+1)
ext round did not start at 18GB of WAL but only on
4GB of and finally get streaming state.
After the restart wal sender (having to process much less volume of WAL)
sucees to reach streaming state and it also consumes reasonable amount of
memory:
db:~$ ps -u -p 4232
USER PID %CPU %MEMVSZ
lsn.
Kind regards Ales
so 3. 11. 2018 v 17:02 odesílatel Jerry Sievers
napsal:
> Aleš Zelený writes:
>
> > Hello,
> >
> > we are suing logical replication on 10.4 and it now hangs. After
> > some timeout it is retarted again, replaying 18GB of data and then
> > ha
Hello,
we are suing logical replication on 10.4 and it now hangs. After some
timeout it is retarted again, replaying 18GB of data and then hangs (while
7GB of wals remains to be proceeded).
The backlog of 18GB comes from a failed migration adding new table to
replication while replication user
#: -1, OS Msg: , Level: 16
Time: 0.249 ms
The error is different, it looks tds_fdw is trying use bytea dat type fro
ASE query (guess).
That is what I was able to test.
Kind regards
Ales Zeleny
st 10. 10. 2018 v 15:30 odesílatel Adrian Klaver
napsal:
> On 10/10/18 1:31 AM, Aleš Zelený wro
. 2018 v 0:08 odesílatel Adrian Klaver
napsal:
> On 10/9/18 12:07 PM, Aleš Zelený wrote:
> > Hello,
> >
> > I've an issue with foreign table using tds_fdw from PostgreSQL 10 to
> > Sybase ASE 15.7.
> >
> > The issue is, that primary key, which I have to use for
Hello,
I've an issue with foreign table using tds_fdw from PostgreSQL 10 to Sybase
ASE 15.7.
The issue is, that primary key, which I have to use for my predicate is in
Sybase data type binary.
Foreign table maps ID column from Sybase binary to PostgreSQL BYTEA.
Simple select is smooth:
34 matches
Mail list logo
