Re: Unable to compile postgres 13.1 on Slackware current x64

On Tue, Nov 17, 2020 at 8:02 PM Condor wrote: > I try to compile postgres again with (cd src/backend/commands; sed > 's/TRUE/true/' collationcmds.c > collationcmds.c; ) and it's compiled > but get new error on linking: Doesn't that produce an empty file collationcmds.c? I think you want: sed 's/

Re: Unable to compile postgres 13.1 on Slackware current x64

On 17-11-2020 11:00, Thomas Munro wrote: On Tue, Nov 17, 2020 at 8:02 PM Condor wrote: I try to compile postgres again with (cd src/backend/commands; sed 's/TRUE/true/' collationcmds.c > collationcmds.c; ) and it's compiled but get new error on linking: Doesn't that produce an empty file coll

Re: I have just downloaded Postgre SQL and "pgadmin 4" doesn't open.

On 11/16/20 9:30 PM, Ecenur Corlu wrote:   It is Windows 10  too. Given that this is the same OS and essentially the same hardware as the other machine, I would be investigating the state of the other machine in general. Ecenur Corlu mailto:corluece...@gmail.com>>, 17 Kas 2020 Sal, 08:2

RE: Race condition with restore_command on streaming replica

Dilip Kumar wrote on 2020/11/15 04:47:12 AM: > I am not sure how Patroni does it internally, can you explain the > scenario in more detail? Suppose you are executing the promote on m-1 > and if the promotion is successful it will switch the timeline and it > will create the timeline history file

Re: I have just downloaded Postgre SQL and "pgadmin 4" doesn't open.

Thank you so much for your time and help Mr Klaver. I will try to investigate it as I keep learning about machines. With sincere thanks, Ece Adrian Klaver , 17 Kas 2020 Sal, 18:22 tarihinde şunu yazdı: > On 11/16/20 9:30 PM, Ecenur Corlu wrote: > >It is Windows 10 too. > > Given that this

Re: Unable to compile postgres 13.1 on Slackware current x64

On 2020-11-16 18:30, Tom Lane wrote: In this case, I see one use of the constant TRUE in collationcmds.c, but I wonder how come that's there given that we deprecated upper-case TRUE some time ago. In 2eb4a831e5fb5d8fc17e13aea56e04af3efe27b4, I intentionally left that there because it was the d

pg_upgrade of 11 -> 13: free(): invalid pointer

I’m continuing my upgrade journey, this time from 11 to 13, and the process is dying in the copy phase, always on the same DB: — Performing Upgrade -- Analyzing all rows in the new cluster ok Freezing all rows in the new clusterok Dele

Re: pg_upgrade of 11 -> 13: free(): invalid pointer

On 11/17/20 8:59 AM, Jeremy Wilson wrote: I’m continuing my upgrade journey, this time from 11 to 13, and the process is dying in the copy phase, always on the same DB: — Performing Upgrade -- Analyzing all rows in the new cluster ok Freezing all rows in th

Re: pg_upgrade of 11 -> 13: free(): invalid pointer

> On Nov 17, 2020, at 12:18 PM, Adrian Klaver wrote: > > On 11/17/20 8:59 AM, Jeremy Wilson wrote: > > Was this after a clean install of the corrected RPM’s? Yes, this is a fresh install of CentOS 8 and installed using the updated repo and RPMs.

Re: pg_upgrade of 11 -> 13: free(): invalid pointer

On Tue, Nov 17, 2020 at 11:59:10AM -0500, Jeremy Wilson wrote: > pg_restore: WARNING: terminating connection because of crash of another > server process > DETAIL: The postmaster has commanded this server process to roll back the > current transaction and exit, because another server process ex

Re: pg_upgrade of 11 -> 13: free(): invalid pointer

On Tue, Nov 17, 2020 at 02:44:47PM -0500, Bruce Momjian wrote: > On Tue, Nov 17, 2020 at 11:59:10AM -0500, Jeremy Wilson wrote: > > pg_restore: WARNING: terminating connection because of crash of another > > server process > > DETAIL: The postmaster has commanded this server process to roll back

Re: pg_upgrade of 11 -> 13: free(): invalid pointer

