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

On Thu, Mar 10, 2016 at 7:21 PM, Fujii Masao wrote: > On Fri, Mar 4, 2016 at 3:40 AM, Masahiko Sawada wrote: >> On Thu, Mar 3, 2016 at 11:30 PM, Masahiko Sawada >> wrote: >>> Hi, >>> >>> Thank you so much for reviewing this patch! >>> >>> All review comments regarding document and comment are f

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Thu, Mar 17, 2016 at 11:39 AM, Amit Kapila wrote: I have reviewed the patch.. here are some review comments, I will continue to review.. 1. + + /* + * Add the proc to list, if the clog page where we need to update the + */ + if (nextidx != INVALID_PGPROCNO && + ProcGlobal->allProcs[nexti

Re: [HACKERS] Applying logical replication changes by more than one process

On 22 March 2016 at 14:32, konstantin knizhnik wrote: > Ah you mean because with wal_log=true the origin advance is in different > WAL record than commit? OK yeah you might be one transaction behind then, > true. > > > It actually means that we can not enforce database consistency. If we do > r

Re: [HACKERS] OOM in libpq and infinite loop with getCopyStart()

On Tue, Mar 22, 2016 at 2:19 PM, Amit Kapila wrote: > On Tue, Mar 22, 2016 at 9:46 AM, Tom Lane wrote: >> >> Amit Kapila writes: >> > On Mon, Mar 21, 2016 at 10:13 PM, Robert Haas >> > wrote: >> >> It is very difficult to believe that this is a good idea: >> >> >> >> --- a/src/backend/replicati

[HACKERS] Some messages of pg_rewind --debug not getting translated

Hi all, I found that some of the messages generated by pg_rewind --debug are not getting translated because the string messages are not put within _(%s). For the debug messages of the file map and the data page map this is not really a problem because those do not involve any translatable words li

Re: [HACKERS] multivariate statistics v14

>> Do you have any other missing parts in this work? I am asking >> because I wonder if you want to push this into 9.6 or rather 9.7. > > I think the first few parts of the patch series, namely: > > * shared infrastructure (0002) > * functional dependencies (0003) > * MCV lists (0004) > *

Re: [HACKERS] Applying logical replication changes by more than one process

On 22/03/16 07:32, konstantin knizhnik wrote: On Mar 21, 2016, at 4:30 PM, Petr Jelinek wrote: On 21/03/16 14:25, Andres Freund wrote: On 2016-03-21 14:18:27 +0100, Petr Jelinek wrote: On 21/03/16 14:15, Andres Freund wrote: Only when the origin is actually setup for the current session. Yo

Re: [HACKERS] Applying logical replication changes by more than one process

On Mar 22, 2016, at 10:10 AM, Craig Ringer wrote: > On 22 March 2016 at 14:32, konstantin knizhnik > wrote: > >> Ah you mean because with wal_log=true the origin advance is in different WAL >> record than commit? OK yeah you might be one transaction behind then, true. > > It actually means

Re: [HACKERS] Applying logical replication changes by more than one process

On Mar 22, 2016, at 11:14 AM, Petr Jelinek wrote: > > And each slot means connection with logical decoding attached to it so you > don't really want to have thousands of those anyway. I think you'll hit other > problems faster than loop over slots becomes problem if you plan to keep all > of t

Re: [HACKERS] POC: Cache data in GetSnapshotData()

On Thu, Mar 10, 2016 at 1:36 PM, Amit Kapila wrote: >Do you think it makes sense to check the performance by increasing CLOG buffers (patch for same is posted in Speed up Clog thread [1]) >as that also relieves contention on CLOG as per the tests I have done? Along with clog patches and save snap

Re: [HACKERS] [WIP] speeding up GIN build with parallel workers

On Fri, 18 Mar 2016 20:40:16 +0300 Dmitry Ivanov wrote: > Hi Constantin, > > I did a quick review of your patch, and here are my comments: > > - This patch applies cleanly to the current HEAD (61d2ebdbf91). > > - Code compiles without warnings. > > - Currently there's no documentation regardi

Re: [HACKERS] checkpointer continuous flushing

Hi, On 03/22/2016 07:35 AM, Fabien COELHO wrote: Hello Tomas, Thanks again for these interesting benches. Overall, this means ~300M transactions in total for the un-throttled case, so sample with ~15M transactions available when computing the following charts. Still a very sizable run! T

Re: [HACKERS] Relation extension scalability

On Mon, Mar 21, 2016 at 8:10 PM, Amit Kapila wrote: > Review comments: > > Thanks for the review, Please find my response inline.. > 1. > /* > + * RelationAddOneBlock > + * > + * Extend relation by one block and lock the buffer > + */ > +static Buffer > +RelationAddOneBlock(Relation relation,

Re: [HACKERS] WIP: Access method extendability

On 21/03/16 23:26, Alvaro Herrera wrote: Alexander Korotkov wrote: Hi! Thank you for review! So. Before this version of the patch was posted in Nov 4th 2015, both Tom and Heikki had said essentially "CREATE ACCESS METHOD is worthless, let's pursue this stuff without those commands". http://w

Re: [HACKERS] checkpointer continuous flushing

Hi, On 2016-03-21 18:46:58 +0100, Tomas Vondra wrote: > I've repeated the tests, but this time logged details for 5% of the > transaction (instead of aggregating the data for each second). I've also > made the tests shorter - just 12 hours instead of 24, to reduce the time > needed to complete the

Re: [HACKERS] multivariate statistics v14

Hi, On 03/22/2016 06:53 AM, Jeff Janes wrote: On Sun, Mar 20, 2016 at 4:34 PM, Tomas Vondra wrote: D'oh. Thanks for reporting. Attached is v16, hopefully fixing the few remaining whitespace issues. Hi Tomas, I'm trying out v16 against a common problem, where postgresql thinks it is likely

Re: [HACKERS] multivariate statistics v14

Hello, On 03/22/2016 09:13 AM, Tatsuo Ishii wrote: Do you have any other missing parts in this work? I am asking because I wonder if you want to push this into 9.6 or rather 9.7. I think the first few parts of the patch series, namely: * shared infrastructure (0002) * functional dependenc

Re: [HACKERS] checkpointer continuous flushing

1) regular-latency.png I'm wondering whether it would be clearer if the percentiles where relative to the largest sample, not to itself, so that the figures from the largest one would still be between 0 and 1, but the other (unpatched) one would go between 0 and 0.85, that is would be cut sho

[HACKERS] NOT EXIST for PREPARE

Hello hackers. Do I understand correctly the only way know availability PREPARE it will appeal to pg_prepared_statements? I think this is not a good practice. In some cases, we may not be aware of the PREPARE made (pgpool). Moreover, it seems popular question in the Internet: http://stackover

Re: [HACKERS] checkpointer continuous flushing

Hi, On 03/22/2016 10:44 AM, Fabien COELHO wrote: 1) regular-latency.png I'm wondering whether it would be clearer if the percentiles where relative to the largest sample, not to itself, so that the figures from the largest one would still be between 0 and 1, but the other (unpatched) one wo

Re: [HACKERS] WIP: Access method extendability

On Tue, Mar 22, 2016 at 1:26 AM, Alvaro Herrera wrote: > So. Before this version of the patch was posted in Nov 4th 2015, both > Tom and Heikki had said essentially "CREATE ACCESS METHOD is worthless, > let's pursue this stuff without those commands". > http://www.postgresql.org/message-id/54730

Re: [HACKERS] checkpointer continuous flushing

WRT tablespaces: What I'm planning to do, unless somebody has a better proposal, is to basically rent two big amazon instances, and run pgbench in parallel over N tablespaces. Once with local SSD and once with local HDD storage. Ok. Not sure how to control that table spaces are actually on di

Re: [HACKERS] checkpointer continuous flushing

On 2016-03-22 10:48:20 +0100, Tomas Vondra wrote: > Hi, > > On 03/22/2016 10:44 AM, Fabien COELHO wrote: > > > > > 1) regular-latency.png > >>> > >>>I'm wondering whether it would be clearer if the percentiles > >>>where relative to the largest sample, not to itself, so that the > >>>figures f

