Re: [HACKERS] [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator

On Wed, Mar 23, 2016 at 12:27 PM, Tom Lane wrote: > Robert Haas writes: >> I did not find this version very clear. It wasn't consistent about >> using ObjectIdGetDatum() where needed, but the bigger problem was that >> I found the logic unnecessarily

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 1:15 PM, Vladimir Sitnikov wrote: > Merlin>No one is arguing that that you should send it any every time (at > least -- I hope not). > > Well, what is your suggestion exactly? > > pgjdbc is NOT using "prepare ..." sql command. > I'm inclined to

Re: [HACKERS] NOT EXIST for PREPARE

2016-03-23 16:21 GMT+03:00 Merlin Moncure : > On Wed, Mar 23, 2016 at 7:27 AM, Craig Ringer wrote: Craig>> With PREPARE IF NOT EXISTS the client is also paying parse and network Craig>> overhead for every time you send that statement. Much better not to

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Tom Lane wrote: > Note: the reason for a new subdirectory, rather than putting this > stuff into src/common/, is that src/common/ is meant for code that's > shared between frontend and backend, which this stuff is not. Also, > many of these files depend on libpq which seems like an inappropriate

Re: [HACKERS] Relation extension scalability

On Wed, Mar 23, 2016 at 2:52 PM, Petr Jelinek wrote: >> Second, if the other backend extended the relation in >> some other manner and did not extend the FSM, how does calling >> RecordAndGetPageWithFreeSpace help? As far as I can see, >> GetPageWithFreeSpace and

Re: [HACKERS] NOT EXIST for PREPARE

Merlin>proposed would allow use of server side prepared statements with JDBC. It would not. If we discuss end-to-end scenarios in detail, we would end up with "send full query on each execution" -> lex/gram on each execution kind of overheads. That is hardly a proper way of using prepared

Re: [HACKERS] Postgres_fdw join pushdown - getting server crash in left outer join of three table

On Wed, Mar 23, 2016 at 5:24 AM, Rajkumar Raghuwanshi wrote: > Thanks Ashutosh for the patch. I have apply and retested it, now not getting > server crash. Thanks for the report and the testing. I have committed the patch. -- Robert Haas EnterpriseDB:

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

On Wed, Mar 23, 2016 at 5:55 PM, Tom Lane wrote: > I'm not terribly happy with the hack I used to get pgbench to be able > to borrow psql's psqlscan.l lexer. It's a mess for the MSVC build > scripts, and I have seen it causing two concurrent builds of psqlscan.o > in

Re: [HACKERS] NOT EXIST for PREPARE

Merlin>No one is arguing that that you should send it any every time (at least -- I hope not). Well, what is your suggestion exactly? pgjdbc is NOT using "prepare ..." sql command. I'm inclined to suppose, it will not use "prepare..." even after your fix. Merlin>Again, not in pooling scenarios

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

"David G. Johnston" writes: > On Wednesday, March 23, 2016, Tom Lane wrote: >> ... We've more or less deprecated SRF-in-tlist since we >> introduced LATERAL in 9.3. How much are we willing to do to stay >> bug-compatible with old behaviors here?

Re: [HACKERS] Proposal: Generic WAL logical messages

On 23/03/16 14:17, Alvaro Herrera wrote: Petr Jelinek wrote: +++ b/contrib/test_decoding/sql/messages.sql @@ -0,0 +1,17 @@ +-- predictability +SET synchronous_commit = on; + +SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot', 'test_decoding'); + +SELECT 'msg1' FROM

Re: [HACKERS] multivariate statistics v14

Hi, I'll add couple of code comments from my first cursory read through (this is huge): 0002: there is some whitespace noise between the varlistentries in alter_statistics.sgml + parentobject.classId = RelationRelationId; + parentobject.objectId =

Re: [HACKERS] dealing with extension dependencies that aren't quite 'e'

Hi. I implemented "ALTER FUNCTION … DEPENDS ON EXTENSION" using a new node (AlterObjectDependsStmt), and tried to add "ALTER TRIGGER … DEPENDS ON EXTENSION" (partly because I wanted to make sure the code could support multiple object types, partly because it's convenient in this particular use

Re: [HACKERS] NOT EXIST for PREPARE

Vladimir Sitnikov writes: > 2016-03-23 16:21 GMT+03:00 Merlin Moncure : >> On Wed, Mar 23, 2016 at 7:27 AM, Craig Ringer wrote: > Craig>> With PREPARE IF NOT EXISTS the client is also paying parse and network > Craig>>

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

On Wed, Mar 23, 2016 at 12:37 PM, Tom Lane wrote: > which is both SQL-standard semantics and much more efficient than > SRF-in-tlist. We've more or less deprecated SRF-in-tlist since we > introduced LATERAL in 9.3. How much are we willing to do to stay > bug-compatible with

[HACKERS] Rationalizing code-sharing among src/bin/ directories

I'm not terribly happy with the hack I used to get pgbench to be able to borrow psql's psqlscan.l lexer. It's a mess for the MSVC build scripts, and I have seen it causing two concurrent builds of psqlscan.o in parallel builds, which is likely to cause a build failure some of the time. Another

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

On Wed, Mar 23, 2016 at 12:55 PM, Tom Lane wrote: > I'm not terribly happy with the hack I used to get pgbench to be able > to borrow psql's psqlscan.l lexer. It's a mess for the MSVC build > scripts, and I have seen it causing two concurrent builds of psqlscan.o > in

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

"Regina Obe" writes: > In the past couple of weeks our PostGIS tests against PostgreSQL 9.6 dev > started failing. I traced the issue down to a behavior change in 9.6 when > dealing with output of set returning functions when used with (func).* > syntax. > CREATE OR REPLACE

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

On 23/03/16 09:14, Kouhei Kaigai wrote: On 15/03/16 05:03, Kouhei Kaigai wrote: Petr, The attached patch is the revised one that follows the new extensible- node routine. It is almost same the previous version except for: - custom-apis.[ch] was renamed to custom-node.[ch] - check for the

Re: [HACKERS] Relation extension scalability

On 23/03/16 20:01, Robert Haas wrote: On Wed, Mar 23, 2016 at 2:52 PM, Petr Jelinek wrote: Second, if the other backend extended the relation in some other manner and did not extend the FSM, how does calling RecordAndGetPageWithFreeSpace help? As far as I can see,

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

On Wednesday, March 23, 2016, Tom Lane wrote: > "Regina Obe" > writes: > > In the past couple of weeks our PostGIS tests against PostgreSQL 9.6 dev > > started failing. I traced the issue down to a behavior change in 9.6 > when > > dealing with

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

On 23/03/16 13:05, Michael Paquier wrote: OK, the please send an updated set of patches for what remains. Here you go: - 0001 fixes the global declarations of TIMEZONE_GLOBAL and TZNAME_GLOBAL to be WIN32-compliant. I got bitten by that in the ECPG compilation. - 0002, support of VS2015 in

Re: [HACKERS] NOT EXIST for PREPARE

Merlin> All I'm saying is that the use of Merlin> server side prepared statements is extremely problematic in Merlin> conjunction with pgbouncer I've filed https://github.com/pgbouncer/pgbouncer/issues/126 to get pgbouncer improved in regard to prepared statements. Vladimir -- Sent via

Re: [HACKERS] Relation extension scalability

On Wed, Mar 23, 2016 at 3:33 PM, Petr Jelinek wrote: > Btw thinking about it some more, ISTM that not finding the block and just > doing the extension if the FSM wasn't extended correctly previously is > probably cleaner behavior than what we do now. The reasoning for that >

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > > Actually you could just list them in OBJS_FRONTEND in src/common. That > > way they're not built for the server at all; no need for a new subdir. > > Meh. I think stuff in OBJS_FRONTEND has to be pretty

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 2:17 PM, Vladimir Sitnikov wrote: > Merlin>proposed would allow use of server side prepared statements with JDBC. > > It would not. If we discuss end-to-end scenarios in detail, we would end up > with > "send full query on each execution" ->

Re: [HACKERS] NOT EXIST for PREPARE

Michael Meskes wrote: More than you think. I doubt you want to propose removing features that make developing new features harder, or do you? :) I want to understand the situation. You may want to make the build ecpg optional. Personally, I want to. -- Yury Zhuravlev Postgres Professional:

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Alvaro Herrera writes: > Tom Lane wrote: >> And where to put the corresponding header files? >> src/include/fe-utils? > Sounds fair but would that be installed in PREFIX/include/server? > That'd be a bit odd, but I'm not -1 on that. The only other plan I can think of

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

>> >> Multicolumn BRIN is like GIN. Every column is indexed separately. >> The order of the columns doesn't matter. > > Right. You can use one index to cover all columns; the position of the > column in the index won't matter for a query that uses one column. The > only reason to have multiple

Re: [HACKERS] NOT EXIST for PREPARE

Merlin, * Merlin Moncure (mmonc...@gmail.com) wrote: > No one is arguing that that you should send it any every time (at > least -- I hope not). I'm not sure I follow how you can avoid that though? pgbouncer in transaction pooling mode may let a particular connection die off and then, when you

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

* Merlin Moncure (mmonc...@gmail.com) wrote: > On Wed, Mar 23, 2016 at 12:37 PM, Tom Lane wrote: > > which is both SQL-standard semantics and much more efficient than > > SRF-in-tlist. We've more or less deprecated SRF-in-tlist since we > > introduced LATERAL in 9.3. How

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

On 2016-03-23 12:33:22 +0530, Amit Kapila wrote: > On Wed, Mar 23, 2016 at 12:26 PM, Amit Kapila > wrote: > > > > On Tue, Mar 22, 2016 at 4:22 PM, Andres Freund wrote: > > > > > > > > > I think it's worthwhile to create a benchmark that does something

Re: [HACKERS] Relation extension scalability

On 23/03/16 20:19, Petr Jelinek wrote: On 23/03/16 20:01, Robert Haas wrote: On Wed, Mar 23, 2016 at 2:52 PM, Petr Jelinek wrote: Second, if the other backend extended the relation in some other manner and did not extend the FSM, how does calling

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Alvaro Herrera writes: > Tom Lane wrote: >> Note: the reason for a new subdirectory, rather than putting this >> stuff into src/common/, is that src/common/ is meant for code that's >> shared between frontend and backend, which this stuff is not. Also, >> many of these

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

Stephen Frost writes: > * Merlin Moncure (mmonc...@gmail.com) wrote: >> I'm something of a backwards compatibility zealot, but I've become one >> for very good reasons. Personally, I'd rather we'd define precisely >> the usages that are deprecated (I guess SRF-tlist in the

Re: [HACKERS] Relation extension scalability

On 23/03/16 20:43, Robert Haas wrote: On Wed, Mar 23, 2016 at 3:33 PM, Petr Jelinek wrote: Btw thinking about it some more, ISTM that not finding the block and just doing the extension if the FSM wasn't extended correctly previously is probably cleaner behavior than what

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

> >> On 15/03/16 05:03, Kouhei Kaigai wrote: > >>> Petr, > >>> > >>> The attached patch is the revised one that follows the new extensible- > >>> node routine. > >>> > >>> It is almost same the previous version except for: > >>> - custom-apis.[ch] was renamed to custom-node.[ch] > >>> - check for

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Wed, Mar 23, 2016 at 7:34 AM, Thomas Munro wrote: > synchronous_commitTPS > > off 9234 > local1223 > remote_write 907 > on587 > remote_apply 555 > >

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Wed, Mar 23, 2016 at 8:39 PM, Robert Haas wrote: > On Wed, Mar 23, 2016 at 7:34 AM, Thomas Munro > wrote: >> synchronous_commitTPS >> >> off 9234 >> local1223 >> remote_write

Re: [HACKERS] NOT EXIST for PREPARE

On 22 March 2016 at 21:01, 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

Re: [HACKERS] Bug in searching path in jsonb_set when walking through JSONB array

On 2016-03-23, Oleg Bartunov wrote: > On Wed, Mar 23, 2016 at 6:37 AM, Vitaly Burovoy > wrote: > >> Hello, Hackers! >> >> While I was reviewed a patch with "json_insert" function I found a bug >> which wasn't connected with the patch and reproduced

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

On 23/03/16 08:17, Michael Paquier wrote: On Mon, Mar 21, 2016 at 3:43 AM, Andrew Dunstan wrote: On 03/20/2016 12:02 AM, Michael Paquier wrote: On Sun, Mar 20, 2016 at 8:06 AM, Andrew Dunstan wrote: Still to do: the non-perl pieces. The patch

Re: [HACKERS] Bug in searching path in jsonb_set when walking through JSONB array

On Wed, Mar 23, 2016 at 7:48 PM, Vitaly Burovoy wrote: > On 2016-03-23, Oleg Bartunov wrote: >> On Wed, Mar 23, 2016 at 6:37 AM, Vitaly Burovoy >> wrote: >> >>> Hello, Hackers! >>> >>> While I was reviewed a patch with

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

> > I have a strong feeling that we are just wasting our time here. > > That is possible. However, I would like it if you would give me the > benefit of the doubt and assume that, if I seem to be more cautious > than you would be were you a committer, there might possibly be some > good reasons

Re: [HACKERS] pg_xlogdump fails to handle WAL file with multi-page XLP_FIRST_IS_CONTRECORD data

On Wed, Mar 23, 2016 at 1:13 PM, Michael Paquier wrote: > > + /* > +* Compute targetRecOff. It should typically be greater than short > +* page-header since a valid record can't , but can also be zero > when > +* caller has supplied a

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

> I guess multicolumn BRIN behaves similarly to B-tree or GiST. But I'm > no expert, so I need someone knowledgeable to confirm this. If the > following wording is OK, I will update the patch. Multicolumn BRIN is like GIN. Every column is indexed separately. The order of the columns doesn't

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

On Wed, Mar 23, 2016 at 8:45 PM, Petr Jelinek wrote: > On 23/03/16 08:17, Michael Paquier wrote: >> >> On Mon, Mar 21, 2016 at 3:43 AM, Andrew Dunstan >> wrote: >>> >>> >>> >>> On 03/20/2016 12:02 AM, Michael Paquier wrote: On Sun, Mar

Re: [HACKERS] pg_xlogdump fails to handle WAL file with multi-page XLP_FIRST_IS_CONTRECORD data

On Wed, Mar 23, 2016 at 7:04 PM, Pavan Deolasee wrote: > > > On Wed, Mar 23, 2016 at 1:13 PM, Michael Paquier > wrote: >> >> >> + /* >> +* Compute targetRecOff. It should typically be greater than short >> +* page-header

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

Le 22/03/2016 14:44, Michael Paquier a écrit : > 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

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

> I'm something of a backwards compatibility zealot, but I've become one for > very good reasons. Personally, I'd rather we'd define precisely the usages > that are deprecated (I guess SRF-tlist in the presence of > FROM) and force them to error out with an appropriate HINT rather than give a

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

* David G. Johnston (david.g.johns...@gmail.com) wrote: > On Wed, Mar 23, 2016 at 2:11 PM, Tom Lane wrote: > > In the meantime I suppose there's a case to be made for preserving > > bug compatibility as much as possible. > > > > So anyway the question is whether to commit the

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

On Wed, Mar 23, 2016 at 2:11 PM, Tom Lane wrote: > > ​​ > In the meantime I suppose there's a case to be made for preserving > bug compatibility as much as possible. > > So anyway the question is whether to commit the attached or not. ​+1 for commit - I'll trust Tom on the

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

I wrote: > ... I'd love to > toss the entire SRF-in-tlist feature overboard one of these years, > both because of semantic issues like these and because a fair amount > of code and overhead could be ripped out if it were disallowed. > But I don't know how we get to that --- as Merlin says, there's

Re: [HACKERS] README for src/backend/replication/logical

On 23 March 2016 at 23:54, Alvaro Herrera wrote: > Craig Ringer wrote: > > Hi all > > > > As part of some internal training/discussion I wrote some notes on > logical > > decoding's structure and flow that seemed worth polishing up into a draft > > README for

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Alvaro Herrera wrote: > > tuple = (HeapTuple) palloc0(HEAPTUPLESIZE + len); > > > > which fails because (HEAPTUPLESIZE + len) is again considered > > an invalid size, the size being 1468006476 in my test. > > Um, it seems reasonable to make this one be a huge-zero-alloc: > >

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

On 23/03/16 17:55, Tom Lane wrote: I'm not terribly happy with the hack I used to get pgbench to be able to borrow psql's psqlscan.l lexer. It's a mess for the MSVC build scripts, and I have seen it causing two concurrent builds of psqlscan.o in parallel builds, which is likely to cause a build

Re: [HACKERS] [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator

Robert Haas writes: > On Wed, Mar 23, 2016 at 12:27 PM, Tom Lane wrote: >> I'm also a bit dubious of the assumption in RemoveOperatorById that an >> operator can't be its own negator. Yeah, that should not be the case, >> but if it is the case the

Re: [HACKERS] Relation extension scalability

On Tue, Mar 22, 2016 at 1:12 PM, Petr Jelinek wrote: > I also think the code simplicity makes this worth it. Agreed. I went over this patch and did a cleanup pass today. I discovered that the LockWaiterCount() function was broken if you try to tried to use it on a lock

Re: [HACKERS] Using quicksort for every external sort run

On Wed, Mar 23, 2016 at 8:05 PM, Tomas Vondra wrote: > FWIW, maintenance_work_mem was set to 1GB on the i5 machine and 256MB on the > Xeon. Hmm, maybe that's why we see no difference for CREATE INDEX on the i5, > and an improvement on the Xeon. That would explain

Re: [HACKERS] Using quicksort for every external sort run

Hi, On 03/24/2016 03:00 AM, Peter Geoghegan wrote: On Tue, Mar 22, 2016 at 3:35 PM, Tomas Vondra wrote: I've tested the patch you've sent on 2016/3/11, which I believe is the last version. I haven't tuned the replacement_sort_mem at all. because my understanding

Re: [HACKERS] Bug in searching path in jsonb_set when walking through JSONB array

On Wed, Mar 23, 2016 at 11:01 PM, Tom Lane wrote: > Michael Paquier writes: >> That's ugly. We should actually use TextDatumGetCString because the >> index is stored as text here via a Datum, and then it is converted >> back to an integer. So I

Re: [HACKERS] Fix for OpenSSL error queue bug

On Mon, Mar 14, 2016 at 6:44 PM, Peter Geoghegan wrote: > I can produce a back-patchable variant of this if you and Peter E. > think this approach is okay. Where are we on this? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Using quicksort for every external sort run

On Tue, Mar 22, 2016 at 3:35 PM, Tomas Vondra wrote: > I've tested the patch you've sent on 2016/3/11, which I believe is the last > version. I haven't tuned the replacement_sort_mem at all. because my > understanding was that it's not a 9.6 material (per your

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Wed, Mar 23, 2016 at 10:05 PM, Thom Brown wrote: > I've noticed that you now can't cancel a query if there's DML pushdown > to a foreign server. This previously worked while it was sending > individual statements as it interrupted and rolled it back. > > Here's what the local

Re: [HACKERS] Relation extension scalability

On Wed, Mar 23, 2016 at 9:43 PM, Amit Kapila wrote: > RecordAndGetPageWithFreeSpace() tries to search from the oldPage passed to > it, rather than from top, so even if RecordPageWithFreeSpace() doesn't > update till root, it will be able to search the newly added page.

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

On 2016-03-23 21:43:41 +0100, Andres Freund wrote: > I'm playing around with SELECT txid_current(); right now - that should > be about the most specific load for setting clog bits. Or so I thought. In my testing that showed just about zero performance difference between the patch and master. And

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

On Thu, Mar 24, 2016 at 5:40 AM, Andres Freund wrote: > > On 2016-03-23 21:43:41 +0100, Andres Freund wrote: > > I'm playing around with SELECT txid_current(); right now - that should > > be about the most specific load for setting clog bits. > > Or so I thought. > > In my

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

Hi, On 2016-03-24 01:10:55 +0100, Andres Freund wrote: > I'm afraid that this patch might be putting bandaid on some of the > absolutely worst cases, without actually addressing the core > problem. Simon's patch in [1] seems to come closer addressing that > (which I don't believe it's safe

Re: [HACKERS] WIP: Access method extendability

I don't quite see how this is supposed to work: + #ifdef WAL_DEBUG + /* +* If xlog debug is enabled then check produced delta. Result of delta +* application to saved image should be the same as current page state. +*/ + if (XLOG_DEBUG) + { + chartmp[BLCKSZ]; +

Re: [HACKERS] Relation extension scalability

On Thu, Mar 24, 2016 at 12:09 AM, Robert Haas wrote: > > On Tue, Mar 22, 2016 at 1:12 PM, Petr Jelinek wrote: > > I've read this over several times and looked at > RecordAndGetPageWithFreeSpace() and I'm still confused. First of all, > if the lock

Re: [HACKERS] Rationalizing code-sharing among src/bin/ directories

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> And where to put the corresponding header files? > >> src/include/fe-utils? > > > Sounds fair but would that be installed in PREFIX/include/server? > > That'd be a bit odd, but I'm not -1 on that. > >

Re: [HACKERS] NOT EXIST for PREPARE

On 24 March 2016 at 02:01, Merlin Moncure wrote: > > If you plan to have "prepare if not exists" at startup only, why don't > > you just wrap it with > > exception handler then? > > That's impolite to our users. Virtually all other commands have been > decorated with IF

Re: [HACKERS] PoC: Partial sort

Hi, On Tue, Mar 1, 2016 at 7:06 AM, Alexander Korotkov wrote: > I finally went over your review. I'll respond to your points here. Note that I'm reviewing "partial-sort-basic-7.patch", which you sent on March 13. I respond here because this is where you answered my

Re: [HACKERS] Postgres_fdw join pushdown - getting server crash in left outer join of three table

On Thu, Mar 24, 2016 at 1:53 AM, Robert Haas wrote: > On Wed, Mar 23, 2016 at 5:24 AM, Rajkumar Raghuwanshi > wrote: >> Thanks Ashutosh for the patch. I have apply and retested it, now not getting >> server crash. > > Thanks for the

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

On Wed, Mar 23, 2016 at 5:32 PM, Kyotaro HORIGUCHI wrote: > Hello, > > At Tue, 22 Mar 2016 23:08:36 +0900, Fujii Masao wrote > in

Re: [HACKERS] Using quicksort for every external sort run

On Tue, Mar 22, 2016 at 2:27 PM, Tomas Vondra wrote: > For example these two queries got almost 2x as slow for some data sets: > > SELECT a FROM numeric_test UNION SELECT a FROM numeric_test_padding > SELECT a FROM text_test UNION SELECT a FROM text_test_padding > >

Re: [HACKERS] [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend

On 03/23/2016 01:55 PM, Eduardo Morras wrote: Benefits: Dynamic multihoming, modifiable at run time, don't need aggregate links at OS level or shutdown servers/clients for a hardware or topology network change. Message oriented connection. Message reliability. Inmune to SYN floods that affect

Re: [HACKERS] [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend

Andreas Karlsson escribió: > On 03/23/2016 01:55 PM, Eduardo Morras wrote: > >Benefits: > > > >Dynamic multihoming, modifiable at run time, don't need aggregate links at > >OS level or shutdown servers/clients for a hardware or topology network > >change. > >Message oriented connection. >

Re: [HACKERS] Bug in searching path in jsonb_set when walking through JSONB array

Michael Paquier writes: > That's ugly. We should actually use TextDatumGetCString because the > index is stored as text here via a Datum, and then it is converted > back to an integer. So I propose instead the simple patch attached > that fixes the failure for me. Could

[HACKERS] Add something in struct PGPROC

Hi I just add something in struct PGPORC, such as "int level", But I cann't seet what I added in MyProc while debugging. That's confused, zhangxiaojian

Re: [HACKERS] Postgres_fdw join pushdown - getting server crash in left outer join of three table

On Mon, Mar 21, 2016 at 11:32 PM, Ashutosh Bapat wrote: >> In get_useful_ecs_for_relation, it seems to me that this assertion >> should be removed and replaces by an actual check because even if >> right_ec and left_ec are initialized, we cannot be sure that

Re: [HACKERS] Proposal: Generic WAL logical messages

Petr Jelinek wrote: > +++ b/contrib/test_decoding/sql/messages.sql > @@ -0,0 +1,17 @@ > +-- predictability > +SET synchronous_commit = on; > + > +SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot', > 'test_decoding'); > + > +SELECT 'msg1' FROM pg_logical_emit_message(true,

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

Emre Hasegeli wrote: > > I guess multicolumn BRIN behaves similarly to B-tree or GiST. But I'm > > no expert, so I need someone knowledgeable to confirm this. If the > > following wording is OK, I will update the patch. > > Multicolumn BRIN is like GIN. Every column is indexed separately. > The

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 7:27 AM, Craig Ringer wrote: > With PREPARE IF NOT EXISTS the client is also paying parse and network > overhead for every time you send that statement. Much better not to send it > repeatedly in the first place. How did you determine that? The

[HACKERS] [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend

Hello, I want to propose to add sctp network protocol to backend and frontend code. Light Sctp description: Sctp is a layer 3 network protocol over ip networks, similar to tcp, udp and others. It's message oriented protocol, unlike tcp and udp that are data stream oriented, and it ensures

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On 22 March 2016 at 02:30, Etsuro Fujita wrote: > On 2016/03/19 3:30, Robert Haas wrote: >> >> On Fri, Mar 18, 2016 at 5:15 AM, Etsuro Fujita >> wrote: >>> >>> Attached is the updated version of the patch. I've noticed that you now can't

Re: [HACKERS] multivariate statistics v14

On 03/23/2016 06:20 AM, Tatsuo Ishii wrote: I am now looking into the create statistics doc to see if the example appearing in it is working. I will get back if I find any. I have the ref doc: CREATE STATISTICS There are nice examples how the multivariate statistics gives better row number

Re: [HACKERS] Postgres_fdw join pushdown - getting server crash in left outer join of three table

Thanks Ashutosh for the patch. I have apply and retested it, now not getting server crash. Thanks & Regards, Rajkumar Raghuwanshi QMG, EnterpriseDB Corporation On Mon, Mar 21, 2016 at 8:02 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > Thanks Michael for looking into this. > > >

Re: [HACKERS] NOT EXIST for PREPARE

Fabrízio de Royes Mello wrote: I got an error when build this patch. Thanks for review and tests! I'm working on it. Without ecpg everything works fine. In ecpg we have black perl magic and special rules for PREPARE. The error is in perl script. Regards -- Yury Zhuravlev Postgres

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

On 18.03.2016 20:19, Anastasia Lubennikova wrote: Please, find the new version of the patch attached. Now it has WAL functionality. Detailed description of the feature you can find in README draft https://goo.gl/50O8Q0 This patch is pretty complicated, so I ask everyone, who interested in

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 >

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

On Wed, Mar 23, 2016 at 12:26 PM, Amit Kapila wrote: > > On Tue, Mar 22, 2016 at 4:22 PM, Andres Freund wrote: > > > > > > I think it's worthwhile to create a benchmark that does something like > > BEGIN;SELECT ... FOR UPDATE; SELECT

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

On Wed, Mar 23, 2016 at 12:24 AM, Alvaro Herrera wrote: > 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 >

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

On Mon, Mar 21, 2016 at 3:43 AM, Andrew Dunstan wrote: > > > On 03/20/2016 12:02 AM, Michael Paquier wrote: >> >> On Sun, Mar 20, 2016 at 8:06 AM, Andrew Dunstan >> wrote: >>> >>> >>> Still to do: the non-perl pieces. >> >> The patch to address locales

Re: [HACKERS] Add something in struct PGPROC

> Hi > I just add something in struct PGPORC, such as "int level", But I > cann't seet what I added in MyProc while debugging. That's confused, > > > zhangxiaojian I think you forgot to run `make clean` after changing proc.h. When you change header files dependent files are not

Re: [HACKERS] [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend

On Wed, 23 Mar 2016 14:03:31 +0100 Andreas Karlsson wrote: > On 03/23/2016 01:55 PM, Eduardo Morras wrote: > > Benefits: > > > > Dynamic multihoming, modifiable at run time, don't need aggregate > > links at OS level or shutdown servers/clients for a hardware or > > topology

Re: [HACKERS] [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend

On Wed, 23 Mar 2016 10:13:42 -0300 Alvaro Herrera wrote: > Andreas Karlsson escribió: > > On 03/23/2016 01:55 PM, Eduardo Morras wrote: > > >Benefits: > > > > > >Dynamic multihoming, modifiable at run time, don't need aggregate > > >links at OS level or shutdown

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Wed, Mar 23, 2016 at 8:43 AM, Michael Paquier wrote: > On Wed, Mar 23, 2016 at 8:39 PM, Robert Haas wrote: >> On Wed, Mar 23, 2016 at 7:34 AM, Thomas Munro >> wrote: >>> synchronous_commitTPS >>>

Re: [HACKERS] [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend

On 03/23/2016 02:13 PM, Alvaro Herrera wrote: Andreas Karlsson escribió: On 03/23/2016 01:55 PM, Eduardo Morras wrote: Benefits: Dynamic multihoming, modifiable at run time, don't need aggregate links at OS level or shutdown servers/clients for a hardware or topology network change. Message

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

On Wed, Mar 23, 2016 at 5:49 AM, Aleksander Alekseev wrote: > I still believe that optimizing 1% blindly without considering possible > side effects this optimization can bring (other data alignment, some > additional machine instructions - just to name a few) and

  1   2   >