Re: [HACKERS] Proposal: pg_rewind to skip config files

> 5 сент. 2017 г., в 15:48, Michael Paquier > написал(а): > > On Tue, Sep 5, 2017 at 9:40 PM, Vladimir Borodin wrote: >> We do compress WALs and send them over network. Doing it via archive_command >> in single thread is sometimes slower than new WALs are written unde

Re: [HACKERS] Proposal: pg_rewind to skip config files

> 5 сент. 2017 г., в 15:42, Chris Travers написал(а): > > On Tue, Sep 5, 2017 at 2:40 PM, Vladimir Borodin <mailto:r...@simply.name>> wrote: > >> 5 сент. 2017 г., в 14:04, Michael Paquier > <mailto:michael.paqu...@gmail.com>> написал(а): >> >&g

Re: [HACKERS] Proposal: pg_rewind to skip config files

> 5 сент. 2017 г., в 14:04, Michael Paquier > написал(а): > >> For example, in archive_command we put WALs for archiving from >> pg_xlog/pg_wal into another directory inside PGDATA and than another cron >> task makes real archiving. This directory ideally should be skipped by >> pg_rewind, but

Re: [HACKERS] Proposal: pg_rewind to skip config files

> 5 сент. 2017 г., в 12:31, Chris Travers написал(а): > > I think the simplest solution for now is to skip any files ending in .conf, > .log, and serverlog. Why don’t you want to solve the problem once? It is a bit harder to get consensus on a way how to do it, but it seems that there are no

Re: [HACKERS] Funny WAL corruption issue

Hi, Chris. > 10 авг. 2017 г., в 15:09, Chris Travers написал(а): > > Hi; > > I ran into a funny situation today regarding PostgreSQL replication and wal > corruption and wanted to go over what I think happened and what I wonder > about as a possible solution. > > Basic information is custom-

Re: [HACKERS] SCRAM auth and Pgpool-II

> 14 июля 2017 г., в 1:33, Stephen Frost написал(а): > > What would be really nice for such cases is support for Kerberos and > delegated Kerberos credentials. Having pgpool support that would remove > the need to deal with passwords at all. Since nearly all systems with some kind of load nowa

Re: [HACKERS] Broken hint bits (freeze)

> 12 июня 2017 г., в 13:19, Amit Kapila написал(а): > > On Sun, Jun 11, 2017 at 11:59 PM, Vladimir Borodin <mailto:r...@simply.name>> wrote: >> >> 8 июня 2017 г., в 17:03, Amit Kapila написал(а): >> >> On Thu, Jun 8, 2017 at 6:49 PM, Dmitriy Sar

Re: [HACKERS] Broken hint bits (freeze)

> 8 июня 2017 г., в 17:03, Amit Kapila написал(а): > > On Thu, Jun 8, 2017 at 6:49 PM, Dmitriy Sarafannikov > wrote: >> >>> Why didn't rsync made the copies on master and replica same? >> >> Because rsync was running with —size-only flag. >> > > IIUC the situation, the new WAL and updated p

Re: [HACKERS] Broken hint bits (freeze)

> 6 июня 2017 г., в 23:30, Sergey Burladyan написал(а): > > Dmitriy Sarafannikov writes: > >> Starting and stopping master after running pg_upgrade but before rsync to >> collect statistics >> was a bad idea. > > But, starting and stopping master after running pg_upgrade is *required* > by d

Re: [HACKERS] Broken hint bits (freeze)

> 27 мая 2017 г., в 19:56, Andres Freund написал(а): > > On 2017-05-27 19:48:24 +0300, Vladimir Borodin wrote: >> Well, actually clean shutdown of master with exit code 0 from `pg_ctl >> stop -m fast` guarantees that all WAL has been replicated to standby. > > It do

Re: [HACKERS] Broken hint bits (freeze)

> 26 мая 2017 г., в 21:39, Amit Kapila написал(а): > >> And LSN on replica is greater that LSN on master (838D/C4A0D280 > >> 8092/6A26DD08) >> How can this be possible? >> > > Yeah, I think this is quite suspicious. This seems to indicate that > not all WAL records are replicated before the

Re: [HACKERS] Broken hint bits (freeze)