Re: [HACKERS] checkpointer continuous flushing

On 2016-03-22 10:52:55 +0100, Fabien COELHO wrote: > To emphasize potential bad effects without having to build too large a host > and involve too many table spaces, I would suggest to reduce significantly > the "checkpoint_flush_after" setting while running these tests. Meh, that completely disto

Re: [HACKERS] checkpointer continuous flushing

You took 5% of the tx on two 12 hours runs, totaling say 85M tx on one and 100M tx on the other, so you get 4.25M tx from the first and 5M from the second. OK I'm saying that the percentile should be computed on the largest one (5M), so that you get a curve like the following, with both curv

Re: [HACKERS] checkpointer continuous flushing

My impression is that we actually know what we need to know anyway? Sure, the overall summary is "it is much better with the patch" on this large SSD test, which is good news because the patch was really designed to help with HDDs. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tue, Mar 22, 2016 at 7:57 AM, Dilip Kumar wrote: > > On Tue, Mar 22, 2016 at 12:31 PM, Dilip Kumar > wrote: > >> ! pg_atomic_write_u32(&bufHdr->state, state); >> } while (!StartBufferIO(bufHdr, true)); >> >> Better Write some comment, about we clearing the BM_LOCKED from stage >> directly a

Re: [HACKERS] checkpointer continuous flushing

