Re: [HACKERS] [bug fix] Memory leak in dblink

From: "Tom Lane" In the first query, the MemoryContextReset is nearly free since there's nothing to free (and we've special-cased that path in aset.c). It's certainly a measurement artifact that it measures out faster, which says to me that these numbers can only be trusted within a couple perc

Re: [HACKERS] Proposal for CSN based snapshots

Hi, On Fri, Jun 13, 2014 at 7:24 PM, Heikki Linnakangas wrote: > Yeah, that seems like a better design, after all. > > Attached is a new patch. It now keeps the current pg_clog unchanged, but > adds a new pg_csnlog besides it. pg_csnlog is more similar to pg_subtrans > than pg_clog: it's not WAL-

Re: [HACKERS] Built-in support for a memory consumption ulimit?

On Tue, Jun 17, 2014 at 04:39:51PM -0400, Tom Lane wrote: > Robert Haas writes: > > We could do better by accounting for memory usage ourselves, inside > > the memory-context system, but that'd probably impose some overhead we > > don't have today. > I wonder how practical it would be to forestal

Re: [HACKERS] idle_in_transaction_timeout

On 06/19/2014 06:33 PM, Josh Berkus wrote: Tom, ISTM our realistic options are for seconds or msec as the unit. If it's msec, we'd be limited to INT_MAX msec or around 600 hours at the top end, which seems like enough to me but maybe somebody thinks differently? Seconds are probably OK but I'

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus wrote: > Tom, > > > ISTM our realistic options are for seconds or msec as the unit. If it's > > msec, we'd be limited to INT_MAX msec or around 600 hours at the top end, > > which seems like enough to me but maybe somebody thinks differently? > > Seconds are probably OK but I'm worrie

Re: [HACKERS] [bug fix] Memory leak in dblink

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2014 04:36 PM, Tom Lane wrote: > In the first query, the MemoryContextReset is nearly free since > there's nothing to free (and we've special-cased that path in > aset.c). It's certainly a measurement artifact that it measures > out faster,

Re: [HACKERS] How about a proper TEMPORARY TABLESPACE?

On Wed, Jun 18, 2014 at 10:39 PM, Matheus de Oliveira < matioli.math...@gmail.com> wrote: > > I was going to answer each message, but Fabrízio summarized everything so far really nicely. Thanks Fabrízio. > You're welcome. :-) > > On Wed, Jun 18, 2014 at 5:25 PM, Fabrízio de Royes Mello < fabrizi

Re: [HACKERS] [bug fix] Memory leak in dblink

Joe Conway writes: > Not the most scientific of tests, but I think a reasonable one: > ... > 2.7% performance penalty I made a slightly different test based on the original example. This uses generate_series() which is surely faster than a SQL function, so it shows the problem to a larger degree:

Re: [HACKERS] pg_stat directory and pg_stat_statements

Fujii-san, I found the right description in REL9_3_STABLE branch, thanks for pointing out the commit. Sorry for noise. 2014-06-18 12:39 GMT+09:00 Fujii Masao : > On Tue, Jun 17, 2014 at 2:11 PM, Shigeru Hanada > wrote: >> Fujii-san, >> >> I agree not to backpatch, but I noticed that the 9.3 doc

Re: [HACKERS] -DDISABLE_ENABLE_ASSERT

Andres Freund writes: > Hm, that missed a couple things. Updated patch attached. Besides adding > the missed documentation adjustments this also removes the -A > commandline/startup packet parameter since it doesn't serve a purpose > anymore. > Does anyone think we should rather keep -A and have i

Re: [HACKERS] -DDISABLE_ENABLE_ASSERT

