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 >>> the VACUUM

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

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 >> transaction doing REPEATABLE READ transactions that needs those rows >> commits on the standby. The WAL flush position

Re: [HACKERS] psql: add \pset true/false

Marko Tiikkaja writes: > On 10/29/15 11:51 AM, Daniel Verite wrote: >> Personally I think it would be worth having, but how about >> booleans inside ROW() or composite types ? > There's not enough information sent over to do that in the client. > Note that this works the same way

Re: [HACKERS] pg_dump

>  It's a problem. See this recent discussion: >   > http://www.postgresql.org/message-id/flat/20150710115735.gh26...@alap3.anarazel.de Postgresmen, we have a SQL function "current_database", which can be called by statement "SELECT CURRENT_CATALOG". If we will use CURRENT_CATALOG keyword, we

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Oct 22, 2015 at 12:47 AM, Masahiko Sawada wrote: > On Tue, Oct 20, 2015 at 8:10 PM, Beena Emerson > wrote: >> >> On Mon, Oct 19, 2015 at 8:47 PM, Masahiko Sawada >> wrote: >>> >>> >>> Hi, >>> >>> Attached patch is a

Re: [HACKERS] Disabling START TRANSACTION for a SuperUser

--On 27. Oktober 2015 14:07:06 + Kevin Grittner wrote: > It would be a boon to big shops if they could > declare (preferably with the option to set it at a role level) that > specific default_transaction_* settings could not be overridden. A while ago i was faced with

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 >>> transaction doing

Re: [HACKERS] pg_dump

David, do you want to have one dumper program for postgres? Maybe it will be a good idea to make a dumper with some dumping levels: - all cluster - global objects - database level -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] pg_dump

On Thu, Oct 29, 2015 at 06:37:46PM +0300, Дмитрий Воронин wrote: > David, do you want to have one dumper program for postgres? Yes, and pg_dump appears to be the best candidate for evolution into one. That there are two separate ones is the result of design decisions that may very well have made

Re: [HACKERS] Personal note: changing employers

