PG16 and replication, ensure a clean switchover after a stop of the primary server

primary server, * postgres-2 the warm standby server. It's a detail but on these servers, PGDATA=/pg_data/pginc and the UniX account and superuser is "pginc". There is continuous WAL archiving via the /pg_archives/pginc/ NFS share mounted on postgres-1 and postgres-2. My goal is to

Re: array_agg() does not stop aggregating according to HAVING clause

On Sat, 17 Aug 2024, Tom Lane wrote: Well, yes: the two aggregates (array_agg and count) are computed concurrently in a single Aggregate plan node scanning the output of the JOIN. There's no way to apply the HAVING filter until after the aggregation is finished. I think this approach is basica

Re: array_agg() does not stop aggregating according to HAVING clause

. There's no way to apply the HAVING filter until after the aggregation is finished. I think this approach is basically forced by the SQL standard's semantics for grouping/aggregation. > How do I tell postgres to stop aggregating when count>=10? The only way to do this would be to

array_agg() does not stop aggregating according to HAVING clause

ay to examine the temporary files written). While this query is going through billions of rows, the ones with infrequent datatags are maybe 10M. How do I tell postgres to stop aggregating when count>=10? Thank you in advance, Dimitris

No Greek stop words in FTS ?

nvoice descriptions etc. The results are fairly good, but as I was trying to experiment with adding some more domain-specific stopwords, I realised there’s no greek.stop under $(pg_config —sharedir)/tsearch_data And indeed looks like stop words are maintained with to_tsvector(‘greek’, ..). select to_ts

Re: stop

On 5/14/23 08:38, Sandeep Kumar Jakkaraju wrote: STOP THIS NON SENSE> I HAVE FACED MANY OF INSULTS JUST FOR SENDING JOKES IN MAIL THIS IS BULL  SHIT ... Calm down. 1) If this thread is not one you are interested in then ignore it. 2) The purpose of the thread is to provide information

Re: stop

On 5/14/23 08:49, Ron wrote: On 5/14/23 10:36, Tom Lane wrote: [snip] Another way is to visit the List-Unsubscribe: link that appears in the headers of every mail sent out by the postgresql mail list servers. That requires knowing about a feature which requires knowing that such features even

Re: stop

ne 14. 5. 2023 v 17:49 odesílatel Ron napsal: > > On 5/14/23 10:36, Tom Lane wrote: > [snip] > > Another way is to visit the > > List-Unsubscribe: link that appears in the headers of every mail sent > > out by the postgresql mail list servers. > > That requires knowing about a feature which requir

Re: stop