> On Nov 17, 2020, at 11:44 AM, Bruce Momjian wrote: > > On Tue, Nov 17, 2020 at 11:59:10AM -0500, Jeremy Wilson wrote: >> pg_restore: WARNING: terminating connection because of crash of another >> server process >> DETAIL: The postmaster has commanded this server process to roll back the >

pg_upgrade from 12 to 13 failes with plpython2

Hi all, trying to performe upgrade from 12 to 13 installed from Centos8 repo gives such error: cat loadable_libraries.txt could not load library "$libdir/plpython2": ERROR: could not access file "$libdir/plpython2": No such file or directory digging around: 1. drop extension plpythonu; ER

Re: pg_upgrade from 12 to 13 failes with plpython2

Hi, On Tue, 2020-11-17 at 21:00 +0100, Marcin Giedz wrote: > Hi all, trying to performe upgrade from 12 to 13 installed from > Centos8 repo gives such error: > > cat loadable_libraries.txt > could not load library "$libdir/plpython2": ERROR: could not access > file "$libdir/plpython2": No such

Re: pg_upgrade from 12 to 13 failes with plpython2

Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes: > On Tue, 2020-11-17 at 21:00 +0100, Marcin Giedz wrote: >> Hi all, trying to performe upgrade from 12 to 13 installed from >> Centos8 repo gives such error: >> >> cat loadable_libraries.txt >> could not load library "$libdir/plpython2": ERROR: could n

Re: pg_upgrade from 12 to 13 failes with plpython2

On 11/17/20 12:06 PM, Devrim Gündüz wrote: Hi, On Tue, 2020-11-17 at 21:00 +0100, Marcin Giedz wrote: Hi all, trying to performe upgrade from 12 to 13 installed from Centos8 repo gives such error: cat loadable_libraries.txt could not load library "$libdir/plpython2": ERROR: could not access f

Re: pg_upgrade from 12 to 13 failes with plpython2

Hi, On Tue, 2020-11-17 at 12:18 -0800, Adrian Klaver wrote: > This was announced where and when? https://www.postgresql.org/message-id/333f3aa334ba93019c75fffaec373f2bf4275d28.camel%40gunduz.org Regards, -- Devrim Gündüz Open Source Solution Architect, Red Hat Certified Engineer Twitter: @Devr

Re: autovacuum recommendations for Large tables

Hi Atul, On Tue, Nov 17, 2020 at 12:05 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Mon, Nov 16, 2020 at 3:57 PM Atul Kumar wrote: > >> I only have this one big table in the database of size 3113 GB with rows >> 7661353111. >> >> Right Now the autovacuum setting for that table

Re: pg_upgrade from 12 to 13 failes with plpython2

On 11/17/20 12:49 PM, Devrim Gündüz wrote: Hi, On Tue, 2020-11-17 at 12:18 -0800, Adrian Klaver wrote: This was announced where and when? https://www.postgresql.org/message-id/333f3aa334ba93019c75fffaec373f2bf4275d28.camel%40gunduz.org So to be clear what was dropped was plpythonu, which m

Re: pg_upgrade from 12 to 13 failes with plpython2

Hi, On Tue, 2020-11-17 at 13:18 -0800, Adrian Klaver wrote: > > https://www.postgresql.org/message-id/333f3aa334ba93019c75fffaec373f2bf4275d28.camel%40gunduz.org > > So to be clear what was dropped was plpythonu, which means > plpython2u. plpython3u still exists, correct? Right. Regards, -- D

Re: pg_upgrade from 12 to 13 failes with plpython2

Adrian Klaver writes: > It would be nice to mention this on --announce and here as this still > exists: > https://www.postgresql.org/docs/13/plpython-python23.html You're confusing what the source code can do (which is what the manual documents) versus what individual packagers choose to support

Re: autovacuum recommendations for Large tables

> > If it helps, I put together a few thoughts and own experience on a blog: > https://sites.google.com/gautherot.net/postgresql/vacuum > > > Hope you find it useful. > -- That URL does not work for me (not even https://sites.google.

Re: pg_upgrade from 12 to 13 failes with plpython2

On 11/17/20 1:23 PM, Tom Lane wrote: Adrian Klaver writes: It would be nice to mention this on --announce and here as this still exists: https://www.postgresql.org/docs/13/plpython-python23.html You're confusing what the source code can do (which is what the manual documents) versus what indi