On Wed, Oct 28, 2015 at 06:14:27PM -0400, Tom Lane wrote: > As of the end of this month, I will be departing Salesforce.com and > joining Crunchy Data Solutions (http://crunchydatasolutions.com), > whom you might recognize as being already the employers of Stephen > Frost, Joe Conway, and Greg

Re: [HACKERS] pg_dump

On Thu, Oct 29, 2015 at 10:51:20AM -0400, Tom Lane wrote: > =?koi8-r?B?5M3J1NLJyiD3z9LPzsnO?= writes: > >> �It's a problem. See this recent discussion: > >> �http://www.postgresql.org/message-id/flat/20150710115735.gh26...@alap3.anarazel.de > > > Postgresmen, we have a

Re: [HACKERS] pg_dump

>>  Maybe it will be a good idea to make a dumper with some dumping levels: >>  - all cluster >>  - global objects >>  - database level > > I'm not sure I understand. Is there some utility in dividing this > into these particular levels? -all cluster -- it's what pg_dumpall and pg_dump do. -

Re: [HACKERS] Personal note: changing employers

On 28 October 2015 at 23:14, Tom Lane wrote: > As of the end of this month, I will be departing Salesforce.com and > joining Crunchy Data Solutions (http://crunchydatasolutions.com), > whom you might recognize as being already the employers of Stephen > Frost, Joe Conway, and

Re: [HACKERS] pg_dump

On Thu, Oct 29, 2015 at 7:51 AM, Tom Lane wrote: > =?koi8-r?B?5M3J1NLJyiD3z9LPzsnO?= writes: >>> šIt's a problem. See this recent discussion: >>> šhttp://www.postgresql.org/message-id/flat/20150710115735.gh26...@alap3.anarazel.de > >> Postgresmen, we

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

Re: [HACKERS] pg_dump

=?koi8-r?B?5M3J1NLJyiD3z9LPzsnO?= writes: >> šIt's a problem. See this recent discussion: >> šhttp://www.postgresql.org/message-id/flat/20150710115735.gh26...@alap3.anarazel.de > Postgresmen, we have a SQL function "current_database", which can be called > by statement

Re: [HACKERS] pg_dump

On Thu, Oct 29, 2015 at 07:03:12PM +0300, Дмитрий Воронин wrote: > > >>  Maybe it will be a good idea to make a dumper with some dumping levels: > >>  - all cluster > >>  - global objects > >>  - database level > > > > I'm not sure I understand. Is there some utility in dividing this > > into

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, Please find attached an updated patch. >Flag isn't reset on error. Corrected in the attached. > + pgstat_reset_activityflag; >Does this actually compile? It does compile but with no effect. It has been corrected. >snprintf()? I don't think you need to keep track of schemaname_len

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Thu, Sep 24, 2015 at 6:36 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Thu, Sep 24, 2015 at 6:32 PM, Andres Freund wrote: > >> On 2015-09-15 20:16:10 +0300, YUriy Zhuravlev wrote: >> > We will be tested. >> >> Did you have a chance to run some

Re: [HACKERS] Freeze avoidance of very large table.

On Wed, Oct 28, 2015 at 12:58 PM, Amit Kapila wrote: > On Sat, Oct 24, 2015 at 2:24 PM, Masahiko Sawada > wrote: >> >> On Sat, Oct 24, 2015 at 10:59 AM, Amit Kapila >> wrote: >> > >> > I think we can display information

[HACKERS] planner doesn't use bitmap index

Hi There is interesting query on stackoverflow http://stackoverflow.com/questions/33418157/query-too-slow-in-postgresql-in-table-with-12m-rows - and it looks like planner issue. I have empty tables test1 and test2 set enable_seqscan to off; create table test1(a int, b int); create index on

Re: [HACKERS] [DOCS] max_worker_processes on the standby

On Wed, Oct 28, 2015 at 3:07 AM, Alvaro Herrera wrote: > Alvaro Herrera wrote: >> Robert Haas wrote: >> > On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek wrote: >> > > I agree with that sentiment. >> > > >> > > Attached patch adds variable to the

[HACKERS] ALTER ... OWNER TO ... vs. ALTER DEFAULT PRIVILEGES

Folks, I've run into a problem recently, and I can't be the first to have done so, and it's this. We have a pretty sophisticated capability via ALTER DEFAULT PRIVILEGES. When the creating role creates something in a schema so altered, all kinds of nice recursive granting happens. That's well

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On 10/28/15 4:18 AM, Victor Wagner wrote: > On Mon, 26 Oct 2015 16:25:57 -0400 > Peter Eisentraut wrote: > >> Also, this assumes that all the components other than host and port >> are the same. Earlier there was a discussion about why the ports >> would ever need to be

Re: [HACKERS] Are we sufficiently clear that jsonb containment is nested?

On Fri, Jun 26, 2015 at 8:05 AM, Robert Haas wrote: > I would be fine with adding a *compact* example of this kind to the > table that begins section 8.14.3. I probably would not back-patch it, > because the absence of that example is not an error in the > documentation,

Re: [HACKERS] Add EXTRA_CFLAGS to configure

On 10/28/15 6:55 AM, Andres Freund wrote: > 1) ./configure CFLAGS=... essentially breaks --enable-debug and related >options, If assigning to CFLAGS breaks --enable-debug, then we should fix that by reordering things a bit. > overwrites -O2 as the default and such. That's imo pretty >

Re: [HACKERS] planner doesn't use bitmap index

Pavel Stehule writes: > -- I was surprised, so following query can use index > postgres=# explain select a from test2 where a at time zone > 'America/Santiago' >= now() at time zone 'America/Santiago' ; > QUERY > PLAN >

Re: [HACKERS] planner doesn't use bitmap index

2015-10-29 19:20 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > -- I was surprised, so following query can use index > > postgres=# explain select a from test2 where a at time zone > > 'America/Santiago' >= now() at time zone 'America/Santiago' ; >

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-10-28 7:25 GMT+01:00 Catalin Iacob : > On Tue, Oct 27, 2015 at 9:34 AM, Pavel Stehule > wrote: > > Hi > > > > 2015-10-23 7:34 GMT+02:00 Catalin Iacob : > >> The current code doesn't build on Python3 because the 3rd

Re: [HACKERS] ALTER ... OWNER TO ... vs. ALTER DEFAULT PRIVILEGES

David Fetter writes: > Since it's not a green field project, I would like to propose the > following addition to the ALTER ... OWNER TO ... construct: > ALTER ... OWNER TO ... [{NEW | OLD} DEFAULT PRIVILEGES] > What say? I'd say "you haven't actually defined what either of

[HACKERS] Within CF app, "Bug Fixes" should be "Bug Fixes/Refactoring"

I think that within the CF app, we should either rename the patch topic "Bug Fixes" to "Bug Fixes/Refactoring", or introduce a new "Refactoring" topic. I prefer the first approach. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Within CF app, "Bug Fixes" should be "Bug Fixes/Refactoring"

On Thu, Oct 29, 2015 at 8:33 PM, Peter Geoghegan wrote: > I think that within the CF app, we should either rename the patch > topic "Bug Fixes" to "Bug Fixes/Refactoring", or introduce a new > "Refactoring" topic. I prefer the first approach. I would vote for the second

Re: [HACKERS] Within CF app, "Bug Fixes" should be "Bug Fixes/Refactoring"

​ On Thu, Oct 29, 2015 at 2:45 PM, Michael Paquier wrote: > On Thu, Oct 29, 2015 at 8:33 PM, Peter Geoghegan wrote: > > I think that within the CF app, we should either rename the patch > > topic "Bug Fixes" to "Bug Fixes/Refactoring", or introduce

Re: [HACKERS] Within CF app, "Bug Fixes" should be "Bug Fixes/Refactoring"

Michael Paquier writes: > On Thu, Oct 29, 2015 at 8:33 PM, Peter Geoghegan wrote: >> I think that within the CF app, we should either rename the patch >> topic "Bug Fixes" to "Bug Fixes/Refactoring", or introduce a new >> "Refactoring" topic. I prefer

Re: [HACKERS] Within CF app, "Bug Fixes" should be "Bug Fixes/Refactoring"

On Thu, Oct 29, 2015 at 1:10 PM, Tom Lane wrote: > Ditto. Bug fixes are not at all like refactoring --- in particular, we'd > usually not consider refactoring as fit material for back-patching. > > "Refactoring" seems rather a narrow definition of what might show up > in such

Re: [HACKERS] Are we sufficiently clear that jsonb containment is nested?

Peter Geoghegan writes: > On Thu, Oct 29, 2015 at 1:16 PM, Tom Lane wrote: >> I think the existing text is largely my fault, so I'll do something with >> this. > Good. Thanks. After studying the proposed patch a bit more, I still think the example is good,

Re: [HACKERS] ALTER ... OWNER TO ... vs. ALTER DEFAULT PRIVILEGES

On Thu, Oct 29, 2015 at 02:25:14PM -0400, Tom Lane wrote: > David Fetter writes: > > Since it's not a green field project, I would like to propose the > > following addition to the ALTER ... OWNER TO ... construct: > > ALTER ... OWNER TO ... [{NEW | OLD} DEFAULT PRIVILEGES] > >

Re: [HACKERS] Are we sufficiently clear that jsonb containment is nested?

On Thu, Oct 29, 2015 at 1:16 PM, Tom Lane wrote: > I think the existing text is largely my fault, so I'll do something with > this. Good. Thanks. >> I still think it would be a good idea to go back to 9.4. I have reason >> to believe that people are getting confused on this

Re: [HACKERS] Are we sufficiently clear that jsonb containment is nested?

Peter Geoghegan writes: > On Fri, Jun 26, 2015 at 8:05 AM, Robert Haas wrote: >> I would be fine with adding a *compact* example of this kind to the >> table that begins section 8.14.3. I probably would not back-patch it, >> because the absence of that

Re: [HACKERS] Are we sufficiently clear that jsonb containment is nested?

On Thu, Oct 29, 2015 at 2:02 PM, Tom Lane wrote: > After studying the proposed patch a bit more, I still think the example > is good, but the added text doesn't do much to explain your point. If > I get what your point is, which maybe I don't, I think the attached might >

Re: [HACKERS] Within CF app, "Bug Fixes" should be "Bug Fixes/Refactoring"

On 10/29/2015 01:10 PM, Tom Lane wrote: > Michael Paquier writes: >> On Thu, Oct 29, 2015 at 8:33 PM, Peter Geoghegan wrote: >>> I think that within the CF app, we should either rename the patch >>> topic "Bug Fixes" to "Bug Fixes/Refactoring", or

Re: [HACKERS] Are we sufficiently clear that jsonb containment is nested?

Peter Geoghegan writes: > Robert seemed to want to keep the example short, which I took on > board, but I myself think that your more worked out treatment is > better. I think this revision makes my point very well. I recommend > committing it. After further thought I realized

[HACKERS] Did the "Full-text search in PostgreSQL in milliseconds" patches land?

Hi, I've been reading wiki.postgresql.org/images/2/25/Full-text_search_in_PostgreSQL_in_milliseconds-extended-version.pdf with interest and am wondering if these patches ever made it in to the "official" version of Postgresql? I've tried doing some of the queries as described in the slides using

Re: [HACKERS] Freeze avoidance of very large table.

On Fri, Oct 30, 2015 at 1:26 AM, Masahiko Sawada wrote: > On Wed, Oct 28, 2015 at 12:58 PM, Amit Kapila wrote: >> On Sat, Oct 24, 2015 at 2:24 PM, Masahiko Sawada >> wrote: >>> >>> On Sat, Oct 24, 2015 at 10:59 AM, Amit

Re: [HACKERS] Are we sufficiently clear that jsonb containment is nested?

On Thu, Oct 29, 2015 at 4:03 PM, Tom Lane wrote: > After further thought I realized that part of the point you'd been > making was that people might fail to distinguish the behaviors of > containment and existence operators in this regard. So I think the > example needs to

Re: [HACKERS] PoC: Partial sort

On Tue, Oct 20, 2015 at 4:17 AM, Alexander Korotkov wrote: > Planner regression is fixed in the attached version of patch. It appears > that get_cheapest_fractional_path_for_pathkeys() behaved wrong when no > ordering is required. I don't see an entry in the CF app for

Re: [HACKERS] Rework the way multixact truncations work

Hi, On October 29, 2015 7:59:03 AM GMT+01:00, Noah Misch wrote: >On Tue, Oct 27, 2015 at 03:44:10PM +0100, Andres Freund wrote: >> On 2015-10-24 22:07:00 -0400, Noah Misch wrote: >> > On Tue, Sep 22, 2015 at 07:57:27PM +0200, Andres Freund wrote: >> > > On 2015-09-22 13:38:58

Re: [HACKERS] Is there any ordering to the values in guc.c?

On 10/28/15 10:27 AM, Bill Moran wrote: See subject. Aside from them being divvied up by datatype, they seem to be ordered randomly. Since I'm putting together a patch that will add some GUCs, do I just add them to the end of the list? The initial commit grouped them logically, and it went

Re: [HACKERS] Cross-check recent documentation changes

On Thu, Oct 29, 2015 at 2:40 AM, Robins wrote: > Was reviewing recent commits, and it seems the following commit adds an > extra line to some comments. Just wanted to cross-check if that was > intentional. I don't see that it changed any comments at all? -- Robert Haas

Re: [HACKERS] Rework the way multixact truncations work

On Tue, Oct 27, 2015 at 03:44:10PM +0100, Andres Freund wrote: > On 2015-10-24 22:07:00 -0400, Noah Misch wrote: > > On Tue, Sep 22, 2015 at 07:57:27PM +0200, Andres Freund wrote: > > > On 2015-09-22 13:38:58 -0400, Robert Haas wrote: > > > > - If SlruDeleteSegment fails in unlink(), shouldn't we

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Thu, Oct 29, 2015 at 6:05 AM, Kouhei Kaigai wrote: > In this case, the EPQ slot to store the joined tuple is still > a challenge to be solved. > > Is it possible to use one or any of EPQ slots that are setup for > base relations but represented by ForeignScan/CustomScan?

Re: [HACKERS] psql: add \pset true/false

On Thu, Oct 29, 2015 at 1:32 AM, Marko Tiikkaja wrote: >> 2. If you're the sort of person liable to be confused by t/f, you >> probably aren't in the target audience for psql anyway. > > Really? The difference between t/f is that the vertical squiggle is > flipped, THAT'S IT.

Re: [HACKERS] Cross-check recent documentation changes

On 2015/10/29 17:10, Robert Haas wrote: > On Thu, Oct 29, 2015 at 2:40 AM, Robins wrote: >> Was reviewing recent commits, and it seems the following commit adds an >> extra line to some comments. Just wanted to cross-check if that was >> intentional. > > I don't see that it

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 errors. Below

Re: [HACKERS] Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')

> On Tue, Oct 27, 2015 at 05:31:25PM +0900, Tatsuo Ishii wrote: >> > No, PQping("host='127.0.0.1'") fails to reach a listen_addresses='::' >> > server >> > on many systems. Here's what I thought Kondo was proposing: >> > >> > --- a/src/bin/pg_ctl/pg_ctl.c >> > +++ b/src/bin/pg_ctl/pg_ctl.c >> >

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

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 start > repeatable read transaction I don’t get any errors. Below is some > diagnostics. In the case

Re: [HACKERS] Cross-check recent documentation changes

Robins, On 2015/10/29 10:40, Robins wrote: > Hi, > > Was reviewing recent commits, and it seems the following commit adds an > extra line to some comments. Just wanted to cross-check if that was > intentional. > > Commit: http://goo.gl/zxA00l > Pre-Commit: http://goo.gl/2DpLxi > Post-Commit:

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 start >>

Re: [HACKERS] psql: add \pset true/false

Marko Tiikkaja wrote: > Since the default t/f output for booleans is not very user friendly, > attached is a patch which enables you to do for example the following: Personally I think it would be worth having, but how about booleans inside ROW() or composite types ? test=> \pset true

Re: [HACKERS] psql: add \pset true/false

On 10/29/15 11:51 AM, Daniel Verite wrote: Marko Tiikkaja wrote: Since the default t/f output for booleans is not very user friendly, attached is a patch which enables you to do for example the following: Personally I think it would be worth having, but how about booleans inside

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

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 >> the VACUUM WAL record cleaning up a relation page. Hence you won't get >> conflicts in this case. > > Standby

Re: [HACKERS] Cube extension kNN support

Hello. That is updated version of the patch with proper update scripts. Also i’ve noted that documentation states the wrong thing: “It does not matter which order the opposite corners of a cube are entered in. The cube functions automatically swap values if needed to create a uniform "lower