> 26 мая 2017 г., в 23:04, Michael Paquier > написал(а): > > On Fri, May 26, 2017 at 2:39 PM, Amit Kapila wrote: >> Yeah, I think this is quite suspicious. This seems to indicate that >> not all WAL records are replicated before the switchover. What is the >> value of "synchronous_commit" yo

Re: [HACKERS] Broken hint bits (freeze)

> 24 мая 2017 г., в 15:44, Robert Haas написал(а): > > On Wed, May 24, 2017 at 7:27 AM, Dmitriy Sarafannikov > wrote: >> It seems like replica did not replayed corresponding WAL records. >> Any thoughts? > > heap_xlog_freeze_page() is a pretty simple function. It's not > impossible that it co

Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range

Hi. > 25 апр. 2017 г., в 18:13, Dmitriy Sarafannikov > написал(а): > > I'd like to propose to search min and max value in index with SnapshotAny in > get_actual_variable_range function. > Current implementation scans index with SnapshotDirty which accepts > uncommitted rows and rejects dead r

Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range

> 29 апр. 2017 г., в 17:34, Tom Lane написал(а): > > Dmitriy Sarafannikov writes: >>> Maybe we need another type of snapshot that would accept any >>> non-vacuumable tuple. I really don't want SnapshotAny semantics here, > >> If I understood correctly, this new type of snapshot would help if

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

> 6 февр. 2017 г., в 4:57, Peter Geoghegan написал(а): > > I meant that I find the fact that there were no user reports in all > these years to be a good reason to not proceed for now in this > instance. Well, we had some strange situations with indexes (see below for example) but I couldn’t e

Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

> 31 янв. 2017 г., в 9:50, Michael Paquier > написал(а): > > On Mon, Jan 30, 2017 at 4:28 PM, Andrew Borodin wrote: >> I'll summarize here my state of studying concurrent methods of page >> unlinking. >> >> GIN B-tree does not have "high key". That means, that rightmost key on >> a page is m

Re: [HACKERS] Checksums by default?

> 21 янв. 2017 г., в 18:18, Petr Jelinek > написал(а): > > On 21/01/17 11:39, Magnus Hagander wrote: >> Is it time to enable checksums by default, and give initdb a switch to >> turn it off instead? +1 > > I'd like to see benchmark first, both in terms of CPU and in terms of > produced WAL (

Re: [HACKERS] tzdata 2016j

