Re: [HACKERS] Why doesn't src/backend/port/win32/socket.c implement bind()?

On Sun, Jan 10, 2016 at 11:55 PM, Tom Lane wrote: > > Some of the Windows buildfarm members occasionally fail like this: > > LOG: could not bind IPv4 socket: No error > HINT: Is another postmaster already running on port 64470? If not, wait a few seconds and retry. >

Re: [HACKERS] PATCH: add pg_current_xlog_flush_location function

On Mon, Jan 11, 2016 at 1:15 PM, Amit Kapila wrote: > On Mon, Jan 11, 2016 at 3:29 AM, Tomas Vondra > wrote: >> >> Hi, >> >> On 12/13/2015 08:38 PM, Tomas Vondra wrote: >>> >>> Hi, >>> >>> On 12/13/2015 06:13 AM, Amit Kapila wrote: >>> >

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Fri, Jan 8, 2016 at 3:37 AM, Magnus Hagander wrote: >> /me waves hand >> >> There are quite a few contributing companies that likely have people that >> could help out with this in an educated fashion but aren't coders. > > Sort of like how they could also have helped

Re: [HACKERS] Apparently deprecated code in planner.c

On Sun, Jan 10, 2016 at 5:28 PM, Dickson S. Guedes wrote: > Hi all, > > I'm wondering whether the #ifdef FORCE_PARALLEL_MODE code [1] was deprecated: > > * > * FIXME: It's assumed that code further down will set parallelModeNeeded > * to true if a parallel

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On 01/10/2016 06:19 PM, Robert Haas wrote: [snip] No arguments with what was written above. If we had an "issue" tracker rather than a bug tracker, I'd expect a lot more unproductive bickering. This I disagree with. It wouldn't be any worse than we have now. An issue tracker (if it is a

Re: [HACKERS] Improved tab completion for FDW DDL

The second part is not necessary, because there is already code that completes FDW names after "FOREIGN DATA WRAPPER". So this already works. The other two parts are valid improvements, but they should be done consistently across commands. So please - Also complete RENAME TO in ALTER FOREIGN

Re: [HACKERS] [COMMITTERS] pgsql: Avoid pin scan for replay of XLOG_BTREE_VACUUM

On Sun, Jan 10, 2016 at 3:50 PM, Simon Riggs wrote: > On 10 January 2016 at 16:32, Robert Haas wrote: >> >> On Sat, Jan 9, 2016 at 5:13 AM, Simon Riggs wrote: >> > Avoid pin scan for replay of XLOG_BTREE_VACUUM >> > Replay of

Re: [HACKERS] ExecGather() + nworkers

On Sun, Jan 10, 2016 at 4:44 PM, Peter Geoghegan wrote: >> I don't really understand why this should be so. I thought the idea >> of parallel sort is (roughly) that each worker should read data until >> it fills work_mem, sort that data, and write a tape. Repeat until no >>

Re: [HACKERS] POC, WIP: OR-clause support for indexes

On 27 December 2015 at 07:04, Teodor Sigaev wrote: > I'd like to present OR-clause support for indexes. Although OR-clauses > could be supported by bitmapOR index scan it isn't very effective and such > scan lost any order existing in index. We (with Alexander Korotkov) >

Re: [HACKERS] ExecGather() + nworkers

On Mon, Jan 11, 2016 at 3:14 AM, Peter Geoghegan wrote: > > On Sun, Jan 10, 2016 at 9:13 AM, Robert Haas wrote: > >> I'm not sure why the test for nworkers following the > >> LaunchParallelWorkers() call doesn't look like this, though: > >> > >> /* Set

Re: [HACKERS] PATCH: add pg_current_xlog_flush_location function

On Mon, Jan 11, 2016 at 3:29 AM, Tomas Vondra wrote: > Hi, > > On 12/13/2015 08:38 PM, Tomas Vondra wrote: > >> Hi, >> >> On 12/13/2015 06:13 AM, Amit Kapila wrote: >> > >> >>> ... >>> >> > >> >>> Is there a reason why you can't use existing function >>>

Re: [HACKERS] checkpointer continuous flushing

On Sat, Jan 9, 2016 at 7:10 PM, Andres Freund wrote: > > On 2016-01-09 19:05:54 +0530, Amit Kapila wrote: > > Right that won't be acceptable, however I think with your latest > > proposal [1] > > Sure, that'd address that problem. > > > > [...] think that idea will help to

Re: [HACKERS] ExecGather() + nworkers

> > > More importantly, I have other, entirely general concerns. Other major > > RDBMSs have settings that are very similar to max_parallel_degree, > > with a setting of 1 effectively disabling all parallelism. Both Oracle > > and SQL Server have settings that they both call the "maximum degree >

Re: [HACKERS] [COMMITTERS] pgsql: Blind attempt at a Cygwin fix

On Sun, Jan 10, 2016 at 8:10 AM, Michael Paquier wrote: > On Sun, Jan 10, 2016 at 2:00 AM, Andrew Dunstan wrote: >> I downloaded the official Cygwin packages into a Cygwin instance and checked >> how they do things. As I rather expected, they do

Re: [HACKERS] Speedup twophase transactions

On 9 January 2016 at 20:28, Stas Kelvich wrote: > Thanks a lot for your edits, now that patch is much more cleaner. > > > Your comments say > > > > "In case of crash replay will move data from xlog to files, if that > hasn't happened before." > > > > but I don't see

Re: [HACKERS] GIN pending list clean up exposure to SQL

On 29/12/2015 00:30, Jeff Janes wrote: > On Wed, Nov 25, 2015 at 9:29 AM, Jeff Janes wrote: >> >> I'll prepare a patch for core for the January commitfest, and see if >> it flies. If not, there is always the extension to fall back to. > > Here is an updated patch. I've

Re: [HACKERS] Spelling corrections

On 10 January 2016 at 19:34, Peter Geoghegan wrote: > Attached patch fixes a couple of misspellings. > Snap! http://www.postgresql.org/message-id/CAKJS1f-AGgQaurTwhY=wkJjspgDcmDUE8Yx03XTXCDz=kae...@mail.gmail.com -- David Rowley http://www.2ndQuadrant.com/

Re: [HACKERS] [COMMITTERS] pgsql: Avoid pin scan for replay of XLOG_BTREE_VACUUM

On Sat, Jan 9, 2016 at 5:13 AM, Simon Riggs wrote: > Avoid pin scan for replay of XLOG_BTREE_VACUUM > Replay of XLOG_BTREE_VACUUM during Hot Standby was previously thought to > require > complex interlocking that matched the requirements on the master. This > required >

Re: [HACKERS] ExecGather() + nworkers

On Sun, Jan 10, 2016 at 12:29 AM, Peter Geoghegan wrote: > The Gather node executor function ExecGather() does this: > [ code ] > I'm not sure why the test for nworkers following the > LaunchParallelWorkers() call doesn't look like this, though: > > /* Set up tuple queue

Re: [HACKERS] strange CREATE INDEX tab completion cases

On 12/13/15 9:16 AM, Michael Paquier wrote: > Please see the attached to address those things (and others) with > extra fixes for a couple of comments. I have ported these changes to the new world order and divided them up into more logical changes that are more clearly documented. Please check

Re: [HACKERS] Fwd: Re: [DOCS] Document Upper Limit for NAMEDATELEN in pgsql 9.5+

On Fri, Jan 8, 2016 at 3:05 PM, Tom Lane wrote: > [ redirecting from -docs, which isn't the best place to discuss code fixes ] > > Whoever thought this was a good idea: > > StaticAssertStmt(NAMEDATALEN <= MAX_LEVENSHTEIN_STRLEN, > "Levenshtein hinting

Re: [HACKERS] [COMMITTERS] pgsql: Avoid pin scan for replay of XLOG_BTREE_VACUUM

On 10 January 2016 at 16:32, Robert Haas wrote: > On Sat, Jan 9, 2016 at 5:13 AM, Simon Riggs wrote: > > Avoid pin scan for replay of XLOG_BTREE_VACUUM > > Replay of XLOG_BTREE_VACUUM during Hot Standby was previously thought to > require > >

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

Hi, On 01/10/2016 01:08 AM, Peter Geoghegan wrote: On Sat, Jan 9, 2016 at 11:02 AM, Tomas Vondra wrote: So, this seems to bring reasonable speedup, as long as the selectivity is below 50%, and the data set is sufficiently large. What about semijoins? Apparently

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

Hi, On 01/10/2016 04:03 AM, Peter Geoghegan wrote: On Sat, Jan 9, 2016 at 4:08 PM, Peter Geoghegan wrote: Also, have you considered Hash join conditions with multiple attributes as a special case? I'm thinking of cases like this: Sorry, accidentally fat-fingered my enter

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

Hi, On 01/10/2016 05:11 AM, Peter Geoghegan wrote: On Sat, Jan 9, 2016 at 11:02 AM, Tomas Vondra wrote: Which means the "dim.r" column has 100 different values (0-99) with uniform distribution. So e.g. "WHERE r < 15" matches 15%. I think that the use of a

[HACKERS] Why doesn't src/backend/port/win32/socket.c implement bind()?

Some of the Windows buildfarm members occasionally fail like this: LOG: could not bind IPv4 socket: No error HINT: Is another postmaster already running on port 64470? If not, wait a few seconds and retry. WARNING: could not create listen socket for "127.0.0.1" FATAL: could not create any

Re: [HACKERS] pglogical - logical replication contrib module

On 01/09/2016 01:30 PM, Steve Singer wrote: On 12/31/2015 06:34 PM, Petr Jelinek wrote: I'm not really sure what to do to 'recover' my cluster at this point so I'll send this off and rebuild my cluster and start over. I had a setup test1--->test2 (with 2 tables in the default set) I

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

On 11 January 2016 at 09:30, Tomas Vondra wrote: > Hi, > > On 01/10/2016 04:03 AM, Peter Geoghegan wrote: > >> On Sat, Jan 9, 2016 at 4:08 PM, Peter Geoghegan wrote: > > Also, are you aware of this? >> >> >>

[HACKERS] Close handle leak in SSPI auth

Hello, here's a one-line patch to close a handle leak in pg_SSPI_recvauth(). According to the docs, the token retrieved with QuerySecurityContextToken() must be closed. -- Christian diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c new file mode 100644 index 0131bfd..57c2f48

Re: [HACKERS] ExecGather() + nworkers

On Sun, Jan 10, 2016 at 9:13 AM, Robert Haas wrote: >> I'm not sure why the test for nworkers following the >> LaunchParallelWorkers() call doesn't look like this, though: >> >> /* Set up tuple queue readers to read the results. */ >> if (pcxt->nworkers_launched >

Re: [HACKERS] COPY (... tab completion

I think this would be a useful addition. A couple of problems: This change in the comment doesn't make sense to me and doesn't seem to match the code: - /* If we have COPY [BINARY] , complete it with "TO" or "FROM" */ + /* If we have COPY|BINARY , complete it with "TO" or "FROM" */

Re: [HACKERS] ExecGather() + nworkers

On Sun, Jan 10, 2016 at 1:44 PM, Peter Geoghegan wrote: > With parallel sequential scan, a max_parallel_degree of 8 could result > in 16 processes scanning in parallel. I meant a max_worker_processes setting, which of course is different. Nevertheless, I find it surprising that

[HACKERS] Apparently deprecated code in planner.c

Hi all, I'm wondering whether the #ifdef FORCE_PARALLEL_MODE code [1] was deprecated: * * FIXME: It's assumed that code further down will set parallelModeNeeded * to true if a parallel path is actually chosen. Since the core * parallelism code isn't committed yet, this

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Fri, Jan 8, 2016 at 7:12 AM, Greg Stark wrote: > This really sounds like you're looking for leverage to fix one problem > by finding other problems that you hope to solve with the same hammer. > That's a recipe for a tool that solves neither problem well and gets > ignored by

Re: [HACKERS] Copy-pasto in logical decoding docs

On 12/31/15 10:45 PM, Petr Jelinek wrote: > I noticed that the filter callback is documented as > LogicalDecodeChangeCB in the logical decoding docs. Here is one-line > patch to fix it. applied to master and 9.5 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] COPY (... tab completion

Peter Eisentraut writes: > I think this would be a useful addition. A couple of problems: > This change in the comment doesn't make sense to me and doesn't seem to > match the code: > - /* If we have COPY [BINARY] , complete it with "TO" or "FROM" */ > + /* If we have

Re: [HACKERS] PATCH: add pg_current_xlog_flush_location function

Hi, On 12/13/2015 08:38 PM, Tomas Vondra wrote: Hi, On 12/13/2015 06:13 AM, Amit Kapila wrote: > ... > Is there a reason why you can't use existing function GetFlushRecPtr() in xlog.c? No, not really. I think I somehow missed that function when writing the initial version of the patch.

Re: [HACKERS] COPY (... tab completion

On 1/10/16 8:01 PM, Peter Eisentraut wrote: > The list of commands to allow as the "query" inside the parentheses is > documented to be: SELECT, VALUES, INSERT, UPDATE or DELETE; and actually > TABLE should also work. Your list doesn't include all of those. To be fair, this is actually a recent