To emphasize potential bad effects without having to build too large a host and involve too many table spaces, I would suggest to reduce significantly the "checkpoint_flush_after" setting while running these tests. Meh, that completely distorts the test. Yep, I agree. The point would be to

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

First, thank you all involved, and thank you for polishing this and committing, Tom. At Mon, 21 Mar 2016 17:15:18 -0400, Tom Lane wrote in <1596.1458594...@sss.pgh.pa.us> > So I looked into this, and found that persuading psql to let backslash > commands cross line boundaries is a much bigger de

Re: [HACKERS] Endless loop calling PL/Python set returning functions

Alexey Grishchenko wrote: > Alexey Grishchenko wrote: > >> Tom Lane wrote: >> >>> Alexey Grishchenko writes: >>> > No, my fix handles this well. >>> > In fact, with the first function call you allocate global variables >>> > representing Python function input parameters, call the function and

Re: [HACKERS] multivariate statistics v14

>> Hum. So without 0006 or beyond, there's not much benefit for the >> PostgreSQL users, and you are not too confident about 0006 or >> beyond. Then I would think it is a little bit hard to justify in >> putting 000[2-5] into 9.6. I really like this feature and would like >> to see in PostgreSQL so

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

Hi, On 2016-03-15 10:47:12 +0530, Amit Kapila wrote: > @@ -248,12 +256,67 @@ set_status_by_pages(int nsubxids, TransactionId > *subxids, > * Record the final state of transaction entries in the commit log for > * all entries on a single page. Atomic only on this page. > * > + * Group the s

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

On 2016/03/22 14:54, Ashutosh Bapat wrote: On Tue, Mar 22, 2016 at 8:03 AM, Etsuro Fujita mailto:fujita.ets...@lab.ntt.co.jp>> wrote: OK, I'll modify the patch so that the join is pushed down even if any of xmins, xmaxs, cmins, and cmaxs are requested. Do you think which one should s

Re: [HACKERS] Proposal: Generic WAL logical messages

On 2016-03-21 18:10:55 +0100, Petr Jelinek wrote: > Just noticed there is missing symlink in the pg_xlogdump. > create mode 100644 src/backend/access/rmgrdesc/logicalmsgdesc.c > create mode 12 src/bin/pg_xlogdump/logicalmsgdesc.c Uh, src/bin/pg_xlogdump/logicalmsgdesc.c shouldn't be there.

Re: [HACKERS] Timeline following for logical slots

On 2016-03-15 21:04:12 +0800, Craig Ringer wrote: > Thanks very much for the review. Are you planning to update the patch? - Andres -- 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] Odd system-column handling in postgres_fdw join pushdown patch

On Tue, Mar 22, 2016 at 5:05 PM, Etsuro Fujita wrote: > On 2016/03/22 14:54, Ashutosh Bapat wrote: > >> On Tue, Mar 22, 2016 at 8:03 AM, Etsuro Fujita >> mailto:fujita.ets...@lab.ntt.co.jp>> wrote: >> OK, I'll modify the patch so that the join is pushed down even if >> any of xmins, xmaxs

Re: [HACKERS] WIP: Upper planner pathification