Re: autovacuum recommendations for Large tables

Hi Rob, On Tue, Nov 17, 2020 at 10:24 PM Rob Sargent wrote: > If it helps, I put together a few thoughts and own experience on a blog: > https://sites.google.com/gautherot.net/postgresql/vacuum > > Hope you find it useful. > -- > > That URL does not work for me (not even > https://sites.google.c

create type with %type or %rowtype

Hello. It seems that I can not create a type with create type my_type as my_table%rowtype; or create type my_type as my_table.my_column%type; Correct? It seems to be a feature for plpgsql programing only, right? But wouldn't that be a good thing to be able to do? Or would it cause too many

Re: pg_upgrade from 12 to 13 failes with plpython2

Hi, On Tue, 2020-11-17 at 16:23 -0500, Tom Lane wrote: > You're confusing what the source code can do (which is what the > manual documents) versus what individual packagers choose to support. > The packagers frequently don't have a lot of choice in the matter; > once their platform drops python2

Re: pg_upgrade from 12 to 13 failes with plpython2

On 11/17/20 2:17 PM, Devrim Gündüz wrote: Hi, On Tue, 2020-11-17 at 16:23 -0500, Tom Lane wrote: You're confusing what the source code can do (which is what the manual documents) versus what individual packagers choose to support. The packagers frequently don't have a lot of choice in the matt

Re: create type with %type or %rowtype

On 11/17/20 2:12 PM, Post Gresql wrote: Hello. It seems that I can not create a type with create type my_type as my_table%rowtype; To me that is redundant as a table has a composite type already. or create type my_type as my_table.my_column%type; In plpgsql %type is effectively a placeh

PK issue: serial sequence needs updating

Running postgresql-12.2-x86_64-1_SBo on Slackware-14.2/x86_64. My restructed business database has populated tables, but the primary keys are not aware of the current maximum number since the table rows were added external to postgres and read in using psql. For example, I'm trying to add a new

Re: PK issue: serial sequence needs updating

On 11/17/20 3:46 PM, Rich Shepard wrote: Running postgresql-12.2-x86_64-1_SBo on Slackware-14.2/x86_64. My restructed business database has populated tables, but the primary keys are not aware of the current maximum number since the table rows were added external to postgres and read in using ps

Re: PK issue: serial sequence needs updating [RESOLVED]

On Tue, 17 Nov 2020, Adrian Klaver wrote: https://www.postgresql.org/docs/12/sql-altersequence.html ALTER SEQUENCE people_person_nbr_seq RESTART 485; Thanks, Adrian. I missed that page. Regards, Rich

Re: create type with %type or %rowtype

(resending to include the list) On Tue, Nov 17, 2020 at 3:12 PM Post Gresql wrote: > create type my_type as my_table%rowtype; > This would be redundant with existing behavior - all tables have a corresponding type already create type my_type as my_table.my_column%type; > What does the indirec

received immediate shutdown request caused cluster failover

Hi all There are 3 nodes in our prd db in patroni cluster, vm01 is leader, vm02 and vm03 are standby, vm01 received immediate shutdown request caused failover to vm02, after that vm03 received fast shutdown request As vm03 not in cluster so have to reinit vm03 What's the possible root caused vm

Re: pg_upgrade from 12 to 13 failes with plpython2

but my question still remains the same - what causes pg_upgrade failure - are functions the reason? what I did was to delete these 2 rows from pg_pltemplate as I thought this may help: postgres=# delete from pg_pltemplate where tmplname = 'plpython2u'; DELETE 1 postgres=# delete from pg_pltem

Re: create type with %type or %rowtype

On 2020-11-18 04:37, David G. Johnston wrote: (resending to include the list) On Tue, Nov 17, 2020 at 3:12 PM Post Gresql > wrote: create type my_type as my_table%rowtype; This would be redundant with existing behavior - all tables have a corresponding ty

Postgresql13-devel fails to install on centos 7

I am trying to install postgres13-devel on a centos 7 server. But I am getting this error message: Error: Package: postgresql13-devel-13.1-1PGDG.rhel7.x86_64 (pgdg13) Requires: llvm5.0-devel >= 5.0 After a bit of googling, and following these instructions