On 2014-06-19 19:31:28 +0200, Andres Freund wrote: > On 2014-05-23 10:01:37 -0400, Tom Lane wrote: > > Andres Freund writes: > > > The next question is whether to wait till after the branching with this? > > > > +1 for waiting (it's only a couple weeks anyway). This isn't a > > user-facing featu

Re: [HACKERS] [bug fix] Memory leak in dblink

From: "Joe Conway" Fair enough -- this patch does it at that level in materializeQueryResult() I'm in favor of this. TBH, I did this at first, but I was afraid this would be rejected due to the reason mentioned earlier. if statement in PG_TRY block is not necessary like this, because sinfo

Re: [HACKERS] idle_in_transaction_timeout

Tom, > ISTM our realistic options are for seconds or msec as the unit. If it's > msec, we'd be limited to INT_MAX msec or around 600 hours at the top end, > which seems like enough to me but maybe somebody thinks differently? > Seconds are probably OK but I'm worried about somebody complaining th

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus writes: > Now ... can we decrease CPU overhead (wakeups) if we only check once per > minute? If so, there's a good argument for making 1min the minimum. Polling wakeups are right out, and are unnecessary anyway. The utils/misc/timeout.c infrastructure calculates the time left till

Re: [HACKERS] change alter user to be a true alias for alter role

On 06/19/2014 07:18 PM, Tom Lane wrote: > Jov writes: >> the doc say: >>> ALTER USER is now an alias for ALTER >>> ROLE > >> but alter user lack the following format: >> ... > > If we're going to have a policy that these commands b

Re: [HACKERS] idle_in_transaction_timeout

On 06/19/2014 02:44 PM, Kevin Grittner wrote: > Josh Berkus wrote: > >> Also, I really hope that nobody is setting this to 10s ... > > Well, we get to decide what the minimum allowed value is. What do > you think that should be? 1s? I don't think that setting it to 1s would ever be a good ide

Re: [HACKERS] idle_in_transaction_timeout

Josh Berkus wrote: > Also, I really hope that nobody is setting this to 10s ... Well, we get to decide what the minimum allowed value is.  What do you think that should be? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing

Re: [HACKERS] idle_in_transaction_timeout

On 06/19/2014 10:39 AM, David G Johnston wrote: > Advocating for the Devil (or a more robust, if probably complicated, > solution): > "idle_in_transaction_timeout=10s" > "idle_in_transaction_target=session|transaction" Per Kevin Grittner's assessment, aborting the transaction is currently a nonsta

Re: [HACKERS] WIP patch for multiple column assignment in UPDATE

2014-06-19 15:37 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > I did some tests and It looks so it allows only some form of nested loop. > > [ shrug... ] It's a subplan. One evaluation per outer row is what > people are expecting. > ok regards Pavel > > regards, t

Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal and patch

On Mon, Jun 9, 2014 at 11:12 AM, johnlumby wrote: > updated version of patch compatible with git head of 140608, > (adjusted proc oid and a couple of minor fixes) Compilation of patched version on MacOS failed. The error messages were gcc -O0 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclarat

Re: [HACKERS] Minmax indexes

On Wed, Jun 18, 2014 at 8:51 AM, Heikki Linnakangas wrote: > > I liked Greg's sketch of what the opclass support functions would be. It > doesn't seem significantly more complicated than what's in the patch now. Which was On Tue, Jun 17, 2014 at 8:48 PM, Greg Stark wrote: > An aggregate to gen

Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal and patch

On Thu, Jun 19, 2014 at 2:49 PM, Greg Stark wrote: > I don't think the threaded implementation on Linux is the one to use > though. I find this *super* confusing but the kernel definitely > supports aio syscalls, glibc also has a threaded implementation it > uses if run on a kernel that doesn't im

Re: [HACKERS] Extended Prefetching using Asynchronous IO - proposal and patch

On Wed, May 28, 2014 at 2:19 PM, Heikki Linnakangas wrote: > How portable is POSIX aio nowadays? Googling around, it still seems that on > Linux, it's implemented using threads. Does the thread-emulation > implementation cause problems with the rest of the backend, which assumes > that there is on

Re: [HACKERS] idle_in_transaction_timeout

On Thu, Jun 19, 2014 at 12:40 PM, Abhijit Menon-Sen-2 [via PostgreSQL] < ml-node+s1045698n5808016...@n5.nabble.com> wrote: > At 2014-06-19 17:53:17 +0200, [hidden email] > wrote: > > > > I much prefer with "in" but it doesn't much matter. > >

Re: [HACKERS] -DDISABLE_ENABLE_ASSERT

On 2014-05-23 10:01:37 -0400, Tom Lane wrote: > Andres Freund writes: > > The next question is whether to wait till after the branching with this? > > +1 for waiting (it's only a couple weeks anyway). This isn't a > user-facing feature in any way, so I feel no urgency to ship it in 9.4. Here's

Re: [HACKERS] Minmax indexes

On Thu, Jun 19, 2014 at 10:06 AM, Heikki Linnakangas wrote: > On 06/18/2014 06:09 PM, Claudio Freire wrote: >> >> On Tue, Jun 17, 2014 at 8:48 PM, Greg Stark wrote: >>> >>> An aggregate to generate a min/max "bounding box" from several values >>> A function which takes an "bounding box" and a new

Re: [HACKERS] change alter user to be a true alias for alter role

Jov writes: > the doc say: >> ALTER USER is now an alias for ALTER >> ROLE > but alter user lack the following format: > ... If we're going to have a policy that these commands be exactly equivalent, it seems like this patch is jus

Re: [HACKERS] Crash on backend exit w/ OpenLDAP [2.4.24, 2.4.31]

Noah Misch writes: > On Thu, Jun 12, 2014 at 05:02:19PM -0400, Noah Misch wrote: >> You can cause the at-exit crash by building PostgreSQL against OpenLDAP >> 2.4.31, connecting with LDAP authentication, and issuing "LOAD 'dblink'". >> 4. Detect older OpenLDAP versions at runtime, just before we

Re: [HACKERS] Crash on backend exit w/ OpenLDAP [2.4.24, 2.4.31]

On Thu, Jun 12, 2014 at 05:02:19PM -0400, Noah Misch wrote: > You can cause the at-exit crash by building PostgreSQL against OpenLDAP > 2.4.31, connecting with LDAP authentication, and issuing "LOAD 'dblink'". > 4. Detect older OpenLDAP versions at runtime, just before we would otherwise > initial

Re: [HACKERS] idle_in_transaction_timeout

At 2014-06-19 17:53:17 +0200, vik.fear...@dalibo.com wrote: > > I much prefer with "in" but it doesn't much matter. If you look at similar settings like statement_timeout, lock_timeout, etc., what comes before the _timeout is a concrete *thing* that can timeout, or that a timeout can be applied to

Re: [HACKERS] Re: [REVIEW] Re: Re: BUG #9578: Undocumented behaviour for temp tables created inside query language (SQL) functions

Haribabu Kommi writes: > Updated patch attached. I revised this a bit more and committed it. regards, tom lane -- 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] Minmax indexes

On Wed, Jun 18, 2014 at 4:51 AM, Heikki Linnakangas wrote: > Implementing something is a good way to demonstrate how it would look like. > But no, I don't insist on implementing every possible design whenever a new > feature is proposed. > > I liked Greg's sketch of what the opclass support functi

Re: [HACKERS] [bug fix] Memory leak in dblink

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2014 08:18 AM, Tom Lane wrote: > The code is really designed to put all the setup for storeRow into > one place; but I concur with Joe that having teardown in a > different place from setup isn't very nice. > > An alternative that might be wo

Re: [HACKERS] [bug fix] Memory leak in dblink

Joe Conway writes: >> Probably so. I'll try to scrounge up some time to test the >> performance impact of your patch. > Not the most scientific of tests, but I think a reasonable one: > ... > 2.7% performance penalty Thanks. While that's not awful, it's enough to be annoying. I think we could

Re: [HACKERS] [bug fix] Memory leak in dblink

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2014 09:18 AM, Tom Lane wrote: > I think we could mitigate this by allocating the argument context > once in nodeFunctionscan setup, and passing it into > ExecMakeTableFunctionResult; so we'd only do a memory context reset > not a create/delet

Re: [HACKERS] change alter user to be a true alias for alter role

On 01/20/2014 03:31 PM, Jov wrote: > the doc say: > > ALTER USER is now an alias for ALTER ROLE > . > > > but alter user lack the following format: > > [...] > > this make alter user a true alias for alter role. This is

Re: [HACKERS] Atomics hardware support table & supported architectures

On 2014-06-19 11:00:51 -0400, Alvaro Herrera wrote: > Merlin Moncure wrote: > > On Thu, Jun 19, 2014 at 7:07 AM, Abhijit Menon-Sen > > wrote: > > > Let's not pretend to support platforms we have no practical way of > > > verifying. > > > > This is key. The buildfarm defines the set of platforms

Re: [HACKERS] [bug fix] Memory leak in dblink

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2014 08:50 AM, Alvaro Herrera wrote: > Joe Conway wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 06/18/2014 08:50 PM, Joe Conway wrote: >>> On 06/18/2014 08:45 PM, Tom Lane wrote: Well, we usually think memory leaks are

Re: [HACKERS] idle_in_transaction_timeout

At 2014-06-19 08:42:01 -0700, kgri...@ymail.com wrote: > > I'm not sure whether using the same name as pgbouncer for the same > functionality makes it less confusing or might lead to confusion > about which layer is disconnecting the client. I don't think the names of the respective configuration

Re: [HACKERS] delta relations in AFTER triggers

Kevin Grittner wrote: > I've already said that I now think we should use the standard > CREATE TRIGGER syntax to specify the transition tables, and that > if we do that we don't need the reloption that's in the patch. > If you ignore the 19 lines of new code to add that reloption, > absolutely 1

Re: [HACKERS] idle_in_transaction_timeout

On 06/19/2014 05:42 PM, Kevin Grittner wrote: > Abhijit Menon-Sen wrote: >> At 2014-06-19 10:58:34 +0200, pavel.steh...@gmail.com wrote: > >>> pgbouncer has idle_transaction_timeout defined some years >>> without any problems, so we can take this design >>> >>> idle_transaction_timeout >> >> Let'

Re: [HACKERS] [bug fix] Memory leak in dblink

Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/18/2014 08:50 PM, Joe Conway wrote: > > On 06/18/2014 08:45 PM, Tom Lane wrote: > >> Well, we usually think memory leaks are back-patchable bugs. I'm > >> a bit worried about the potential performance impact of an extra

Re: [HACKERS] idle_in_transaction_timeout

Abhijit Menon-Sen wrote: > At 2014-06-19 10:58:34 +0200, pavel.steh...@gmail.com wrote: >> pgbouncer has idle_transaction_timeout defined some years >> without any problems, so we can take this design >> >> idle_transaction_timeout > > Let's steal the name too. :-) > > (I didn't realise there was

Re: [HACKERS] [bug fix] Memory leak in dblink

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/18/2014 08:50 PM, Joe Conway wrote: > On 06/18/2014 08:45 PM, Tom Lane wrote: >> Well, we usually think memory leaks are back-patchable bugs. I'm >> a bit worried about the potential performance impact of an extra >> memory context creation/del

Re: [HACKERS] [bug fix] Memory leak in dblink

"MauMau" writes: > From: "Joe Conway" >> Any objections to me back-patching it this way? > I thought the same at first before creating the patch, but I reconsidered. > If the query executed by dblink() doesn't return any row, the context > creation and deletion is a waste of processing. I thi

Re: [HACKERS] Atomics hardware support table & supported architectures

Merlin Moncure wrote: > On Thu, Jun 19, 2014 at 7:07 AM, Abhijit Menon-Sen > wrote: > > Let's not pretend to support platforms we have no practical way of > > verifying. > > This is key. The buildfarm defines the set of platforms we support. This means that either Renesas should supply us with

Re: [HACKERS] [bug fix] Memory leak in dblink

From: "Joe Conway" I think the context deletion was missed in the first place because storeRow() is the wrong place to create the context. Rather than creating the context in storeRow() and deleting it two levels up in materializeQueryResult(), I think it should be created and deleted in the int

Re: [HACKERS] Atomics hardware support table & supported architectures

On Thu, Jun 19, 2014 at 7:07 AM, Abhijit Menon-Sen wrote: > Let's not pretend to support platforms we have no practical way of > verifying. This is key. The buildfarm defines the set of platforms we support. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows

On Thu, Jun 19, 2014 at 11:13 PM, MauMau wrote: > * The patch applies cleanly. Running "grep -lir wsock32 ." after applying > the patch shows that wsock32.lib is no longer used. > However, I wonder if some DLL entries in dlls[] in > src/interfaces/libpq/win32.c should be removed. winsock.dll sho

Re: [HACKERS] calculation for NUM_FIXED_LWLOCKS

On Thu, Jun 19, 2014 at 7:41 PM, Kevin Grittner wrote: > > Kevin Grittner wrote: > > > Will commit a fix shortly. > > Fixed exactly as Amit suggested. Pushed to master and 9.4 branches. Thanks for looking into it. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] postgresql.auto.conf read from wrong directory

