Re: [HACKERS] Timeline following for logical slots

> On 05 Apr 2016, at 09:51, Craig Ringer wrote: > > On 5 April 2016 at 04:00, Robert Haas > wrote: > > In general, I think we'd be a lot better off if we got some kind of > logical replication into core first and then worked on lifting these > types of limitations

Re: [HACKERS] WIP: Failover Slots

Hi, > On 17 Mar 2016, at 09:34, Craig Ringer wrote: > > OK, here's the latest failover slots patch, rebased on top of today's master > plus, in order: > > - Dirty replication slots when confirm_lsn is changed > > (http://www.postgresql.org/message-id/camsr+yhj0oycug2zbyqprhxmcjnkt9d57msxdzg

Re: [HACKERS] empty array case in plperl_ref_from_pg_array not handled correctly

> On 08 Mar 2016, at 10:11, Alex Hunsaker wrote: > > > > On Mon, Mar 7, 2016 at 11:32 PM, Andres Freund > wrote: > Hi, > > Per the new valgrind animal we get: > > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=skink&dt=2016-03-08%2004%3A22%3A00 > 2016-03-08 >

Re: [HACKERS] WIP: Failover Slots

> On 23 Feb 2016, at 11:30, Craig Ringer wrote: > > > Updated patch > > ... attached > > I've split it up a bit more too, so it's easier to tell what change is for > what and fixed the issues mentioned by Oleksii. I've also removed some > unrelated documentation changes. > > Patch 0001,

Re: [HACKERS] WIP: Failover Slots

Hi, > On 16 Feb 2016, at 09:11, Craig Ringer wrote: > > > > Revision attached. There was a file missing from the patch too. > All attached patches apply normally. I only took a look at first 2, but also tried to run the Patroni with the modified version to check whether the basic replicati

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

> On 30 Dec 2015, at 21:12, Tom Lane wrote: > > Emre Hasegeli writes: >>> I don’t see how to solve this problem without changing explain analyze >>> output to accommodate for “unknown” value. I don’t think “0” is a >>> non-confusing representation of “unknown” for most people, and from the >

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

> On 30 Dec 2015, at 18:38, Emre Hasegeli wrote: > >> which is much closer to the actual number of rows removed by the index >> recheck + the one left. > > Is it better to be closer? We are saying those are the "actual" > values not the estimates. If we cannot provide the actual rows, I > thi

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

> On 30 Dec 2015, at 17:44, Tom Lane wrote: > > Oleksii Kliukin writes: >>> On 30 Dec 2015, at 17:02, Tom Lane wrote: >>> Another idea would be to use the heap's row density as calculated >>> by the last ANALYZE (ie, reltuples/relpages), with a fallba

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

> On 30 Dec 2015, at 17:02, Tom Lane wrote: > > Oleksii Kliukin writes: >> Bitmap Heap Scan on example (cost=744.44..757.64 rows=6 width=0) (actual >> time=73.895..73.895 rows=0 loops=1) >> Output: 1 >> Recheck Cond: (example.event_time = (now() - '

[HACKERS] rows estimate in explain analyze for the BRIN index

Hi, While experimenting with BRIN on PostgreSQL 9.5RC1 I came across the following plan (which is, btw a very good example of how BRIN rocks for the clustered data, the size of this table is around 90GB, the size of the index is around 3MB): explain (analyze, buffers, verbose) select 1 from ex

Re: [HACKERS] pg_rewind test race condition..?

Hi, On Wed, Apr 29, 2015, at 01:36 AM, Heikki Linnakangas wrote: > The problem seems to be that when the standby is promoted, it's a > so-called "fast promotion", where it writes an end-of-recovery record > and starts accepting queries before creating a real checkpoint. > pg_rewind looks at the

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

> On 29 Oct 2015, at 14:39, Vladimir Borodin wrote: > > f I understand right, with hot_standby_feedback = on standby tells the master > xmin of the earliest transaction on standby. And autovacuum worker on master > takes it into account when doing vacuum cleanup (because it can see it from >

Re: [HACKERS] run pg_rewind on an uncleanly shut down cluster.

> On 06 Oct 2015, at 08:58, Michael Paquier > wrote: > > On Tue, Oct 6, 2015 at 12:41 AM, Oleksii Kliukin > wrote: >> pg_rewind -D postgresql0 --source-server="host=127.0.0.1 port=5433 >> dbname=postgres" The servers diverged at WAL position 0/360

Re: [HACKERS] run pg_rewind on an uncleanly shut down cluster.

> On 05 Oct 2015, at 18:04, Bruce Momjian wrote: > > On Mon, Oct 5, 2015 at 05:41:07PM +0200, Oleksii Kliukin wrote: >> Hello, >> >> I'm trying to find out how to rewind a cluster that was not shut down >> cleanly, in order to implement pg_rewind suppor

[HACKERS] run pg_rewind on an uncleanly shut down cluster.

there a better way to bring up the former master after the crash with pg_rewind? Kind regards, -- Oleksii Kliukin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] REVOKE [ADMIN OPTION FOR] ROLE

On Tue, Jul 28, 2015 at 10:51 AM, Egor Rogov wrote: > > Well, I looked into a draft of SQL:2003. It basically says that "cascade" > for must behave the same way as for privilege statement>. That is, from standard's point of view we have a code > issue. > > Still I doubt about usefulness of this