> 6 дек. 2016 г., в 19:19, David Fetter написал(а): > > On Tue, Dec 06, 2016 at 10:52:47AM -0500, Tom Lane wrote: >> Vladimir Borodin writes: >>> Any chance to get tzdata 2016j in supported branches? >> >> When the next scheduled releases come around (Fe

[HACKERS] tzdata 2016j

Hi all. Any chance to get tzdata 2016j in supported branches? -- May the force be with you… https://simply.name

Re: [HACKERS] GIN non-intrusive vacuum of posting tree

> 28 нояб. 2016 г., в 20:31, Andrew Borodin написал(а): > > This patch solved a problem encountered by Evgeniy Efimkin and > Vladimir Borodin from Yandex.Mail. > > and eventually deleting some of data. This testbed showed VACUUM > holding inserts for up to tenths of sec

Re: [HACKERS] [PERFORM] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6

> 13 июня 2016 г., в 21:58, Vladimir Borodin написал(а): > >> >> 13 июня 2016 г., в 0:51, Andres Freund > <mailto:and...@anarazel.de>> написал(а): >> >> Hi Vladimir, >> >> Thanks for these reports. >> >> On 2016-06-13

Re: [HACKERS] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6

27 мая 2016 г., в 19:57, Vladimir Borodin <r...@simply.name> написал(а):-performance+hackers25 мая 2016 г., в 17:33, Vladimir Borodin <r...@simply.name> написал(а):Hi all.We have found that queries through PgBouncer 1.7.2 (with transaction pooling) to local PostgreSQL are almost two

Re: [HACKERS] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6

> 28 мая 2016 г., в 0:56, Andres Freund написал(а): > > On 2016-05-27 19:57:34 +0300, Vladimir Borodin wrote: >> >> OS PostgreSQL version TPS Avg. >> latency >> RHEL 6 9.4

Re: [HACKERS] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6

> 28 мая 2016 г., в 0:56, Andres Freund написал(а): > > Hi, > > > On 2016-05-27 19:57:34 +0300, Vladimir Borodin wrote: >> -performance >>> Here is how the results look like for 9.4, 9.5 and 9.6. All are built from >>> latest commi

Re: [HACKERS] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6

-performance +hackers > 25 мая 2016 г., в 17:33, Vladimir Borodin написал(а): > > Hi all. > > We have found that queries through PgBouncer 1.7.2 (with transaction pooling) > to local PostgreSQL are almost two times slower in 9.5.3 than in 9.4.8 on > RHEL 6 hosts (all pa

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

> 25 марта 2016 г., в 19:11, David Steele написал(а): > > Hi Vladimir, > > On 3/14/16 2:15 PM, Vladimir Borodin wrote: > >> JFYI, I’m preparing the stand to reproduce the initial problem and I >> hope to finish testing this week. > > Do you know when you&

Re: [HACKERS] Background Processes and reporting

> 15 марта 2016 г., в 19:57, Oleg Bartunov написал(а): > > > > On Tue, Mar 15, 2016 at 7:43 PM, Alexander Korotkov > mailto:a.korot...@postgrespro.ru>> wrote: > On Tue, Mar 15, 2016 at 12:57 AM, Robert Haas > wrote: > On Mon, Mar 14, 2016 at 4:42 PM, Andres Freu

Re: [HACKERS] Background Processes and reporting

> 14 марта 2016 г., в 22:21, Robert Haas написал(а): > > On Sat, Mar 12, 2016 at 6:05 AM, Oleg Bartunov wrote: >>> So? >> >> So, Robert already has experience with the subject, probably, he has bad >> experience with edb implementation and he'd like to see something better in >> community ver

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

> 10 марта 2016 г., в 14:38, Simon Riggs написал(а): > > On 10 March 2016 at 09:22, Michael Paquier <mailto:michael.paqu...@gmail.com>> wrote: > On Thu, Mar 10, 2016 at 10:00 AM, Vladimir Borodin <mailto:r...@simply.name>> wrote: > > Let’s do immediately

Re: [HACKERS] Background Processes and reporting

> 12 марта 2016 г., в 13:59, Amit Kapila написал(а): > > On Sat, Mar 12, 2016 at 3:10 AM, Andres Freund > wrote: > > > > > > > Similarly for the wait event stuff - checkpointer, wal writer, > > > background writer are in many cases processes that very often are > > >

Re: [HACKERS] Background Processes and reporting

> 12 марта 2016 г., в 2:45, Andres Freund написал(а): > > On 2016-03-12 02:24:33 +0300, Alexander Korotkov wrote: >> Idea of individual time measurement of every wait event met criticism >> because it might have high overhead [1]. > > Right. And that's actually one of the point which I meant wi

Re: [HACKERS] Background Processes and reporting

> 12 марта 2016 г., в 0:22, Andres Freund написал(а): > > On 2016-03-11 23:53:15 +0300, Vladimir Borodin wrote: >> It was many times stated in threads about waits monitoring [0, 1, 2] >> and supported by different people, but ultimately waits information >> wa

Re: [HACKERS] Background Processes and reporting

> 11 марта 2016 г., в 22:16, Andres Freund написал(а): > > Hi, > > We now have "Provide much better wait information in pg_stat_activity" > and "Add a generic command progress reporting facility" making it easier > to provide insight into the system. > > > While working on the writeback contr

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

> 10 марта 2016 г., в 11:50, Simon Riggs написал(а): > > On 10 March 2016 at 06:27, Michael Paquier > wrote: > On Thu, Mar 10, 2016 at 1:29 AM, David Steele > wrote: > > On 1/8/16 9:34 AM, Alvaro Herrera wrote: > >> Simon Riggs wrot

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

> 16 февр. 2016 г., в 18:20, Alvaro Herrera > написал(а): > > Vladimir Borodin wrote: > >>> Moreover, the use case you've sketched (ie, change ownership of all >>> objects inside a database) doesn't actually have anything to do with >>> fo

Re: [HACKERS] [WIP] ALTER ... OWNER TO ... CASCADE

> 15 февр. 2016 г., в 19:25, Tom Lane написал(а): > > Teodor Sigaev writes: >>> So basically, a generic CASCADE facility sounds like a lot of work to >>> produce something that would seldom be anything but a foot-gun. > >> DELETE FROM or TRUNCATE could be a foot-gun too, but it's not a reason

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

> 7 янв. 2016 г., в 5:26, Michael Paquier > написал(а): > > On Thu, Jan 7, 2016 at 12:20 AM, Alvaro Herrera > mailto:alvhe...@2ndquadrant.com>> wrote: >> Vladimir Borodin wrote: >> >>> There are situations in which vacuuming big btree index causes

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

> 14 нояб. 2015 г., в 10:50, Amit Kapila написал(а): > > On Wed, Sep 16, 2015 at 11:22 PM, Robert Haas > wrote: > > On Wed, Sep 16, 2015 at 12:29 PM, Alexander Korotkov > > mailto:aekorot...@gmail.com>> wrote: > > > > >> I think it's reasonable to consider reportin

[HACKERS] pg_rewind and replication slots

Hi. Should pg_rewind ignore pg_replslot dir at all? As it does pg_basebackup, for example. -- May the force be with you… https://simply.name

Re: [HACKERS] [ADMIN] Replication slots and isolation levels

> 3 нояб. 2015 г., в 11:38, Andres Freund написал(а): > > On 2015-11-02 15:37:57 -0500, Robert Haas wrote: >> On Fri, Oct 30, 2015 at 9:49 AM, Vladimir Borodin wrote: >>> I’ve tried two ways - bare SELECT in autocommit mode and BEGIN; SELECT; >>> ROLLBACK.

Re: [HACKERS] [ADMIN] Replication slots and isolation levels

> 2 нояб. 2015 г., в 23:37, Robert Haas написал(а): > > On Fri, Oct 30, 2015 at 9:49 AM, Vladimir Borodin wrote: >> I’ve tried two ways - bare SELECT in autocommit mode and BEGIN; SELECT; >> ROLLBACK. I first described the problem in thread on pgsql-admin@ [0], there >&

Re: [HACKERS] [ADMIN] Replication slots and isolation levels

> 30 окт. 2015 г., в 16:04, Robert Haas написал(а): > > On Fri, Oct 30, 2015 at 12:40 PM, Vladimir Borodin wrote: >> I still don’t fully understand why is it so (the problem occurs while >> running only one SELECT-statement in READ COMMITED so only one snapshot is >>

Re: [HACKERS] [ADMIN] Replication slots and isolation levels

> 30 окт. 2015 г., в 14:30, Robert Haas написал(а): > > On Thu, Oct 29, 2015 at 3:29 PM, Oleksii Kliukin wrote: >> Could it be a consequence of how REPEATABLE READ transactions handle >> snapshots? With REPEATABLE READ the snapshot is acquired only once at the >> beginning of a transaction; a R

Re: [HACKERS] [ADMIN] Replication slots and isolation levels

> 29 окт. 2015 г., в 15:29, Michael Paquier > написал(а): > > On Thu, Oct 29, 2015 at 12:35 PM, Vladimir Borodin wrote: >> 29 окт. 2015 г., в 14:03, Michael Paquier написал(а): >>> Standby will receive the record but not replay it until the >>> transactio

Re: [HACKERS] [ADMIN] Replication slots and isolation levels

> 29 окт. 2015 г., в 14:03, Michael Paquier > написал(а): > > On Thu, Oct 29, 2015 at 11:33 AM, Vladimir Borodin wrote: >> 29 окт. 2015 г., в 13:12, Michael Paquier написал(а): >>> In the case of repeatable read the standby will wait before applying >>>

Re: [HACKERS] [ADMIN] Replication slots and isolation levels

> 29 окт. 2015 г., в 13:12, Michael Paquier > написал(а): > > On Thu, Oct 29, 2015 at 9:42 AM, Vladimir Borodin wrote: >> I’m wondering why do I get conflicts with recovery on hot standby using >> replication slots and read commited isolation level? And if I

Re: [HACKERS] [ADMIN] Replication slots and isolation levels

> 27 окт. 2015 г., в 19:45, Vladimir Borodin написал(а): > > Hi all. > > I’m wondering why do I get conflicts with recovery on hot standby using > replication slots and read commited isolation level? And if I start > repeatable read transaction I don’t get any

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

> 18 сент. 2015 г., в 20:16, Robert Haas написал(а): > > On Fri, Sep 18, 2015 at 4:08 AM, Vladimir Borodin wrote: >> For both scenarios on linux we got approximately the same results - version >> with timings was faster then version with sampling (sampling was done eve

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

> 16 сент. 2015 г., в 20:52, Robert Haas написал(а): > > On Wed, Sep 16, 2015 at 12:29 PM, Alexander Korotkov > wrote: >> Yes, the major question is cost. But I think we should validate our thoughts >> by experiments assuming there are more possible synchronization protocols. >> Ildus posted im

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

> 12 сент. 2015 г., в 14:05, Amit Kapila написал(а): > > On Thu, Aug 6, 2015 at 3:31 PM, Ildus Kurbangaliev > mailto:i.kurbangal...@postgrespro.ru>> wrote: > > > > On 08/05/2015 09:33 PM, Robert Haas wrote: > >> > >> > >> You're missing the point. Those multi-byte fields have additional > >> s

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

25 авг. 2015 г., в 16:03, Michael Paquier написал(а):On Sun, Jul 26, 2015 at 9:46 PM, Andres Freund wrote:On 2015-07-24 09:53:49 +0300, Heikki Linnakangas wrote:To me it sounds like this shouldn't go through the full ReadBuffer()rigamarole. That code is already complex e

Re: [HACKERS] creating extension including dependencies

> 10 июля 2015 г., в 16:09, Heikki Linnakangas написал(а): > > On 07/09/2015 07:05 PM, Petr Jelinek wrote: >> On 2015-07-07 15:41, Andres Freund wrote: >>> On 2015-07-07 22:36:29 +0900, Fujii Masao wrote: On Mon, Jun 15, 2015 at 7:50 AM, Petr Jelinek wrote: > Hi, > > I am gett

Re: [HACKERS] pg_rewind failure by file deletion in source server

> 28 июня 2015 г., в 21:46, Heikki Linnakangas написал(а): > > On 06/24/2015 09:43 AM, Michael Paquier wrote: >> Attached is a new set of patches. Except for the last ones that >> addresses one issue of pg_rewind (symlink management when streaming >> PGDATA), all the others introduce if_not_exis

Re: [HACKERS] pg_rewind and xlogtemp files

> 17 июня 2015 г., в 9:48, Michael Paquier > написал(а): > > On Wed, Jun 17, 2015 at 3:17 PM, Michael Paquier > wrote: >> As pointed by dev1ant on the original bug report, process_remote_file >> should ignore files named as pg_xlog/xlogtemp.*, and I think that this >> is the right thing to do.

Re: [HACKERS] Broken --dry-run mode in pg_rewind

8 мая 2015 г., в 16:39, Vladimir Borodin <r...@simply.name> написал(а):8 мая 2015 г., в 16:11, Stephen Frost <sfr...@snowman.net> написал(а):* Heikki Linnakangas (hlinn...@iki.fi) wrote:On 05/08/2015 03:39 PM, Michael Paquier wrote:On Fri, May 8, 2015 at 9:34 PM, Heikki Linnak

Re: [HACKERS] Broken --dry-run mode in pg_rewind

> 8 мая 2015 г., в 16:11, Stephen Frost написал(а): > > * Heikki Linnakangas (hlinn...@iki.fi <mailto:hlinn...@iki.fi>) wrote: >> On 05/08/2015 03:39 PM, Michael Paquier wrote: >>> On Fri, May 8, 2015 at 9:34 PM, Heikki Linnakangas wrote: >>>> On 0

[HACKERS] Broken --dry-run mode in pg_rewind

Hi all.Seems, that pg_rewind does not account --dry-run option properly. A simple fix for that is attached. pg_rewind_dry_run_fix.patch Description: Binary data --May the force be with you…https://simply.name

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

Hi, Jim.Thanks for review.2 мая 2015 г., в 2:10, Jim Nasby <jim.na...@bluetreble.com> написал(а):On 5/1/15 11:19 AM, Vladimir Borodin wrote:There are situations in which vacuuming big btree index causes stuck inWAL replaying on hot standby servers for quite a long time. I’vedescribed the p

[HACKERS] Improving replay of XLOG_BTREE_VACUUM records

Hi all.There are situations in which vacuuming big btree index causes stuck in WAL replaying on hot standby servers for quite a long time. I’ve described the problem in more details in this thread [0]. Below in that thread Kevin Grittner proposed a good way for improving btree scans so that btree v

[HACKERS] ONLY in queries by RI triggers

Hi all. A long time ago in 04b31609b63ce77fb9273193f07cf21b2a7176af ONLY keyword was added to all queries in src/backend/utils/adt/ri_triggers.c. Since that time foreign keys do not work with inheritance trees and it is mentioned in the documentation for all versions since at least 7.3. I won

Re: [HACKERS] Vacuuming big btree indexes without pages with deleted items

> 31 марта 2015 г., в 23:33, Kevin Grittner написал(а): > > Jim Nasby wrote: >> On 3/27/15 5:15 AM, Vladimir Borodin wrote: > >>> Master writes this record to xlog in btvacuumscan function after >>> vacuuming of all index pages. And in case of no pages with

[HACKERS] Vacuuming big btree indexes without pages with deleted items

Hi all. I have described [0] a problem with delaying replicas after vacuuming a relation with big btree index. It stucks in replaying WAL record of type XLOG_BTREE_VACUUM like that (with lastBlockVacuumed 0): rmgr: Btree len (rec/tot): 20/52, tx: 0, lsn: 4115/56126DC0, p

Re: [HACKERS] pg_rewind in contrib

> 26 марта 2015 г., в 7:32, Michael Paquier > написал(а): > > On Thu, Mar 26, 2015 at 12:23 PM, Venkata Balaji N wrote: >> Test 1 : >> >> [...] >> >> If the master is crashed or killed abruptly, it may not be possible to do a >> rewind. Is my understanding correct ? > > Yep. This is mention

Re: [HACKERS] [GENERAL] [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary

> 20 марта 2015 г., в 18:00, Vladimir Borodin написал(а): > >> >> 19 марта 2015 г., в 20:30, Sergey Shchukin > <mailto:shchukin@gmail.com>> написал(а): >> >> 17.03.2015 13:22, Sergey Shchukin пишет: >>> 05.03.2015 11:25, Jim Nasby пи

Re: [HACKERS] pg_upgrade and rsync

> 6 марта 2015 г., в 6:11, Bruce Momjian написал(а): > > On Thu, Mar 5, 2015 at 10:55:28AM +0300, Vladimir Borodin wrote: >>You are correct that a pg_controldata file is copied over that has >>wal_level=minimal, but that should not be a problem. >> >>

Re: [HACKERS] pg_upgrade and rsync

> 4 марта 2015 г., в 19:28, Bruce Momjian написал(а): > > On Wed, Mar 4, 2015 at 01:53:47PM +0300, Vladimir Borodin wrote: >>After running initdb to create the new master, but before running >>pg_upgrade, modify the new master's postgresql.conf and change wal

Re: [HACKERS] pg_upgrade and rsync

> 3 марта 2015 г., в 18:01, Bruce Momjian написал(а): > > On Tue, Mar 3, 2015 at 04:55:56PM +0300, Vladimir Borodin wrote: >>OK, hmmm. Thanks for testing. It feels like you didn't have your new >>master set up for streaming replication when you ran pg_upgra

Re: [HACKERS] pg_upgrade and rsync

> 3 марта 2015 г., в 16:38, Bruce Momjian написал(а): > > On Tue, Mar 3, 2015 at 11:38:58AM +0300, Vladimir Borodin wrote: >>No, you would not need to take a full backup if you use these >> instructions. >> >> >> Although it would be applied t

Re: [HACKERS] pg_upgrade and rsync

> 2 марта 2015 г., в 21:28, Bruce Momjian написал(а): > > On Tue, Feb 24, 2015 at 12:13:17PM +0300, Vladimir Borodin wrote: >> >>20 февр. 2015 г., в 18:21, Bruce Momjian написал(а): >> >>On Fri, Feb 20, 2015 at 09:45:08AM -0500, Bruce Momjian wrote:

Re: [HACKERS] pg_upgrade and rsync

> 20 февр. 2015 г., в 18:21, Bruce Momjian написал(а): > > On Fri, Feb 20, 2015 at 09:45:08AM -0500, Bruce Momjian wrote: >>> #3 bothered me as well because it was not specific enough. I like what >>> you've added to clarify the procedure. >> >> Good. It took me a while to understand why they

Re: [HACKERS] Check that streaming replica received all data after master shutdown

05 янв. 2015 г., в 18:15, Vladimir Borodin написал(а): > Hi all. > > I have a simple script for planned switchover of PostgreSQL (9.3 and 9.4) > master to one of its replicas. This script checks a lot of things before > doing it and one of them is that all data from master ha