On Thu, Jun 19, 2014 at 5:21 PM, Fujii Masao wrote: > > On Wed, Jun 18, 2014 at 1:07 PM, Abhijit Menon-Sen wrote: > > At 2014-06-18 12:55:36 +0900, masao.fu...@gmail.com wrote: > >> > >> Also I'm thinking to backpatch this to 9.4 because this is a bugfix > >> rather than new feature. > > > > That

Re: [HACKERS] calculation for NUM_FIXED_LWLOCKS

Kevin Grittner wrote: > Will commit a fix shortly. Fixed exactly as Amit suggested.  Pushed to master and 9.4 branches. Thanks! -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows

From: "Michael Paquier" You are right, I only though about the MS scripts when working on this patch. Updated patch for a complete cleanup is attached (note I updated manually ./configure for test purposes and did not re-run autoconf). I marked this patch as ready for committer. I confirmed:

Re: [HACKERS] IMPORT FOREIGN SCHEMA statement

>> This seems to be related to re-using the table-name between invocations. The >> attached patch should fix point 2. As for point 1, I don't know the cause for >> it. Do you have a reproducible test case ? > Sure. I'll try harder when looking in more details at the patch for > postgres_fdw :) With

Re: [HACKERS] pg_receivexlog add synchronous mode

On Mon, Jun 16, 2014 at 7:03 PM, wrote: >> You introduced the state machine using the flag "flush_flg" into >> pg_receivexlog. >> That's complicated and would reduce the readability of the source code. >> I think that the logic should be simpler like walreceiver's one. >> >> Maybe I found one pro

