Re: Unable to compile postgres 13.1 on Slackware current x64

On 16-11-2020 22:18, Tom Lane wrote: I wrote: What's wrong with s/TRUE/true/ in get_icu_language_tag? I confirmed that that fixes the build with ICU 68.1, and pushed it. regards, tom lane Hello, I try to compile postgres again with (cd src/backend/commands; sed

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

It is Windows 10 too. Ecenur Corlu , 17 Kas 2020 Sal, 08:26 tarihinde şunu yazdı: > Yes it worked. > Intel (R) Core (TM) İ7-6700HQ CPU @2.60 Ghz 2.59 GHz - 16.0GB Ram- x64 > I downloaded 13.1 Version from here. > "https://www.enterprisedb.com/software-downloads-postgres > I'll work there.

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

Yes it worked. Intel (R) Core (TM) İ7-6700HQ CPU @2.60 Ghz 2.59 GHz - 16.0GB Ram- x64 I downloaded 13.1 Version from here. "https://www.enterprisedb.com/software-downloads-postgres I'll work there. Thank you. Ece Adrian Klaver , 17 Kas 2020 Sal, 08:13 tarihinde şunu yazdı: > On 11/16/20 8:59 PM,

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

On 11/16/20 8:59 PM, Ecenur Corlu wrote: Hello Mr. Klaver,  I couldn't solve the problem on my computer. I also download it from https://www.enterprisedb.com/downloads/postgres-postgresql-downloads  but nothing has

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

Hello Mr. Klaver, I couldn't solve the problem on my computer. I also download it from https://www.enterprisedb.com/downloads/postgres-postgresql-downloads but nothing has changed. I looked at system logs but I couldn't find the relevant error log. So, I downloaded PostgreSQL on somebody

RE: New "function tables" in V13 documentation

>From: Adrian Klaver >>On 11/15/20 9:00 AM, David G. Johnston wrote: > >> In hindsight it could have been handled better. Waiting longer at >> different points and making pronouncements on -announce to solicit >> feedback from people who don't follow -docs. That doesn't change the > Yes and at

Re: autovacuum recommendations for Large tables

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 is set to > >

Re: autovacuum recommendations for Large tables

Hi, Could you help me by explaining in simple words, as I am new to postgres. What value of which parameter should I set and why. 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 is set to

Re: Unable to compile postgres 13.1 on Slackware current x64

I wrote: > What's wrong with s/TRUE/true/ in get_icu_language_tag? I confirmed that that fixes the build with ICU 68.1, and pushed it. regards, tom lane

Re: autovacuum recommendations for Large tables

https://www.postgresql.org/docs/13/routine-vacuuming.html Regards Andreas Am 11/16/2020 um 6:38 PM schrieb Atul Kumar: > Hi, > > I have a large table having no. of live tuples approx 7690798868 and > no. of dead tuples approx 114917737. > > So Please share autovacuum tuning recommendations for

Re: Unable to compile postgres 13.1 on Slackware current x64

I wrote: > A larger issue is that it looks like ICU68 may insist on importing > in some headers. That's fine on the platforms where we > use anyway, but it's distinctly not fine elsewhere. Meh. I went to see if I could test that, and didn't get much further than this on ICU's downloads page:

Re: Unable to compile postgres 13.1 on Slackware current x64

Laurenz Albe writes: > On Mon, 2020-11-16 at 12:30 -0500, 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. I find it hard to believe that sprinkling "#include

Re: Unable to compile postgres 13.1 on Slackware current x64

On Mon, 2020-11-16 at 12:30 -0500, Tom Lane wrote: > Thomas Munro writes: > > It looks like something happened to ICU's boolean macros . See this > > commit in FreeBSD ports: > > https://github.com/freebsd/freebsd-ports/commit/81a88b4506ec06d07be10d199170ef4003eb0e30 > > It'd be so nice if

autovacuum recommendations for Large tables

Hi, I have a large table having no. of live tuples approx 7690798868 and no. of dead tuples approx 114917737. So Please share autovacuum tuning recommendations for this table so that our time can be spent better than repeatedly vacuuming large tables. Please help. Regards, Atul

Re: Unable to compile postgres 13.1 on Slackware current x64

Thomas Munro writes: > It looks like something happened to ICU's boolean macros . See this > commit in FreeBSD ports: > https://github.com/freebsd/freebsd-ports/commit/81a88b4506ec06d07be10d199170ef4003eb0e30 It'd be so nice if people would tell us about their problems, instead of just

Re: Unable to compile postgres 13.1 on Slackware current x64

On Mon, 2020-11-16 at 22:17 +1300, Thomas Munro wrote: > On Mon, Nov 16, 2020 at 10:10 PM Laurenz Albe > wrote: > > > On Mon, 2020-11-16 at 09:15 +0200, Condor wrote: > > > collationcmds.c: In function ‘get_icu_language_tag’: > > > collationcmds.c:467:51: error: ‘TRUE’ undeclared (first use in

Re: "invalid record length" after restoring pg_basebackup

Dennis Jacobfeuerborn writes: > On 11/13/20 4:02 PM, Tom Lane wrote: >> This looks quite normal to me. If you'd pulled the power plug on the >> primary system at the time you made this backup, you would likely see >> the same message at the end of its crash recovery. Some sort of >>

Re: Unable to compile postgres 13.1 on Slackware current x64

On 16-11-2020 11:10, Laurenz Albe wrote: On Mon, 2020-11-16 at 09:15 +0200, Condor wrote: unable to compile Postgresql 13.0 and 13.1 on Slackware current x64. Here is gcc -v: Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/9.3.0/specs COLLECT_GCC=gcc

psycopg3 COPY support

Hello, I have written an article describing the new COPY support available in psycopg3: it is a big improvement to what is available in psycopg2, allowing COPY from a stream of Python objects, async operations, binary copy. You can find it at

Re: "invalid record length" after restoring pg_basebackup

On 11/13/20 4:02 PM, Tom Lane wrote: > Dennis Jacobfeuerborn writes: >> All of this works fine and the logs report that the db reaches a >> consistent recovery state but as last entry it reports an "invalid >> record length": > > This looks quite normal to me. If you'd pulled the power plug on

Logical replication gradually slowing down, then hanging.

Hello, I'm encountering a repeating problem with logical replication. The issue began occurring right after upgrading the cluster from 10.x to 13.x. There are two databases - `mc` and `comm` - within the same cluster. Few tables are replicated logically from `mc` to `comm`. The problem is

Re: Unable to compile postgres 13.1 on Slackware current x64

On Mon, Nov 16, 2020 at 10:10 PM Laurenz Albe wrote: > On Mon, 2020-11-16 at 09:15 +0200, Condor wrote: > > collationcmds.c: In function ‘get_icu_language_tag’: > > collationcmds.c:467:51: error: ‘TRUE’ undeclared (first use in this > > function); did you mean ‘IS_TRUE’? > >467 |

Re: Unable to compile postgres 13.1 on Slackware current x64

On Mon, 2020-11-16 at 09:15 +0200, Condor wrote: > unable to compile Postgresql 13.0 and 13.1 on Slackware current x64. > Here is gcc -v: > > Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/9.3.0/specs > COLLECT_GCC=gcc >