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

On Thu, Mar 24, 2016 at 5:18 AM, Petr Jelinek wrote: > Hmm I see you are right, I missed the last couple emails. Ok I'll mark it > ready for committer - it does work fine on my vs2015 machine and I am happy > with the code too. Thanks, let's see what others have to say. >

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

Hello, At Thu, 24 Mar 2016 13:04:49 +0900, Masahiko Sawada wrote in

Re: [HACKERS] Show dropped users' backends in pg_stat_activity

Hi, At Tue, 22 Mar 2016 22:47:16 -0500, Jim Nasby wrote in <56f211c4.6010...@bluetreble.com> > On 3/22/16 10:35 PM, Kyotaro HORIGUCHI wrote: > >> Even if we maintained some interlock for a backend's login role > >> identity, > >> >I hardly think it would be practical

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

On Thu, Mar 24, 2016 at 8:08 AM, Amit Kapila wrote: > > On Thu, Mar 24, 2016 at 5:40 AM, Andres Freund wrote: > > > > Even after changing to scale 500, the performance benefits on this, > > older 2 socket, machine were minor; even though contention on

Re: [HACKERS] Fix for OpenSSL error queue bug

Peter Geoghegan writes: > 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? I'm generally okay with the approach used in

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

On 2016/03/24 11:14, Michael Paquier wrote: 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

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

On Thu, Mar 24, 2016 at 11:34 AM, Fujii Masao wrote: > 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] Odd system-column handling in postgres_fdw join pushdown patch

On 2016/03/23 13:44, Ashutosh Bapat wrote: An FDW can choose not to use those functions, so I don't see a connection between scan list having simple Vars and existence of those functions (actually a single one). But having those function would minimize the code that each FDW has to write, in

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

I wrote: > Having said that, I also notice these dependencies: > ... > src/bin/initdb/encnames.c -> ../../../src/backend/utils/mb/encnames.c > src/interfaces/libpq/encnames.c -> ../../../src/backend/utils/mb/encnames.c > ... > which seem like they'd be better handled by moving those files into >

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] 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 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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).*

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] 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).*

* 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).*

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] 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] 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] 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] 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] 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] 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, * 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] Relation extension scalability

On 23/03/16 19:39, Robert Haas wrote: 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

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

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] 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] 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] 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] 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] 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] 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] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 12:46 PM, Vladimir Sitnikov wrote: > 2016-03-23 16:21 GMT+03:00 Merlin Moncure : > Merlin> A typical pattern is for the application to > Merlin> prepare them all upon startup, but currently each PREPARE needs to be > Merlin>

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] 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] [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] 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] 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] 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] 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] 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] [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] 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

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

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. Here is an example not involving PostGIS. Is this an intentional

[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] 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] [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator

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 convoluted. I rewrote it - I believe > more straightforwardly - as attached.

Re: [HACKERS] NOT EXIST for PREPARE

On Wed, Mar 23, 2016 at 8:21 AM, Merlin Moncure wrote: > I'm not understanding the objection at all. You have N client > sessions connecting to the database that all utilize the same named > prepared statement. A typical pattern is for the application to > prepare them all

Re: [HACKERS] NOT EXIST for PREPARE

> PS Who use ecpg? For me it's like hell.  More than you think. I doubt you want to propose removing features that make developing new features harder, or do you? :) Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot

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

On Wed, Mar 23, 2016 at 10:57 AM, Jim Nasby wrote: > On 3/22/16 8:37 AM, Merlin Moncure wrote: >>> >>> I afraid of useless and forgotten call of functions. But the risk is same >>> >like PERFORM - so this is valid from one half. The PERFORM statement >>> > holds >>>

Re: [HACKERS] WIP: Upper planner pathification

On 3/22/16 7:28 AM, Michael Paquier wrote: 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

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

> Thanks! I can't think of anything else to worry about with regards to > that version, so I have committed it. > Thanks, Robert. And thanks everyone for contributing to this patch. -- Best regards, Aleksander Alekseev http://eax.me/ -- Sent via pgsql-hackers mailing list

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

On Tue, Mar 22, 2016 at 9:25 PM, Tomas Vondra wrote: > OK, the new code seems more comprehensible to me. 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

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

On 3/22/16 8:37 AM, Merlin Moncure wrote: I afraid of useless and forgotten call of functions. But the risk is same >like PERFORM - so this is valid from one half. The PERFORM statement holds >special semantic, and it is interesting. I see your point here, but the cost of doing that far

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

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 src/backend/replication/logical . That's nice, but you attached the one in src/backend/replication

Re: [HACKERS] NOT EXIST for PREPARE

Fabrízio de Royes Mello wrote: I got an error when build this patch. I fix it! All tests pass (include ecpg tests). Patch in attachment. Thanks. PS Who use ecpg? For me it's like hell. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Companydiff

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

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] 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: "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

[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] 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

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

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

  1   2   >