Re: [HACKERS] Minmax indexes

Vik Fearing writes: > On 06/18/2014 12:46 PM, Andres Freund wrote: >> So to implement a feature one now has to implement the most generic >> variant as a prototype first? Really? > Well, there is the inventor's paradox to consider. I have not seen anyone demanding a different implementation in t

Re: [HACKERS] WIP patch for multiple column assignment in UPDATE

Pavel Stehule writes: > I did some tests and It looks so it allows only some form of nested loop. [ shrug... ] It's a subplan. One evaluation per outer row is what people are expecting. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] calculation for NUM_FIXED_LWLOCKS

Amit Kapila wrote: > #define PREDICATELOCK_MANAGER_LWLOCK_OFFSET \ > (NUM_INDIVIDUAL_LWLOCKS + NUM_LOCK_PARTITIONS) > In this PREDICATELOCK_MANAGER_LWLOCK_OFFSET > should consider NUM_BUFFER_PARTITIONS which means > it should be: > > #define PREDICATELOCK_MANAGER_LWLOCK_OFFSET \ > (LOCK_MANAGER_

Re: [HACKERS] Minmax indexes

On 06/18/2014 06:09 PM, Claudio Freire wrote: On Tue, Jun 17, 2014 at 8:48 PM, Greg Stark wrote: An aggregate to generate a min/max "bounding box" from several values A function which takes an "bounding box" and a new value and returns the new "bounding box" A function which tests if a value is