On 5/14/23 10:36, Tom Lane wrote: [snip] Another way is to visit the List-Unsubscribe: link that appears in the headers of every mail sent out by the postgresql mail list servers. That requires knowing about a feature which requires knowing that such features even exist.  (How many people thin

Re: stop

STOP THIS NON SENSE> I HAVE FACED MANY OF INSULTS JUST FOR SENDING JOKES IN MAIL THIS IS BULL SHIT ... On Sun, May 14, 2023 at 9:06 PM Tom Lane wrote: > Adrian Klaver writes: > > On 5/13/23 23:50, Rahul Chordiya wrote: > >> unsub > > > Go to: > > https:

Re: stop

Adrian Klaver writes: > On 5/13/23 23:50, Rahul Chordiya wrote: >> unsub > Go to: > https://lists.postgresql.org/ That may not help, if the OP never set up a postgresql.org web account, or has forgotten his password. Another way is to visit the List-Unsubscribe: link that appears in the headers

Re: stop

Ok, no problem. On Sun, May 14, 2023 at 8:48 PM Adrian Klaver wrote: > On 5/14/23 08:14, Sandeep Kumar Jakkaraju wrote: > > Isn't this spamming 🤔 > > No just someone lost on how to unsubscribe from the list. > > > > > On Sun, 14 May, 2023, 20:38 Adrian Klaver, >

Re: stop

On 5/14/23 08:14, Sandeep Kumar Jakkaraju wrote: Isn't this spamming 🤔 No just someone lost on how to unsubscribe from the list. On Sun, 14 May, 2023, 20:38 Adrian Klaver, > wrote: On 5/13/23 23:50, Rahul Chordiya wrote: > unsub Go to: h

Re: stop

Isn't this spamming 🤔 On Sun, 14 May, 2023, 20:38 Adrian Klaver, wrote: > On 5/13/23 23:50, Rahul Chordiya wrote: > > unsub > > Go to: > > https://lists.postgresql.org/ > > -- > Adrian Klaver > adrian.kla...@aklaver.com > > > >

Re: stop

On 5/13/23 23:50, Rahul Chordiya wrote: unsub Go to: https://lists.postgresql.org/ -- Adrian Klaver adrian.kla...@aklaver.com

stop

unsub

Re: The logfile stop upgrade after a vim write

> On 04/05/2023 11:54 CEST lz ma wrote: > > 1. pg_ctl -D data -l MyLog > 2. vim MyLog : add some words, save and exit > 3. after vim operation, MyLog will never upgrade except restart server > I know it caused by file descripter only open once at the start by postgres, > and vim operation rename t

The logfile stop upgrade after a vim write

1. pg_ctl -D data -l MyLog 2. vim MyLog : add some words, save and exit 3. after vim operation, MyLog will never upgrade except restart server I know it caused by file descripter only open once at the start by postgres, and vim operation rename the file to MyLog~, so postgres can't up

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

On 9/14/22 23:27, Tom Lane wrote: Looks to me like you made the same mistake as Bryn. You revoked the permission in the postgres database: You are right. When I do it correctly, "revoke execute" works. Thanks for taking time to show me the errors of my wicked ways. Regards -- Mladen Gogala

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

Bryn Llewellyn writes: > I just confirmed that, if it suits me, I can revoke "execute" from "public" > on all overloads of the humble length() function. Maybe I should refer to it > as "pg_catalog.length()" to emphasize another point that had escaped me. Yup. For even more fun, try revoking pr

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> gogala.mla...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> I'll use "kill" here a shorthand for using the "pg_terminate_backend()" >> built-in function. I read about it in the "Server Signaling Functions" >> section of the enclosing "System Administration Functions" section of the >>

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

Mladen Gogala writes: > ... This doesn't look like a big problem because > applications usually don't contain code for killing other user's > sessions. I am not sure that GTA is running on top of Postgres database. Yeah, I meant to comment on that further but forgot. I don't particularly buy t

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

Mladen Gogala writes: > Tom, I did the same thing on 14.5, and it behaves as Bryn alleges: Looks to me like you made the same mistake as Bryn. You revoked the permission in the postgres database: > postgres=# select proacl from pg_proc where proname = > 'pg_terminate_backend'; >   

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

On 9/13/22 00:49, Tom Lane wrote: Bryn Llewellyn writes: My non-superuser normalrole with direct login, "u1", is *still* able to invoke pg_terminate_backend() and kill other "u1" sessions—even after this (as a super-user): Really? I did this in 14.5: regression=# revoke execute on function

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

On 9/12/22 18:51, Bryn Llewellyn wrote: I'll use "kill" here a shorthand for using the "pg_terminate_backend()" built-in function. I read about it in the "Server Signaling Functions" section of the enclosing "System Administration Functions" section of the current doc: www.postgresql.org/docs/

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

Am Wed, Sep 14, 2022 at 10:10:30AM +0200 schrieb Karsten Hilbert: > Am Tue, Sep 13, 2022 at 05:10:58PM -0400 schrieb Tom Lane: > > > (I recall that somewhere we have some code that warns about no-op > > grants. I wonder if issuing a warning for no-op revokes would be > > helpful.) > > Surely, in

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

Am Tue, Sep 13, 2022 at 05:10:58PM -0400 schrieb Tom Lane: > (I recall that somewhere we have some code that warns about no-op > grants. I wonder if issuing a warning for no-op revokes would be > helpful.) Surely, in the light of security a no-op revoke is potentially more dangerous than a no-op

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

Le mer. 14 sept. 2022 à 00:35, Bryn Llewellyn a écrit : > > *guilla...@lelarge.info wrote:* > This won't answer your question > > > It has been answered now. See my "case closed" email here: > > > www.postgresql.org/message-id/B33C40D9-2B79-44C7-B527-86E672BEA71A%40yugabyte.com > > …but still… I

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> guilla...@lelarge.info wrote: > > This won't answer your question It has been answered now. See my "case closed" email here: www.postgresql.org/message-id/B33C40D9-2B79-44C7-B527-86E672BEA71A%40yugabyte.com > …but still… I usually really like your scripts, it's nicely written, but this > par

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

imple case... Guilty as charged. Sorry. I was too focuses on what I wanted to achieve: to stop sessions connected as "r1" killing other sessions connected as "r1". > but looking through it, it appears that you revoked permissions to > pg_terminate_backend in the postgres da

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role? >> CASE CLOSED

x...@thebuild.com wrote: > >> t...@sss.pgh.pa.us wrote: >> >> Perhaps you'd already revoked from public in this database? > > Very possible! You all forgot to tell me to put this aside and go out for a walk. I just told myself to do that. And it struck me then. Tom just said it here—albeit pa

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> On Sep 13, 2022, at 14:10, Tom Lane wrote: > > Perhaps you'd already revoked from public in this database? Very possible!

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

Christophe Pettus writes: > It works correctly for me, on MacOS: > swift-239:~ xof$ psql > psql (14.5) > Type "help" for help. > xof=# create user r1; > CREATE ROLE > xof=# revoke execute on function pg_terminate_backend from r1; > REVOKE > xof=# > \q > swift-239:~ xof$ psql -U r1 xof > psql (1

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

I say this only to emphasize that there are always things that are critical > that are elided in a testcase that tries to be minimal. > > So it seems that there's something critical about my env that I'm failing > to tell you all. But what can it be? > > Removing permissions also works for me. In

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

Hi, This won't answer your question but still... I usually really like your scripts, it's nicely written, but this part seems really weird to me: Le mar. 13 sept. 2022 à 20:23, Bryn Llewellyn a écrit : > > > > > > > > > > > > > > > > > > *-- No errordo $body$declare p int not null := 0;begin

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> x...@thebuild.com wrote: > >> b...@yugabyte.com wrote: >> >> What are you seeing that I'm failing to? > > It works correctly for me, on MacOS: > > create user r1; > revoke execute on function pg_terminate_backend from r1; > > (reconnect as r1) > > select pg_terminate_backend(123); > > ERRO

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> On Sep 13, 2022, at 11:39, Bryn Llewellyn wrote: > > What are you seeing that I'm failing to? It works correctly for me, on MacOS: swift-239:~ xof$ psql psql (14.5) Type "help" for help. xof=# create user r1; CREATE ROLE xof=# revoke execute on function pg_terminate_backend from r1; REVOK

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> x...@thebuild.com wrote: > >> b...@yugabyte.com wrote: >> >> There must be some-or-other non-standard setting in my environment that >> results in the behavior that I see and that other's don't. > > From the documentation: > >> superuser status: A database superuser bypasses all permission c

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> On Sep 13, 2022, at 11:23, Bryn Llewellyn wrote: > > There must be some-or-other non-standard setting in my environment that > results in the behavior that I see and that other's don't. From the documentation: > superuser status > A database superuser bypasses all permission checks,

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> t...@sss.pgh.pa.us wrote: > >> b...@yugabyte.com wrote: >> >> My non-superuser normalrole with direct login, "u1", is *still* able to >> invoke pg_terminate_backend() and kill other "u1" sessions—even after this >> (as a super-user): > > Really? I did this in 14.5: > > revoke execute on fu

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

Bryn Llewellyn writes: > I can't agree with you about risks and probability, though. The general > literature of security threats often makes the point that disgruntled > employees (current or very recently former) who know the code in question do > sometimes wreak havoc—sometimes just for spor

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

Bryn Llewellyn writes: > My non-superuser normalrole with direct login, "u1", is *still* able to > invoke pg_terminate_backend() and kill other "u1" sessions—even after this > (as a super-user): Really? I did this in 14.5: regression=# revoke execute on function pg_terminate_backend from pub

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

x...@thebuild.com wrote: > > b...@yugabyte.com wrote: >> >> The implication is that every client program must follow every database call >> with defensive code to detect error "57P01" and programmatically re-try. > > That situation exists even without the ability for a role to kill other > ses

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> On Sep 12, 2022, at 20:44, Bryn Llewellyn wrote: > Version 16? Thus might be the clue, then. It behaves as David describes on: PostgreSQL 14.5 on x86_64-apple-darwin19.6.0, compiled by Apple clang version 12.0.0 (clang-1200.0.32.29), 64-bit

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> david.g.johns...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> revoke execute on function pg_terminate_backend(int, bigint) from public; > > I just did this very thing in v16 (head-ish) and it worked as expected, > preventing the non-superuser role from executing the function: > > Ses

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

On Mon, Sep 12, 2022 at 6:08 PM Bryn Llewellyn wrote: > > *revoke execute on function pg_terminate_backend(int, bigint) from public;* > I just did this very thing in v16 (head-ish) and it worked as expected, preventing the non-superuser role from executing the function: Session 1 - superuser po

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> david.g.johns...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> …I'm troubled by the notion that (as it seems) one session that authorizes >> as the role "r1" can easily list all other concurrent sessions that are also >> authorized as "r1"—and kill them all without restriction. (The do

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

> On Sep 12, 2022, at 15:51, Bryn Llewellyn wrote: > The implication is that every client program must follow every database call > with defensive code to detect error "57P01" and programmatically re-try. That situation exists even without the ability for a role to kill other sessions author

Re: Is it possible to stop sessions killing eachother when they all authorize as the same role?

On Mon, Sep 12, 2022 at 3:51 PM Bryn Llewellyn wrote: > I'll use "kill" here a shorthand for using the "pg_terminate_backend()" > built-in function. I read about it in the "Server Signaling Functions" > section of the enclosing "System Administration Functions" section of the > current doc: > > w

Is it possible to stop sessions killing eachother when they all authorize as the same role?

I'll use "kill" here a shorthand for using the "pg_terminate_backend()" built-in function. I read about it in the "Server Signaling Functions" section of the enclosing "System Administration Functions" section of the current doc: www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADM

Re: Full text search - wildcard and a stop word

Allan Jardine writes: > => select to_tsquery('all:*'); > NOTICE: text-search query contains only stop words or doesn't contain > lexemes, ignored > to_tsquery > > (1 row) > I get why that is happening - the notification basically details it,

Full text search - wildcard and a stop word

Hi all, I'm venturing into full text search in Postgres for the first time, and I'd like to be able to do a search by the start of a word - so I used the `:*` operator. However, this doesn't operate as I'd expect with a stop word - for example, my name is "Allan&quo

Re: Regex for (A) and (B) to find in Bus Stop (A) or (B)

On Wednesday, November 3, 2021, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Wednesday, November 3, 2021, Shaozhong SHI > wrote: > >> What is the regex for (A) and (B) to find in Bus Stop (A) or (B)? >> > > Not tested… > > ^Bus\sStop\s\(

Re: Regex for (A) and (B) to find in Bus Stop (A) or (B)

On Wednesday, November 3, 2021, Shaozhong SHI wrote: > What is the regex for (A) and (B) to find in Bus Stop (A) or (B)? > Not tested… ^Bus\sStop\s\((\w)\)\sor\((\w)\)$ The \s can just written as a space though the above seems clearer in email (though it allows for non-space whitespa

Regex for (A) and (B) to find in Bus Stop (A) or (B)

What is the regex for (A) and (B) to find in Bus Stop (A) or (B)? Regards, David

Regex for (A) and (B) to find in Bus Stop (A) or (B)

What is the regex for (A) and (B) to find in Bus Stop (A) or (B)? Regards, David

Re: Database system was interrupted. Possible reasons for a database to suddenly stop accepting connections?

On Mon, 2020-11-09 at 13:53 +, Buzenets, Yuriy (GE Renewable Energy, consultant) wrote: If I delete all the noise from the log, file, this remains: > < 2020-10-29 11:51:59.345 PDT >STATEMENT: SELECT NULL AS TABLE_CAT, > n.nspname AS TABLE_SCHEM, [...] > < 2020-10-29 12:04:09.700 PDT >LOG:

Re: Database system was interrupted. Possible reasons for a database to suddenly stop accepting connections?

On 11/9/20 5:53 AM, Buzenets, Yuriy (GE Renewable Energy, consultant) wrote: Some time ago the database at my work suddenly stopped accepting connections. In the logs there was a message “the database system was interrupted; last known up at 2020-10-29 12:03:16 PDT”, followed by a lot of “the d

Database system was interrupted. Possible reasons for a database to suddenly stop accepting connections?

Some time ago the database at my work suddenly stopped accepting connections. In the logs there was a message "the database system was interrupted; last known up at 2020-10-29 12:03:16 PDT", followed by a lot of "the database system is starting up" messages. It seems like the database tried to r

Re: New Role drop with Grant/Revokes stop working after subsequent runs

Greetings, * David G. Johnston (david.g.johns...@gmail.com) wrote: > On Wed, May 6, 2020 at 5:05 PM AC Gomez wrote: > > I suppose the main question is, why would a bunch of grant and revoke > > commands run and not do anything, not even throw an error? > > Maybe its a bug? - I doubt this kind of

Re: New Role drop with Grant/Revokes stop working after subsequent runs

On Wed, May 6, 2020 at 5:05 PM AC Gomez wrote: > We have developed some code that creates a new role to be used as the main > role for DB usage. This code will be called on a predetermined frequency to > act a role/pwd rotation mechanism. > > Each time the code is run we feed it the prior role t

New Role drop with Grant/Revokes stop working after subsequent runs

Hi, On PostgreSQL 9.6. We have developed some code that creates a new role to be used as the main role for DB usage. This code will be called on a predetermined frequency to act a role/pwd rotation mechanism. Each time the code is run we feed it the prior role that was created (the Db owner bein

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

On Fri, Feb 22, 2019 at 2:03 AM Tom Lane wrote: > Bruce Momjian writes: > > On Thu, Feb 21, 2019 at 09:31:32PM -0500, Stephen Frost wrote: > >> * Bruce Momjian (br...@momjian.us) wrote: > >>> There was too much concern that users would accidentally start the old > >>> server at some later point,

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

Bruce Momjian writes: > On Thu, Feb 21, 2019 at 09:31:32PM -0500, Stephen Frost wrote: >> * Bruce Momjian (br...@momjian.us) wrote: >>> There was too much concern that users would accidentally start the old >>> server at some later point, and its files would be hard linked to the >>> new live serv

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

On Thu, Feb 21, 2019 at 09:31:32PM -0500, Stephen Frost wrote: > Greetings, > > * Bruce Momjian (br...@momjian.us) wrote: > > On Tue, Feb 19, 2019 at 12:25:24PM -0500, Stephen Frost wrote: > > > Ah, right, I forgot that it did that, fair enough. > > > > > > I've never been thrilled with that part

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Feb 19, 2019 at 12:25:24PM -0500, Stephen Frost wrote: > > Ah, right, I forgot that it did that, fair enough. > > > > I've never been thrilled with that particular approach due to the > > inherent risks of people messing directly with

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

On Tue, Feb 19, 2019 at 12:25:24PM -0500, Stephen Frost wrote: > Ah, right, I forgot that it did that, fair enough. > > I've never been thrilled with that particular approach due to the > inherent risks of people messing directly with files like pg_control, > but that's how it is for now. There w

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

Greetings, * Martín Fernández (fmarti...@gmail.com) wrote: > On Tue, Feb 19, 2019 at 1:37 PM Stephen Frost wrote: > > * Martín Fernández (fmarti...@gmail.com) wrote: > > > Thanks for information! I've refactor our migration scripts to follow > > the suggestions. > > > > Please don't top-post on t

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

Stephen, @bilby91 On Tue, Feb 19, 2019 at 1:37 PM Stephen Frost wrote: > Greetings, > > * Martín Fernández (fmarti...@gmail.com) wrote: > > Thanks for information! I've refactor our migration scripts to follow > the suggestions. > > Please don't top-post on these mailing lists. > > > One extra

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

Greetings, * Martín Fernández (fmarti...@gmail.com) wrote: > Thanks for information! I've refactor our migration scripts to follow the > suggestions.  Please don't top-post on these mailing lists. > One extra question that popped up. As long as we don't start the standby > (after running rsync

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

d both the primary and the standby >> are down and the instructions in the pg_upgrade docs are followed. >> >> > arracar master >> > hot standby start >> >> So, start both the primary and the replica?  That part should be fine by >> itself. >> &g

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

th a hot standby > > The above should be alright provided both the primary and the standby > are down and the instructions in the pg_upgrade docs are followed. > > > arracar master > > hot standby start > > So, start both the primary and the replica? That part should be fine

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

followed. > arracar master > hot standby start So, start both the primary and the replica? That part should be fine by itself. > stop hot standby and rsync the other hot standby with the migrated hot > standby? At some later point, shut down the replica completely, then do an rsync fro

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

Hi But could you do the following procedure?: pg_upgrade of the master rysnc with a hot standby arracar master hot standby start stop hot standby and rsync the other hot standby with the migrated hot standby? El mar., 19 de feb. de 2019 a la(s) 06:12, Stephen Frost (sfr...@snowman.net) escribió

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

Greetings, * Martín Fernández (fmarti...@gmail.com) wrote: > After reading the pg_upgrade documentation multiple times, it seems that > after running pg_upgrade on the primary instance, we can't start it until we > run rsync from the primary to the standby. I'm understanding this from the > fol

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

ade.html > > Usage > (...) > 7. Stop both servers > (...) > 10. Upgrade Streaming Replication and Log-Shipping standby servers > (...) > 12. Start the new server > > *The new server can now be safely started, and then any rsync'ed standby > servers.* > >

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

Hola Martin Pues si uno sigue la secuencia de la pagina de ayuda de PostgreSQL https://www.postgresql.org/docs/10/pgupgrade.html Usage (...) 7. Stop both servers (...) 10. Upgrade Streaming Replication and Log-Shipping standby servers (...) 12. Start the new server *The new server can now be

Re: PG Upgrade with hardlinks, when to start/stop master and replicas

Martín Fernández wrote: > After reading the pg_upgrade documentation multiple times, it seems that > after running pg_upgrade on the primary instance, we can't start it until we > run rsync from the primary to the standby. I'm understanding this from the > following section in the pg_upgrade man

PG Upgrade with hardlinks, when to start/stop master and replicas

Hello everyone! We are about to upgrade a 6 instance cluster from pg92 to pg10 using pg_upgrade with hardlinks and rsync. Our preliminary tests are working really good so far but on question has popped up that we feel is really critical because it has an important impact on our failover plan.

Re: How can I stop a long run pgAgent job?

As said, terminating a backend is the current way to kill a job. An alternative if this is something you do often: https://github.com/GoSimpleLLC/jpgAgent jpgAgent supports terminating a job by issuing a NOTIFY command on the correct channel like this: NOTIFY jpgagent_kill_job, 'job_id_here'; It w

Re: How can I stop a long run pgAgent job?

Hi Shore, Have a look at: https://www.postgresql.org/docs/current/static/functions-admin.html 'pg_terminate_backend' is probably what you are looking for regards, fabio pardi On 21/06/18 11:32, a wrote: > Hi  > > I'm using pgAdmin 4, pgAgent and postgresql 10 on windows server. > > I tried a

How can I stop a long run pgAgent job?

Hi I'm using pgAdmin 4, pgAgent and postgresql 10 on windows server. I tried a job but due to some reasons, its running long time. Is there a way that I can terminate it ?? Thanks Shore

Re: Pg Upgrade failing as it is not able to start and stop server properly

Guru Prashanth Thanakodi writes: > pg_ctl start and stop commands are hanging in a Windows environment. Can i > enable some debug logs to understand the root cause of the issue? You could try cranking log_min_messages all the way up to "debug5" in postgresql.conf, but I'm no

Re: Pg Upgrade failing as it is not able to start and stop server properly

Hi All pg_ctl start and stop commands are hanging in a Windows environment. Can i enable some debug logs to understand the root cause of the issue? Thanks Guru Thanks, Guru On Thu, Jan 4, 2018 at 8:54 PM, Bruce Momjian wrote: > On Thu, Jan 4, 2018 at 01:49:17PM +0530, kiran gadamse

Re: Pg Upgrade failing as it is not able to start and stop server properly

On Thu, Jan 4, 2018 at 01:49:17PM +0530, kiran gadamsetty wrote: > While upgrading the PostgreSQL database from 9.1.4 to 9.6.4 version on > windows 2012 server, Pg_upgrade is failing as postgre service start and > stop are failing because of time outs. I got the information

Re: Pg Upgrade failing as it is not able to start and stop server properly

tgre service start and > stop are failing because of time outs. I got the information as using -m > immediate mode with solve the problem, but we are interested to know the > root cause of this issue. > Without -m immediate, the server start and stop commands will simply wait, > ti