On Mon, Mar 21, 2016 at 7:55 AM, Jim Nasby wrote: > On 3/17/16 9:01 AM, Robert Haas wrote: >> >> I think that >> there are an awful lot of cases where extension authors haven't been >> able to quite do what they want to do without core changes because >> they couldn't get control in quite the righ

Re: [HACKERS] NOT EXIST for PREPARE

Em terça-feira, 22 de março de 2016, Yury Zhuravlev < u.zhurav...@postgrespro.ru> escreveu: > Hello hackers. > > Do I understand correctly the only way know availability PREPARE it will > appeal to pg_prepared_statements? > I think this is not a good practice. In some cases, we may not be aware of

Re: [HACKERS] multivariate statistics v14

Hi, On 03/22/2016 11:41 AM, Tatsuo Ishii wrote: Hum. So without 0006 or beyond, there's not much benefit for the PostgreSQL users, and you are not too confident about 0006 or beyond. Then I would think it is a little bit hard to justify in putting 000[2-5] into 9.6. I really like this feature an

Re: [HACKERS] multivariate statistics v14

> On 03/22/2016 11:41 AM, Tatsuo Ishii wrote: Hum. So without 0006 or beyond, there's not much benefit for the PostgreSQL users, and you are not too confident about 0006 or beyond. Then I would think it is a little bit hard to justify in putting 000[2-5] into 9.6. I really like

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Tue, Mar 22, 2016 at 4:22 PM, Andres Freund wrote: > > Hi, > > On 2016-03-15 10:47:12 +0530, Amit Kapila wrote: > > @@ -248,12 +256,67 @@ set_status_by_pages(int nsubxids, TransactionId *subxids, > > * Record the final state of transaction entries in the commit log for > > * all entries on

Re: [HACKERS] NOT EXIST for PREPARE

Fabrízio de Royes Mello wrote: I think you meant IF NOT EXISTS, right? Thanks, you right. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscriptio

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

Thank you for the revised patch. At Tue, 22 Mar 2016 16:02:39 +0900, Fujii Masao wrote in > On Thu, Mar 10, 2016 at 7:21 PM, Fujii Masao wrote: > Sorry for the delay... Here is the revised version of the patch. > Please review and test this version! > BTW, I've not revised the documentation an

Re: [HACKERS] NOT EXIST for PREPARE

Em terça-feira, 22 de março de 2016, Yury Zhuravlev < u.zhurav...@postgrespro.ru> escreveu: > Fabrízio de Royes Mello wrote: > >> I think you meant IF NOT EXISTS, right? >> > Thanks, you right. > > You already have a patch? If yes I'm glad to review it. Regards, -- Fabrízio de Royes Mello Cons

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On 2016-03-22 18:19:48 +0530, Amit Kapila wrote: > > I'm actually rather unconvinced that it's all that common that all > > subtransactions are on one page. If you have concurrency - otherwise > > there'd be not much point in this patch - they'll usually be heavily > > interleaved, no? You can arg

Re: [HACKERS] NOT EXIST for PREPARE

Hi, On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: > Do I understand correctly the only way know availability PREPARE it will > appeal to pg_prepared_statements? > I think this is not a good practice. In some cases, we may not be aware of > the PREPARE made (pgpool). Moreover, it seems popul

Re: [HACKERS] Proposal: Generic WAL logical messages

On 22/03/16 12:47, Andres Freund wrote: On 2016-03-21 18:10:55 +0100, Petr Jelinek wrote: + + + Generic Message Callback + + + The optional message_cb callback is called whenever + a logical decoding message has been decoded. + +typedef void (*LogicalDecodeMessageCB) ( +

Re: [HACKERS] trivial typo in vacuum progress doc

On Tue, Mar 22, 2016 at 3:11 PM, Jeff Janes wrote: > "skipped blocks are included this total" > > The word "in" is missing Pushed. Thanks! Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresq

Re: [HACKERS] Proposal: Generic WAL logical messages

On 2016-03-22 14:03:06 +0100, Petr Jelinek wrote: > On 22/03/16 12:47, Andres Freund wrote: > >On 2016-03-21 18:10:55 +0100, Petr Jelinek wrote: > > > >>+ > >>+ > >>+ Generic Message Callback > >>+ > >>+ > >>+ The optional message_cb callback is called > >>whenever > >>+ a l

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

I attached the patch, which fixes the pg_trgm documentation. On 19.03.2016 01:18, Artur Zakirov wrote: 2016-03-18 23:46 GMT+03:00 Jeff Janes mailto:jeff.ja...@gmail.com>>: <% and <<-> are not documented at all. Is that a deliberate choice? Since they were added as convenience functi

Re: [HACKERS] Speedup twophase transactions

On Tue, Mar 22, 2016 at 1:53 AM, Jesper Pedersen wrote: > On 03/18/2016 12:50 PM, Stas Kelvich wrote: >>> >>> On 11 Mar 2016, at 19:41, Jesper Pedersen >>> wrote: >>> >> >> Thanks for review, Jesper. >> >>> Some comments: >>> >>> * The patch needs a rebase against the latest TwoPhaseFileHeader ch

Re: [HACKERS] Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure)

> > It's possible that memset() would be more convincing. > > +1 OK, here is corrected patch. -- Best regards, Aleksander Alekseev http://eax.me/ diff --git a/src/backend/access/gist/gistxlog.c b/src/backend/access/gist/gistxlog.c index b48e97c..273e0b0 100644 --- a/src/backend/access/gist/gis

Re: [HACKERS] BRIN is missing in multicolumn indexes documentation

On Tue, Mar 22, 2016 at 12:53 AM, Petr Jediný wrote: > Hello, > > the http://www.postgresql.org/docs/9.5/static/indexes-multicolumn.html > page doesn't mention BRIN support, but according to the > http://www.postgresql.org/docs/9.5/static/sql-createindex.html it is > supported in multicolumn setup

Re: [HACKERS] Relax requirement for INTO with SELECT in pl/pgsql

On Tue, Mar 22, 2016 at 12:20 AM, Pavel Stehule wrote: > > 2016-03-22 6:06 GMT+01:00 Tom Lane : >> >> Pavel Stehule writes: >> > I can live with SELECT fx(x). It is little bit dangerous, but this risk >> > can >> > be easy detected by plpgsql_check. >> >> Dangerous how? > > I afraid of useless an

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Wed, Mar 9, 2016 at 11:10 PM, Petr Jelinek wrote: > Something like attached is simplest way this would work correctly (note that > I didn't really test it and it's missing comments). Note that we are falling > back to the old parsing in case the GetLocaleInfoEx didn't work, that's > important b

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Sat, Mar 12, 2016 at 12:46 AM, Gilles Darold wrote: > Here is the patch rewritten to use alternate file > $PGDATA/pg_log_filename to store the current log filename used by > syslogger. All examples used in the first mail of this thread work the > exact same way. If there's no other remarks, I w

Re: [HACKERS] pg_dump dump catalog ACLs

Hi, Stephen! I'm signed to review this patch. At first, patch wasn't applied cleanly, it had a conflict at the end of system_views.sql. But that way very easy to fix. On Mon, Mar 14, 2016 at 7:00 PM, Stephen Frost wrote: > I've not included it in this patch, but my thinking here would be to add

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Mon, Mar 21, 2016 at 11:07 PM, Robert Haas wrote: > Well, I said before and I'll say again that I don't like the idea of > multiple password verifiers. I think that's an accident waiting to > happen, and I'm not prepared to put in the amount of time and energy > that it would take to get that

Re: [HACKERS] multivariate statistics v14

Hi, On 03/22/2016 01:46 PM, Tatsuo Ishii wrote: ... Sorry, maybe I did not explain clearly. My question is, if put patches only 0002 to 0005 into 9.6, does it still give any visible benefit to users? The users will be able to define statistics with the limitation that only a single one (the o

Re: [HACKERS] NOT EXIST for PREPARE

Andres Freund wrote: you'd still need to compare the statement somehow You right, I think about that as syntax sugar. Maybe with some performance increase but hardly. We can save on a round trip. It may be necessary to add an index on the field "statement"? Thanks. -- Yury Zhuravlev Postgr

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 22/03/16 14:40, Michael Paquier wrote: On Wed, Mar 9, 2016 at 11:10 PM, Petr Jelinek wrote: Something like attached is simplest way this would work correctly (note that I didn't really test it and it's missing comments). Note that we are falling back to the old parsing in case the GetLocaleI

Re: [HACKERS] NOT EXIST for PREPARE

On 2016-03-22 16:51:26 +0300, Yury Zhuravlev wrote: > Andres Freund wrote: > >you'd still need to compare the > >statement somehow > > You right, I think about that as syntax sugar. Maybe with some performance > increase but hardly. We can save on a round trip. If anything what'd be useful would

Re: [HACKERS] NOT EXIST for PREPARE

Fabrízio de Royes Mello wrote: You already have a patch? If yes I'm glad to review it. If the community is not against it, I'll do it quickly. Changing the syntax is the risk. In addition, we have already missed 9.6. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.c

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

On Tue, Mar 22, 2016 at 9:58 PM, Kyotaro HORIGUCHI wrote: > Thank you for the revised patch. Thanks for reviewing the patch! > This version looks to focus on n-priority method. Stuffs for the > other methods like n-quorum has been removed. It is okay for me. I don't think it's so difficult to e

Re: [HACKERS] NOT EXIST for PREPARE

Yury Zhuravlev wrote: It may be necessary to add an index on the field "statement"? Sorry. Said nonsense. We need to understand what kind of behavior should be if the name is the same but query_string not? Replace? Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.co

Re: [HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 10:01 AM, Andres Freund wrote: > > Hi, > > > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: > > Do I understand correctly the only way know availability PREPARE it will > > appeal to pg_prepared_statements? > > I think this is not a good practice. In some cases, we may

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Tue, Mar 22, 2016 at 6:29 PM, Andres Freund wrote: > > On 2016-03-22 18:19:48 +0530, Amit Kapila wrote: > > > I'm actually rather unconvinced that it's all that common that all > > > subtransactions are on one page. If you have concurrency - otherwise > > > there'd be not much point in this pat

Re: [HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund wrote: > Hi, > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: >> Do I understand correctly the only way know availability PREPARE it will >> appeal to pg_prepared_statements? >> I think this is not a good practice. In some cases, we may not be aw

Re: [HACKERS] improving GROUP BY estimation

Hi, Tomas! On Mon, Mar 21, 2016 at 2:39 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Fri, Mar 18, 2016 at 1:20 PM, Dean Rasheed > wrote: > >> Probably a better URL to give is >> http://www.adellera.it/investigations/distinct_balls/ which has a link >> to the PDF version of the

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Tue, Mar 22, 2016 at 6:52 AM, Andres Freund wrote: > I'm actually rather unconvinced that it's all that common that all > subtransactions are on one page. If you have concurrency - otherwise > there'd be not much point in this patch - they'll usually be heavily > interleaved, no? You can argue

Re: [HACKERS] NOT EXIST for PREPARE

* Merlin Moncure (mmonc...@gmail.com) wrote: > On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund wrote: > > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: > >> Do I understand correctly the only way know availability PREPARE it will > >> appeal to pg_prepared_statements? > >> I think this is not

Re: [HACKERS] NOT EXIST for PREPARE

On 2016-03-22 09:37:15 -0500, Merlin Moncure wrote: > On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund wrote: > > Hi, > > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: > >> Do I understand correctly the only way know availability PREPARE it will > >> appeal to pg_prepared_statements? > >> I th

Re: [HACKERS] NOT EXIST for PREPARE

* Andres Freund (and...@anarazel.de) wrote: > On 2016-03-22 09:37:15 -0500, Merlin Moncure wrote: > > On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund wrote: > > > Hi, > > > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: > > >> Do I understand correctly the only way know availability PREPARE it

Re: [HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 11:50 AM, Stephen Frost wrote: > > I agree that PREPARE IF NOT EXISTS would be nice to have, but only if we > can keep it fast somehow, which is the part that makes me wonder a bit. > Skip error if already exists when catched in src/backend/commands/prepare.c isn't enough?

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On 2016-03-22 10:40:28 -0400, Robert Haas wrote: > On Tue, Mar 22, 2016 at 6:52 AM, Andres Freund wrote: > > I'm actually rather unconvinced that it's all that common that all > > subtransactions are on one page. If you have concurrency - otherwise > > there'd be not much point in this patch - the

Re: [HACKERS] Some messages of pg_rewind --debug not getting translated

Seems reasonable. For the last hunk in your patch, though, I would add a /* translator: */ comment explaining what each of the values is; otherwise it's just incomprehensible percent-sign-salad for the poor translator. Note that if the line is too long you have to use dirty tricks to avoid pginde

Re: [HACKERS] [PATCH] we have added support for box type in SP-GiST index

On 3/21/16 7:41 PM, Stas Kelvich wrote: While people tends to use machine learning and regressions models more and more it is interesting to have some general n-dim indexing with kNN, but I think it is different problem and should be solved in a different way. I think one of the issues here is

Re: [HACKERS] NOT EXIST for PREPARE

Fabrízio de Royes Mello wrote: Skip error if already exists when catched in src/backend/commands/prepare.c isn't enough? I think that's enough. And expand PrepareStmt of course. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsq

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Tue, Mar 22, 2016 at 2:48 PM, Michael Paquier wrote: > On Mon, Mar 21, 2016 at 11:07 PM, Robert Haas > wrote: > > Well, I said before and I'll say again that I don't like the idea of > > multiple password verifiers. I think that's an accident waiting to > > happen, and I'm not prepared to pu

[HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 9:53 AM, Andres Freund > wrote: > On 2016-03-22 09:37:15 -0500, Merlin Moncure wrote: >> On Tue, Mar 22, 2016 at 8:01 AM, Andres Freund > wrote: >> > Hi, >> > On 2016-03-22 12:41:43 +0300, Yury Zhuravlev wrote: >> >> Do I understand correctly the only way know availability P

Re: [HACKERS] [PATCH] we have added support for box type in SP-GiST index

tend to think of a *point* as having *zero* dimensions. Would it perhaps be more accurate to say we are treating a 2-dimensional box as a point in 4-dimensional space? Exactly, sorry for ambiguity. -- Teodor Sigaev E-mail: teo...@sigaev.ru

Re: [HACKERS] [PATCH] we have added support for box type in SP-GiST index

Isn't this basically the same thing that the cube contrib module does? (Which has the added benefit of kNN-capable operators). No, cube module introduces new type - N-dimensional box. And adds an index support for it. Current patch suggests non-traditional indexing technique for 2D boxes by

Re: [HACKERS] Updated backup APIs for non-exclusive backups

Hi Magnus, On 3/19/16 8:15 AM, Magnus Hagander wrote: > I've attached an updated patch, which is rebased on current master and > includes the oid fix. Before doing a thorough review of this patch there are a few points I would like to consider: * I think it's really important to provide the sto

Re: [HACKERS] Updated backup APIs for non-exclusive backups

On Tue, Mar 22, 2016 at 5:08 PM, David Steele wrote: > > On 3/19/16 8:15 AM, Magnus Hagander wrote: > > > I've attached an updated patch, which is rebased on current master and > > includes the oid fix. > > Before doing a thorough review of this patch there are a few points I > would like to cons

Re: [HACKERS] Minor bug affecting ON CONFLICT lock wait log messages

Stephen Frost wrote: > I don't think either message really fits here, unfortunately. We're not > actually checking the uniqueness of someone else's tuple here either, > after all, we're waiting to see what happens with their tuple because > ours won't be unique if it goes in with that other tuple

Re: [HACKERS] Updated backup APIs for non-exclusive backups

On 3/22/16 12:14 PM, Magnus Hagander wrote: > On Tue, Mar 22, 2016 at 5:08 PM, David Steele > wrote: > > On 3/19/16 8:15 AM, Magnus Hagander wrote: > > > I've attached an updated patch, which is rebased on current master and > > includes the oid fix. > >

Re: [HACKERS] Updated backup APIs for non-exclusive backups

On Tue, Mar 22, 2016 at 5:27 PM, David Steele wrote: > On 3/22/16 12:14 PM, Magnus Hagander wrote: > > On Tue, Mar 22, 2016 at 5:08 PM, David Steele > > wrote: > > > > On 3/19/16 8:15 AM, Magnus Hagander wrote: > > > > > I've attached an updated patch, which i

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On 3/15/16 3:42 AM, Peter Geoghegan wrote: > On Tue, Mar 15, 2016 at 12:31 AM, Amit Langote > wrote: >> Ah, I see the nuance. Thanks for the explanation. Maybe, >> bt_index_check() and bt_index_parent_child_check() / >> bt_index_check_parent_child(). IMHO, the latter more clearly highlights >>

Re: [HACKERS] WAL logging problem in 9.4.3?

On 3/15/16 10:01 PM, Kyotaro HORIGUCHI wrote: > Ok, I understand that this is not an issue in a hurry. I'll go to > another patch that needs review. Since we're getting towards the end of the CF is it time to pick this up again? Thanks, -- -David da...@pgmasters.net -- Sent via pgsql-hackers

Re: [HACKERS] pg_ctl promote wait

On 3/16/16 12:19 PM, David Steele wrote: > Hi Peter, > > On 3/9/16 3:08 PM, Michael Paquier wrote: > >> Here are some comments about 0002 > <...> >> I think that we had better do something like the attached first. >> Thoughts? > > It's been a week since Michael reviewed this patch. Could you pl

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

Hi Kyotaro, On 3/18/16 3:22 AM, Pavel Stehule wrote: > I am looking this patch. It looks well, but this feature doesn't > respect upper or lower chars. It enforce upper chars. This is not > consistent with any other autocomplete. > > > I checked it against sql help and these stateme

Re: [HACKERS] Relation extension scalability

On 22/03/16 10:15, Dilip Kumar wrote: On Mon, Mar 21, 2016 at 8:10 PM, Amit Kapila mailto:amit.kapil...@gmail.com>> wrote: 11. +{ +/* +* First try to get the lock in no-wait mode, if succeed extend one + * block, else get the lock in normal mode and after we get the loc

Re: [HACKERS] NOT EXIST for PREPARE

You already have a patch? If yes I'm glad to review it. Please. Patch in attachment. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Companydiff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c index cec37ce..63d164f 100644 --- a/

Re: [HACKERS] NOT EXIST for PREPARE

Yury Zhuravlev wrote: You already have a patch? If yes I'm glad to review it. Please. Patch in attachment. Fix bug, forgot change attr number in parser. And, I forgot example: PREPARE usrrptplan (int) IF NOT EXISTS AS SELECT * FROM pg_operator; PREPARE New patch in attachment. -- Yury

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

On Tue, Mar 22, 2016 at 11:08 PM, Fujii Masao wrote: > On Tue, Mar 22, 2016 at 9:58 PM, Kyotaro HORIGUCHI > wrote: >> Thank you for the revised patch. > > Thanks for reviewing the patch! > >> This version looks to focus on n-priority method. Stuffs for the >> other methods like n-quorum has been

Re: [HACKERS] NOT EXIST for PREPARE

Yury Zhuravlev wrote: > Fabrízio de Royes Mello wrote: > >You already have a patch? If yes I'm glad to review it. > > If the community is not against it, I'll do it quickly. Changing the syntax > is the risk. In addition, we have already missed 9.6. Also we're in the middle of a commitfest, and i

Re: [HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 2:32 PM, Alvaro Herrera wrote: > > Yury Zhuravlev wrote: > > Fabrízio de Royes Mello wrote: > > >You already have a patch? If yes I'm glad to review it. > > > > If the community is not against it, I'll do it quickly. Changing the syntax > > is the risk. In addition, we have

Re: [HACKERS] NOT EXIST for PREPARE

On Tue, Mar 22, 2016 at 2:19 PM, Yury Zhuravlev wrote: > > Yury Zhuravlev wrote: >>> >>> You already have a patch? If yes I'm glad to review it. >>> >> Please. Patch in attachment. > > > Fix bug, forgot change attr number in parser. And, I forgot example: > PREPARE usrrptplan (int) IF NOT EXISTS A

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Tue, Mar 22, 2016 at 9:33 AM, David Steele wrote: > It looks like an updated patch is expected here, though it seems that > the only requests are for updates to comments. That's right - I have a small number of feedback items to work through. I also determined myself that there could be a very

Re: [HACKERS] BRIN is missing in multicolumn indexes documentation

> Good catch! > > In addtion to your patch, we should add the description for > the multicolumn brin index, like the following one in the doc? > > --- > A multicolumn GIN index can be used with query conditions that > involve any subset of the index's columns. Unlike B-tree or GiST, > i

  1   2   >