Re: [HACKERS] Atomics hardware support table & supported architectures

At 2014-06-19 13:33:03 +0200, p...@2ndquadrant.com wrote: > > I think quite the opposite, it's better to say we don't support the > obscure platform than saying that we do and have no active testing or > proof that it indeed does and somebody finding the hard way that there > are issues. Yes, I st

Re: [HACKERS] postgresql.auto.conf read from wrong directory

On Wed, Jun 18, 2014 at 1:07 PM, Abhijit Menon-Sen wrote: > At 2014-06-18 12:55:36 +0900, masao.fu...@gmail.com wrote: >> >> Also I'm thinking to backpatch this to 9.4 because this is a bugfix >> rather than new feature. > > That sounds reasonable, thanks. Committed! Regards, -- Fujii Masao

Re: [HACKERS] Atomics hardware support table & supported architectures

On 18/06/14 17:15, Robert Haas wrote: 6) armv-v5 I think this is also a bit less dead than the other ones; Red Hat's shows Bugzilla shows people filing bugs for platform-specific problems as recently as January of 2013: https://bugzilla.redhat.com/show_bug.cgi?id=892378 Closed as WONTFIX :P.

[HACKERS] calculation for NUM_FIXED_LWLOCKS

Currently the calculation for NUM_FIXED_LWLOCKS is as below, which I think has some problem: /* Offsets for various chunks of preallocated lwlocks. */ #define BUFFER_MAPPING_LWLOCK_OFFSET NUM_INDIVIDUAL_LWLOCKS #define LOCK_MANAGER_LWLOCK_OFFSET \ (BUFFER_MAPPING_LWLOCK_OFFSET + NUM_BUFFER_PAR

