pg_upgrade 10.2
In older versions of pg_upgrade (e.g from 9.2 to 9.3), I was able to run pg_upgrade without stopping old cluster using the check flag. pg_upgrade -b -B -d -D -p 5432 -P 5434 -r -v -k -c Note the "c" flag at the end However pg_upgrade in 10 (I tried from 9.3 to 10.4), when I did not stop the old cluster, the upgrade failed: *** There seems to be a postmaster servicing the old cluster. Please shutdown that postmaster and try again. Failure, exiting Is this expected? Also, when I stopped the old cluster and ran pg_upgrade with "-c" flag, the file global/pg_control got renamed to global/pg_control.old. The "-c" flag never renamed anything in the old cluster in older pg_upgrade
RE: pg_upgrade 10.2
Thanks Adrian. I removed "-k" flag. But still got same error. There seems to be a postmaster servicing the old cluster. Please shutdown that postmaster and try again. Failure, exiting -Original Message- From: Adrian Klaver [mailto:adrian.kla...@aklaver.com] Sent: Tuesday, June 12, 2018 3:48 PM To: Murthy Nunna ; pgsql-general@lists.postgresql.org; pgsql-ad...@lists.postgresql.org; pgsql-performa...@lists.postgresql.org Subject: Re: pg_upgrade 10.2 On 06/12/2018 01:34 PM, Murthy Nunna wrote: > In older versions of pg_upgrade (e.g from 9.2 to 9.3), I was able to > run pg_upgrade without stopping old cluster using the check flag. > > pg_upgrade -b -B -d -D -p > 5432 -P 5434 -r -v -k -c > > Note the "c" flag at the end I take the below to it mean it should work: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.postgresql.org_docs_10_static_pgupgrade.html&d=DwID-g&c=gRgGjJ3BkIsb5y6s49QqsA&r=0wrsmPzpZSao0v32yCcG2Q&m=g2e1NMngBLIcEgi5UjlCHkyJ5zK1Su-vsaRw0Y9N0Dc&s=PDVmjA_uW6cJvV4lWR8vgkiArplzgd5Rs4taLA6ZY6Q&e= > "You can use pg_upgrade --check to perform only the checks, even if > the old server is still running. pg_upgrade --check will also outline any manual adjustments you will need to make after the upgrade. If you are going to be using link mode, you should use the --link option with --check to enable link-mode-specific checks." Might want to try without -k to see what happens. More comments below. > However pg_upgrade in 10 (I tried from 9.3 to 10.4), when I did not > stop the old cluster, the upgrade failed: > > *** > > There seems to be a postmaster servicing the old cluster. > > Please shutdown that postmaster and try again. > > Failure, exiting > > Is this expected? > > Also, when I stopped the old cluster and ran pg_upgrade with "-c" > flag, the file global/pg_control got renamed to global/pg_control.old. > The "-c" flag never renamed anything in the old cluster in older > pg_upgrade Again seems related to -k: " If you ran pg_upgrade without --link or did not start the new server, the old cluster was not modified except that, if linking started, a .old suffix was appended to $PGDATA/global/pg_control. To reuse the old cluster, possibly remove the .old suffix from $PGDATA/global/pg_control; you can then restart the old cluster. " > -- Adrian Klaver adrian.kla...@aklaver.com
RE: pg_upgrade 10.2
pg_upgrade -V
pg_upgrade (PostgreSQL) 10.4
pg_upgrade -b /fnal/ups/prd/postgres/v9_3_14_x64/Linux-2-6/bin -B
/fnal/ups/prd/postgres/v10_4_x64/Linux-2-6/bin -d /data0/pgdata/ifb_prd_last -D
/data0/pgdata/ifb_prd_last_104 -p 5433 -P 5434 -r -v –c
-Original Message-
From: Adrian Klaver [mailto:adrian.kla...@aklaver.com]
Sent: Tuesday, June 12, 2018 4:13 PM
To: Murthy Nunna ; pgsql-general@lists.postgresql.org;
pgsql-ad...@lists.postgresql.org; pgsql-performa...@lists.postgresql.org
Subject: Re: pg_upgrade 10.2
On 06/12/2018 01:58 PM, Murthy Nunna wrote:
> Thanks Adrian.
> I removed "-k" flag. But still got same error.
>
> There seems to be a postmaster servicing the old cluster.
> Please shutdown that postmaster and try again.
> Failure, exiting
>
Well according to the code in pg_upgrade.c that message should not be reached
when the check option is specified:
if (!user_opts.check)
pg_fatal("There seems to be a postmaster servicing the old cluster.\n"
"Please shutdown that postmaster and try again.\n"); else
*live_check = true;
Can we see the actual command you ran?
--
Adrian Klaver
adrian.kla...@aklaver.com
RE: pg_upgrade 10.2
Hi Adrian, Port numbers are correct. I moved the position of -c (-p 5433 -P 5434 -c -r -v). Now it is NOT complaining about old cluster running. However, I am running into a different problem. New cluster database "ifb_prd_last" is not empty Failure, exiting Note: ifb_prd_last is not new cluster. It is actually old cluster. Is this possibly because in one of my earlier attempts where I shutdown old cluster and ran pg_upgrade with -c at the end of the command line. I think -c was ignored and my cluster has been upgraded in that attempt. Is that possible? -Original Message- From: Adrian Klaver [mailto:adrian.kla...@aklaver.com] Sent: Tuesday, June 12, 2018 4:35 PM To: Murthy Nunna ; pgsql-general@lists.postgresql.org; pgsql-ad...@lists.postgresql.org; pgsql-performa...@lists.postgresql.org Subject: Re: pg_upgrade 10.2 On 06/12/2018 02:18 PM, Murthy Nunna wrote: > pg_upgrade -V > pg_upgrade (PostgreSQL) 10.4 > > pg_upgrade -b /fnal/ups/prd/postgres/v9_3_14_x64/Linux-2-6/bin -B > /fnal/ups/prd/postgres/v10_4_x64/Linux-2-6/bin -d > /data0/pgdata/ifb_prd_last -D /data0/pgdata/ifb_prd_last_104 -p 5433 > -P 5434 -r -v –c > > Looks good to me. The only thing that stands out is that in your original post you had: -p 5432 and above you have: -p 5433 Not sure if that makes a difference. The only suggestion I have at the moment is to move -c from the end of the line to somewhere earlier on the chance that there is a bug that is not finding it when it's at the end. -- Adrian Klaver adrian.kla...@aklaver.com
RE: pg_upgrade 10.2
Jerry, OMG, I think you nailed this... I know what I did. I cut/pasted the command from an e-mail... I have seen this issue before with stuff not related to postgres. But then those commands failed in syntax error and then you know what you did wrong. Similarly, I expect pg_upgrade to throw an error if it finds something it doesn't understand instead of ignoring and causing damage. Don't you agree? Thanks for pointing that out. I will redo my upgrade. -r -v -k -c --- good flags no utf8 -r -v -k –c --- bad flags -Original Message- From: Jerry Sievers [mailto:gsiever...@comcast.net] Sent: Tuesday, June 12, 2018 6:24 PM To: Murthy Nunna Cc: Adrian Klaver ; pgsql-general@lists.postgresql.org; pgsql-ad...@lists.postgresql.org; pgsql-performa...@lists.postgresql.org Subject: Re: pg_upgrade 10.2 Murthy Nunna writes: > Hi Adrian, > > Port numbers are correct. > > I moved the position of -c (-p 5433 -P 5434 -c -r -v). Now it is NOT > complaining about old cluster running. However, I am running into a different > problem. I noted in your earlier message the final -c... the dash was not a regular 7bit ascii char but some UTF or whatever dash char. I wonder if that's what you fed your shell and it caused a silent parsing issue, eg the -c dropped. But of course email clients wrap and mangle text like that all sorts of fun ways so lordy knows just what you originally sent :-) FWIW > > New cluster database "ifb_prd_last" is not empty Failure, exiting > > Note: ifb_prd_last is not new cluster. It is actually old cluster. > > Is this possibly because in one of my earlier attempts where I > shutdown old cluster and ran pg_upgrade with -c at the end of the > command line. I think -c was ignored and my cluster has been upgraded > in that attempt. Is that possible? > > > -Original Message- > From: Adrian Klaver [mailto:adrian.kla...@aklaver.com] > Sent: Tuesday, June 12, 2018 4:35 PM > To: Murthy Nunna ; > pgsql-general@lists.postgresql.org; pgsql-ad...@lists.postgresql.org; > pgsql-performa...@lists.postgresql.org > Subject: Re: pg_upgrade 10.2 > > On 06/12/2018 02:18 PM, Murthy Nunna wrote: >> pg_upgrade -V >> pg_upgrade (PostgreSQL) 10.4 >> >> pg_upgrade -b /fnal/ups/prd/postgres/v9_3_14_x64/Linux-2-6/bin -B >> /fnal/ups/prd/postgres/v10_4_x64/Linux-2-6/bin -d >> /data0/pgdata/ifb_prd_last -D /data0/pgdata/ifb_prd_last_104 -p 5433 >> -P 5434 -r -v –c >> >> > > Looks good to me. The only thing that stands out is that in your original > post you had: > > -p 5432 > > and above you have: > > -p 5433 > > Not sure if that makes a difference. > > The only suggestion I have at the moment is to move -c from the end of the > line to somewhere earlier on the chance that there is a bug that is not > finding it when it's at the end. > > > -- > Adrian Klaver > adrian.kla...@aklaver.com -- Jerry Sievers Postgres DBA/Development Consulting e: postgres.consult...@comcast.net p: 312.241.7800
psql help
Hello:
Following works-
SELECT pid, pg_terminate_backend(pid) FROM pg_stat_activity
WHERE pid IN (select unnest(pg_blocking_pids(pid)) from pg_stat_activity
where cardinality(pg_blocking_pids(pid)) > 0)
and usename = 'DBUSER_10'
and now() - state_change >= interval $a'${TIMEOUT_MINS}'$a
order by now() - state_change >= interval
$a'${TIMEOUT_MINS}'$a desc limit 1;
How can I rewrite the above in psql and pg_terminate_backend all pids that
meet above criteria (essentially remove limit 1) ?
Thanks!
Note:
I run this in Linux. TIMEOUT_MINS is env variable.
RE: psql help
Sorry, there is no problem with the following statement and the environment
variable. It works fine. But it terminates only one PID due to LIMIT 1. I want
to terminate all pids that meet this criteria. If I remove LIMIT 1,
pg_terminate_backend(pid) will not work as it expects only one pid at a time.
So, the question is how to rewrite this psql so it loops through all pids one
pid at a time? Thanks in advance for your help.
SELECT pid, pg_terminate_backend(pid) FROM pg_stat_activity
WHERE pid IN (select unnest(pg_blocking_pids(pid)) from pg_stat_activity
where cardinality(pg_blocking_pids(pid)) > 0)
and usename = 'DBUSER_10'
and now() - state_change >= interval $a'${TIMEOUT_MINS}'$a
order by now() - state_change >= interval
$a'${TIMEOUT_MINS}'$a desc limit 1;
From: David G. Johnston
Sent: Thursday, July 4, 2024 8:17 PM
To: Murthy Nunna
Cc: pgsql-general@lists.postgresql.org
Subject: Re: psql help
[EXTERNAL] – This message is from an external sender
On Thu, Jul 4, 2024 at 4:56 PM Murthy Nunna
mailto:mnu...@fnal.gov>> wrote:
How can I rewrite the above in psql
The only real trick is using a psql variable instead of the shell-injection of
the environment variable. Use the --set CLI argument to assign the environment
variable to a psql variable then refer to it in the query using :'timout_mins'
Removing the limit 1 should be as simple as not typing limit 1 when you bring
the query into the psql script.
David J.
RE: psql help
-Original Message-
From: dep...@depesz.com
Sent: Friday, July 5, 2024 6:05 AM
To: Murthy Nunna
Cc: pgsql-general@lists.postgresql.org
Subject: Re: psql help
[EXTERNAL] – This message is from an external sender
On Fri, Jul 05, 2024 at 03:54:56AM +, Murthy Nunna wrote:
> Sorry, there is no problem with the following statement and the environment
> variable. It works fine. But it terminates only one PID due to LIMIT 1. I
> want to terminate all pids that meet this criteria. If I remove LIMIT 1,
> pg_terminate_backend(pid) will not work as it expects only one pid at a time.
> So, the question is how to rewrite this psql so it loops through all pids one
> pid at a time? Thanks in advance for your help.
>
> SELECT pid, pg_terminate_backend(pid) FROM pg_stat_activity
> WHERE pid IN (select unnest(pg_blocking_pids(pid)) from pg_stat_activity
> where cardinality(pg_blocking_pids(pid)) > 0)
> and usename = 'DBUSER_10'
> and now() - state_change >= interval $a'${TIMEOUT_MINS}'$a
> order by now() - state_change >= interval
> $a'${TIMEOUT_MINS}'$a desc limit 1;
Did you try?
I don't see any reason why it wouldn't work with just 'limit 1' removed.
Best regards,
depesz
Thanks, depesz. I am pretty sure removing “limit 1” should terminate all pids
in the result set. I was just being dumb.
RE: Bash function from psql (v14)
Thanks, Greg. 1. This means what I am trying to do is not meant to work. This won’t work even if I declare the function before calling it in PSQL. I get it. 2. You are correct. Function must be declared before the call. Thanks again.
Bash function from psql (v14)
Hi,
I am trying to code bash function and call it from psql. But it is failing. How
can I get this to work. Creating a separate script instead of a function works,
but I do not want to do that. I have too many variables to be passed back and
forth. Any ideas?
#!/bin/bash
psql -d postgres -p 5433 <<-PSQLBLOCK
\! run-bash-function-- This doesn't work
PSQLBLOCK
# Run the function outside PSQLBLOCK. This works!
run-bash-function
exit $?
# Create bash function
run-bash-function ()
{
echo "in bash function"
}
# end of bash script
Run the above script:
./test-bash-function.sh
sh: line 1: run-bash-function: command not found
in bash function