Re: [HACKERS] Minmax indexes

On 06/18/2014 12:46 PM, Andres Freund wrote: >>> Isn't 'simpler implementation' a valid reason that's already been >>> > >discussed onlist? Obviously simpler implementation doesn't trump >>> > >everything, but it's one valid reason... >>> > >Note that I have zap to do with the design of this featur

Re: [HACKERS] GSoC on WAL-logging hash indexes

On 04/30/2014 11:41 PM, Tom Lane wrote: > We really oughta fix the WAL situation, not just band-aid around it. After re-reading this thread, it is not clear that anyone is going to work on it so I'll just ask: Is anyone working on this? If not, I'd like to put it on my plate. -- Vik -- Sen

Re: [HACKERS] idle_in_transaction_timeout

At 2014-06-19 10:58:34 +0200, pavel.steh...@gmail.com wrote: > > Hello > > pgbouncer has idle_transaction_timeout defined some years without any > problems, so we can take this design > > idle_transaction_timeout Let's steal the name too. :-) (I didn't realise there was precedent in pgbouncer,

Re: [HACKERS] idle_in_transaction_timeout

Hello pgbouncer has idle_transaction_timeout defined some years without any problems, so we can take this design idle_transaction_timeout If client has been in "idle in transaction" state longer, it will be disconnected. [seconds] Default: 0.0 (disabled) This feature can be very important, and

Re: [HACKERS] replication commands and log_statements

On 12/06/14 20:37, Fujii Masao wrote: On Wed, Jun 11, 2014 at 11:55 PM, Tom Lane wrote: Andres Freund writes: Your wish just seems like a separate feature to me. Including replication commands in 'all' seems correct independent of the desire for a more granular control. No, I think I've got

Re: [HACKERS] Removing dependency to wsock32.lib when compiling code on WIndows

On Wed, Jun 18, 2014 at 8:37 PM, MauMau wrote: > Doing "grep -lir wsock32 ." shows the following files. Could you modify and > test these files as well for code cleanup? > ./configure > ./configure.in > ./contrib/pgcrypto/Makefile > ./src/interfaces/libpq/Makefile > ./src/interfaces/libpq/win32.c

Re: [HACKERS] WIP patch for multiple column assignment in UPDATE

Hello I did some tests and It looks so it allows only some form of nested loop. postgres=# explain (analyze, timing off, buffers) update a1 set b = (select b from a2 where a1.a = a2.a); QUERY PLAN --