Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?

Bruce Momjian wrote: > On Tue, Dec 29, 2015 at 02:08:19PM -0500, Bruce Momjian wrote: > > In the Windows MSVC build, we handle pg_config_os.h in the Perl scripts, > > but not dynloader.h. The attached patch copies the process used for > > pg_config_os.h to handle dynloader.h. I believe this is

[HACKERS] Re: More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)

On 12/30/2015 10:30 PM, David Rowley wrote: On 31 December 2015 at 01:24, Tomas Vondra > wrote: Personally I'd like to see automatic plan caching occur in PostgreSQL. There is a bit of a problem with it in regards to a query

Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?

On Wed, Dec 30, 2015 at 11:57:45PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > Oops. Once this patch is applied, it is only going to take effect when > > someone _installs_ Postgres. Even an initdb will not add the file. > > This means that upgrading to the next minor

Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?

Bruce Momjian writes: > Oops. Once this patch is applied, it is only going to take effect when > someone _installs_ Postgres. Even an initdb will not add the file. > This means that upgrading to the next minor release will _not_ fix this. Uh, what? Surely an upgrade to a

Re: [HACKERS] [POC] FETCH limited by bytes.

> > >> I believe it won't be needed as a regression test but DEBUGn >> messages could be usable to see "what was sent to the remote >> side". It can be shown to the console so easily done in >> regression test. See the deocumentation for client_min_messages >> for details. (It could receive far

Re: [HACKERS] Additional role attributes && superuser review

On Tue, Dec 29, 2015 at 08:35:50AM -0500, Stephen Frost wrote: > * Noah Misch (n...@leadboat.com) wrote: > The one argument which you've put forth for adding the complexity of > dumping catalog ACLs is that we might reduce the number of default > roles provided to the user. Right. If "GRANT

Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?

On Wed, Dec 30, 2015 at 11:18:45PM -0300, Alvaro Herrera wrote: > > This suggests that we perhaps should consider this for 9.5.0, and that > > your hack will have to be active until 9.4 gets to end-of-life, or > > perhaps 9.5 if we can't get this into 9.5.0. People who are using 9.5 > > Beta or

Re: [HACKERS] Better detail logging for password auth failures

On Wed, Dec 30, 2015 at 10:18:35AM -0500, Tom Lane wrote: > Andres Freund writes: > > On 2015-12-29 11:07:26 -0500, Tom Lane wrote: > >> In passing, the patch gets rid of a vestigial CHECK_FOR_INTERRUPTS() > >> call; it was added by e710b65c and IMO should have been removed

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Andres Freund writes: > FWIW, the > if (sock == PGINVALID_SOCKET) > wakeEvents &= ~(WL_SOCKET_READABLE | WL_SOCKET_WRITEABLE); > block in both latch implementations looks like a problem waiting to happen. You think it should throw an error instead? Seems

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2015-12-30 19:38:23 +0200, Shay Rojansky wrote: > > Hm. So that seems to indicate that, on windows, we're not properly > > recognizing dead sockets in the latch code. Could you check, IIRC with > > netstat or something like it, in what state the connections are? > netstat shows the socket is

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

> On 30 Dec 2015, at 18:38, Emre Hasegeli wrote: > >> which is much closer to the actual number of rows removed by the index >> recheck + the one left. > > Is it better to be closer? We are saying those are the "actual" > values not the estimates. If we cannot provide the

Re: --enable-depend by default (was Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex)

On 2015-12-30 10:49:27 -0500, Tom Lane wrote: > > On Wed, Dec 30, 2015 at 5:44 PM, Andres Freund wrote: > >> I still maintain that --enable-depend should be on by default. We're > >> absurdly optimizing towards saving a handful of cycles in scenarios > >> which are usually

Re: [HACKERS] --enable-depend by default (was Re: Patch: fix lock contention for HASHHDR.mutex)

Greg Stark writes: > Alternately the buildfarm could be changed to retain earlier builds and use > dependencies to reduce build times. This would have the benefit of > detecting dependency failures. At the expense of a lot more noise, at least > until we Orrin out whatever

Re: [HACKERS] --enable-depend by default (was Re: Patch: fix lock contention for HASHHDR.mutex)

On 2015-12-30 11:13:31 -0500, Tom Lane wrote: > The buildfarm already made its choice in this area, and that's ccache. > Layering --enable-depend on top of builds that are using ccache is > simply a waste. > > (Admittedly, ccache is gcc-specific, but TTBOTMK so is --enable-depend.) For

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Hi, On 2015-12-30 19:01:10 +0200, Shay Rojansky wrote: > OK, I finally found some time to dive into this. > > The backends seem to hang when the client closes a socket without first > sending a Terminate message - some of the tests make this happen. I've > confirmed this happens with 9.5rc1

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Shay Rojansky writes: > The backends seem to hang when the client closes a socket without first > sending a Terminate message - some of the tests make this happen. I've > confirmed this happens with 9.5rc1 running on Windows (versions 10 and 7), > but this does not occur on Ubuntu

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

Emre Hasegeli writes: >> which is much closer to the actual number of rows removed by the index >> recheck + the one left. > Is it better to be closer? We are saying those are the "actual" > values not the estimates. If we cannot provide the actual rows, I > think it is

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2015-12-30 12:41:56 -0500, Tom Lane wrote: > Andres Freund writes: > > FWIW, the > > if (sock == PGINVALID_SOCKET) > > wakeEvents &= ~(WL_SOCKET_READABLE | WL_SOCKET_WRITEABLE); > > block in both latch implementations looks like a problem waiting to happen.

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Andres Freund writes: > On 2015-12-30 12:30:43 -0500, Tom Lane wrote: >> Nor OS X. Ugh. My first thought was that ac1d7945f broke this, but >> that's only in HEAD not 9.5, so some earlier change must be responsible. > The backtrace in >

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2015-12-30 12:50:58 -0500, Tom Lane wrote: > Right, and what I was wondering was whether adding the additional wait-for > condition had exposed some pre-existing flaw in the Windows latch code. > But that's not it, so we're left with the conclusion that we broke > something that used to work.

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2015-12-30 20:12:07 +0200, Shay Rojansky wrote: > > > > Is this in a backend with ssl? > > > > No. There goes that theory. Amongst others. The aforementioned problem with waitfor doesn't seem to be actually armed because waitfor is only used if errno == EWOULDBLOCK || errno == EAGAIN. > If

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2015-12-30 20:18:52 +0200, Shay Rojansky wrote: > Tom's probably right about the optimized code. I could try compiling a > debug version.. Seems to be the next unfortunately. Sorry. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

> On 30 Dec 2015, at 17:02, Tom Lane wrote: > > Oleksii Kliukin writes: >> Bitmap Heap Scan on example (cost=744.44..757.64 rows=6 width=0) (actual >> time=73.895..73.895 rows=0 loops=1) >> Output: 1 >> Recheck Cond: (example.event_time = (now() -

Re: [HACKERS] custom function for converting human readable sizes to bytes

On Mon, Dec 28, 2015 at 8:45 AM, Shulgin, Oleksandr wrote: > I didn't check out earlier versions of this patch, but the latest one still > changes pg_size_pretty() to emit PB suffix. > > I don't think it is worth it to throw a number of changes together like > that.

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

Oleksii Kliukin writes: >> On 30 Dec 2015, at 17:02, Tom Lane wrote: >> Another idea would be to use the heap's row density as calculated >> by the last ANALYZE (ie, reltuples/relpages), with a fallback to 100 >> if relpages=0. This'd only be convenient

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

> which is much closer to the actual number of rows removed by the index > recheck + the one left. Is it better to be closer? We are saying those are the "actual" values not the estimates. If we cannot provide the actual rows, I think it is better to provide nothing. Something closer to the

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

> > > The backends seem to hang when the client closes a socket without first > > sending a Terminate message - some of the tests make this happen. I've > > confirmed this happens with 9.5rc1 running on Windows (versions 10 and > 7), > > but this does not occur on Ubuntu 15.10. The client runs on

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

> > Hm. Is this with a self compiled postgres? If so, is it with assertions > enabled? > No, it's just the EnterpriseDB 9.5rc1 installer... Tom's probably right about the optimized code. I could try compiling a debug version..

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Andres Freund writes: > On 2015-12-30 19:54:19 +0200, Shay Rojansky wrote: >> wakeEvents is 8387808 and so is sock. > Hm. That seems like an extremely weird value. Probably just means the debugger is confused by optimized code. > I think it's indicative of > a bug in

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Hi, On 2015-12-30 13:17:47 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2015-12-30 19:54:19 +0200, Shay Rojansky wrote: > >> wakeEvents is 8387808 and so is sock. > > > Hm. That seems like an extremely weird value. > > Probably just means the debugger is confused

[HACKERS] custom parameters cannot be removed once set

Today I was reminded of an issue I have run across before, namely that in a given postgres session, once a custom parameter has been set, there is no way to remove it entirely. For example: 8<--- # psql regression psql (9.5rc1) Type "help" for help. regression=# SELECT

Re: [HACKERS] More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)

> On 30 Dec 2015, at 10:16, David Rowley wrote: > > Hi, > > On [1] I suggested an idea to make improvements to the planner around the > Equivalence Class code. Later in [2] Tom raised concerns with this adding too > many planning cycles for a perhaps not common

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

OK, I finally found some time to dive into this. The backends seem to hang when the client closes a socket without first sending a Terminate message - some of the tests make this happen. I've confirmed this happens with 9.5rc1 running on Windows (versions 10 and 7), but this does not occur on

Re: [HACKERS] Tsvector editing functions

Hi, Tomáš! Thanks for comprehensive review. > On 15 Dec 2015, at 06:07, Tomas Vondra wrote: > > 1) It's a bit difficult to judge the usefulness of the API, as I've > always been a mere user of full-text search, and I never had a need > (or courage) to mess with

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2015-12-30 19:54:19 +0200, Shay Rojansky wrote: > > > > Things that'd be interesting: > > 1) what are the arguments passed to WaitLatchOrSocket(), most > >importantly wakeEvents and sock > > > > wakeEvents is 8387808 and so is sock. Hm. That seems like an extremely weird value. I think

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

Oleksii Kliukin writes: > Bitmap Heap Scan on example (cost=744.44..757.64 rows=6 width=0) (actual > time=73.895..73.895 rows=0 loops=1) >Output: 1 >Recheck Cond: (example.event_time = (now() - '5 mons'::interval)) >Rows Removed by Index Recheck: 4030 >Heap

[HACKERS] Re: --enable-depend by default (was Re: Patch: fix lock contention for HASHHDR.mutex)

Alternately the buildfarm could be changed to retain earlier builds and use dependencies to reduce build times. This would have the benefit of detecting dependency failures. At the expense of a lot more noise, at least until we Orrin out whatever dependency failures are there now. Or we could add

Re: [HACKERS] Additional role attributes && superuser review

On Tue, Dec 29, 2015 at 5:35 AM, Stephen Frost wrote: > * Noah Misch (n...@leadboat.com) wrote: >> > Updated patch attached. I'll give it another good look and then commit >> > it, barring objections. >> >> This thread and its satellite[1] have worked their way through a few

[HACKERS] Rationalizing Query.withCheckOptions

The RLS patch added this to struct Query: List *withCheckOptions;/* a list of WithCheckOption's, which * are only added during rewrite and * therefore are not written out as

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

> > > > Any chance you could single-step through WaitLatchOrSocket() with a > > > debugger? Without additional information this is rather hard to > > > diagnose. > > > > > > > Uh I sure can, but I have no idea what to look for :) Anything > > specific? > > Things that'd be interesting: > 1) what

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

> > Things that'd be interesting: > 1) what are the arguments passed to WaitLatchOrSocket(), most >importantly wakeEvents and sock > wakeEvents is 8387808 and so is sock. Tom, this bug doesn't occur with 9.4.4 (will try to download 9.4.5 and test).

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

> > Are we sure this is a 9.5-only bug? Shay, can you try 9.4 branch tip > and see if it misbehaves? Can anyone else reproduce the problem? > > Doesn't occur with 9.4.5 either. The first version I tested which exhibited this was 9.5beta2.

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

> > Is this in a backend with ssl? > No. If you go up one frame, what value does port->sock have? > For some reason VS is telling me "Unable to read memory" on port->sock... I have no idea why that is...

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Andres Freund writes: > There goes that theory. Amongst others. The aforementioned problem with > waitfor doesn't seem to be actually armed because waitfor is only used > if errno == EWOULDBLOCK || errno == EAGAIN. Mumble. It is clearly possible that we'd reach the Assert

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Shay Rojansky wrote: > > > > Are we sure this is a 9.5-only bug? Shay, can you try 9.4 branch tip > > and see if it misbehaves? Can anyone else reproduce the problem? > > > > > Doesn't occur with 9.4.5 either. The first version I tested which exhibited > this was 9.5beta2. Maybe it's time for

Re: [HACKERS] custom parameters cannot be removed once set

On 12/30/2015 10:36 AM, Joe Conway wrote: > A side issue is that it would be nice if there were a way to check for a > custom parameter value without getting an error if it does not exist. > There is a missing_ok option to GetConfigOptionByName(), but we > currently don't expose it from SQL. I'd

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2015-12-30 13:26:34 -0500, Tom Lane wrote: > I doubt that is what is happening here, because those errnos don't > seem sensible for an EOF condition, but I'd still feel more comfortable > if be_tls_read/be_tls_write handled SSL_ERROR_SYSCALL like this: > > if (n != -1) >

Re: [HACKERS] More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)

On 30 December 2015 at 21:12, Benedikt Grundmann wrote: > On Wed, Dec 30, 2015 at 7:16 AM, David Rowley < > david.row...@2ndquadrant.com> wrote: > >> >> A number of ideas were suggested on the other thread about how we might >> go about solving this problem. In [3]

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Andres Freund writes: > On 2015-12-30 13:26:34 -0500, Tom Lane wrote: >> I doubt that is what is happening here, because those errnos don't >> seem sensible for an EOF condition, but I'd still feel more comfortable >> if be_tls_read/be_tls_write handled SSL_ERROR_SYSCALL like

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

> I don’t see how to solve this problem without changing explain analyze output > to accommodate for “unknown” value. I don’t think “0” is a non-confusing > representation of “unknown” for most people, and from the practical > standpoint, a “best effort” estimate is better than 0 (i.e. I will

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

> On 30 Dec 2015, at 21:12, Tom Lane wrote: > > Emre Hasegeli writes: >>> I don’t see how to solve this problem without changing explain analyze >>> output to accommodate for “unknown” value. I don’t think “0” is a >>> non-confusing representation of

Fwd: [HACKERS] Avoid endless futile table locks in vacuuming.

Forgetting to CC the list is starting to become a bad habit, sorry. forwarding to list: -- Forwarded message -- From: Jeff Janes Date: Wed, Dec 30, 2015 at 10:03 AM Subject: Re: [HACKERS] Avoid endless futile table locks in vacuuming. To: Tom Lane

Re: [HACKERS] custom parameters cannot be removed once set

On 12/30/2015 10:44 AM, Tom Lane wrote: > Meh. The real problem here is that people are abusing the custom-GUC > mechanism to implement session-lifespan variables. I do not think we > should encourage that; GUC offers neither adequate features for that > (eg, no way to declare a variable's type)

Re: [HACKERS] custom function for converting human readable sizes to bytes

2015-12-30 17:33 GMT+01:00 Robert Haas : > On Mon, Dec 28, 2015 at 8:45 AM, Shulgin, Oleksandr > wrote: > > I didn't check out earlier versions of this patch, but the latest one > still > > changes pg_size_pretty() to emit PB suffix. > > > > I

Re: [HACKERS] custom parameters cannot be removed once set

Joe Conway writes: > Today I was reminded of an issue I have run across before, namely that > in a given postgres session, once a custom parameter has been set, there > is no way to remove it entirely. True. > This strikes me as, at least, surprising, and possibly should be

Re: Fwd: [HACKERS] Avoid endless futile table locks in vacuuming.

Jeff Janes writes: > On Dec 29, 2015 4:47 PM, "Tom Lane" wrote: >> Uh, isn't that what my patch is doing? > My reading was it does that only if there are no tuples that could be > frozen. If there are tuples that could be frozen, it actually does > the

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

Emre Hasegeli writes: >> I don’t see how to solve this problem without changing explain analyze >> output to accommodate for “unknown” value. I don’t think “0” is a >> non-confusing representation of “unknown” for most people, and from the >> practical

Re: [HACKERS] Additional role attributes && superuser review

On Thu, Dec 31, 2015 at 1:50 AM, Robert Haas wrote: > Under those circumstances, it seems very dubious to proceed > with this. Michael seems to think that we can go ahead and start > changing things and sort out whatever is broken later, but that > doesn't sound like a

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Dec 30, 2015 at 11:21 PM, Alvaro Herrera wrote: > Michael Paquier wrote: > >> OK, here are new patches. >> - 0001 switches a bunch of TailMatches to Matches. Do we want to care >> about the case where a schema is created following by a bunch of >> objects? I mean

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

Tom Lane wrote: > Emre Hasegeli writes: > >> I don’t see how to solve this problem without changing explain analyze > >> output to accommodate for “unknown” value. I don’t think “0” is a > >> non-confusing representation of “unknown” for most people, and from the > >>

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

Alvaro Herrera writes: > Tom Lane wrote: >> We do already have a nearby precedent for returning zero when we don't >> have an accurate answer: that's what BitmapAnd and BitmapOr plan nodes >> do. (This is documented btw, at the bottom of section 14.1.) > Hmm, but

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

On Wed, Dec 30, 2015 at 9:48 PM, Shulgin, Oleksandr wrote: > On Wed, Dec 30, 2015 at 4:31 AM, Haribabu Kommi > wrote: >> >> >> Adding quotes to pg_hba_lookup function makes it different from others. >> The issues regarding the same is

--enable-depend by default (was Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex)

[ A change as significant as this should not be debated in a thread with a title that suggests it's of interest to only one or two people ] > On Wed, Dec 30, 2015 at 5:44 PM, Andres Freund wrote: >> I still maintain that --enable-depend should be on by default. We're >>

Re: [HACKERS] rows estimate in explain analyze for the BRIN index

> On 30 Dec 2015, at 17:44, Tom Lane wrote: > > Oleksii Kliukin writes: >>> On 30 Dec 2015, at 17:02, Tom Lane wrote: >>> Another idea would be to use the heap's row density as calculated >>> by the last ANALYZE (ie,

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2015-12-30 12:30:43 -0500, Tom Lane wrote: > Nor OS X. Ugh. My first thought was that ac1d7945f broke this, but > that's only in HEAD not 9.5, so some earlier change must be responsible. The backtrace in

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Andres Freund writes: > On 2015-12-30 19:01:10 +0200, Shay Rojansky wrote: >> The backends seem to hang when the client closes a socket without first >> sending a Terminate message - some of the tests make this happen. I've >> confirmed this happens with 9.5rc1 running on

[HACKERS] Re: More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)

On 31 December 2015 at 01:24, Tomas Vondra wrote: > On 12/30/2015 08:16 AM, David Rowley wrote: > >> >> I do strongly believe that we need to come up with something to >> solve this problem. I already summarised my thoughts on the other >> thread. >> > > One

Re: Fwd: [HACKERS] Avoid endless futile table locks in vacuuming.

Jeff Janes writes: > So like the attached, although it is a bit weird to call > lazy_check_needs_freeze if , under !scan_all, we don't actually care > about whether it needs freezing but only the hastup. I think this misses unpinning the buffer in the added code path. I

[HACKERS] Re: More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)

On 31 December 2015 at 04:39, Evgeniy Shishkin wrote: > > > On 30 Dec 2015, at 10:16, David Rowley > wrote: > > > > A number of ideas were suggested on the other thread about how we might > go about solving this problem. In [3] Simon talked

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

On Mon, Nov 30, 2015 at 02:41:02PM +0100, Shulgin, Oleksandr wrote: > On Wed, Nov 25, 2015 at 9:13 AM, Lukas Fittl wrote: > > On Mon, Nov 23, 2015 at 11:53 PM, Peter Geoghegan wrote: > > One specific justification he gave for not using

[HACKERS] Still more sanity checking in gincostestimate()

I looked into the problem reported in http://www.postgresql.org/message-id/flat/56830ea5.7080...@squeakycode.net which briefly is that gincostestimate can produce ridicuously large index scan cost estimates for partial-match queries. It appears that there are two basic problems contributing to

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

On Wed, Dec 30, 2015 at 5:20 PM, Bruce Momjian wrote: > Is this a TODO? It's on my (very long) personal TODO list. It would be great if someone else took it, though. So, yes. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

On Wed, Dec 30, 2015 at 05:21:05PM -0800, Peter Geoghegan wrote: > On Wed, Dec 30, 2015 at 5:20 PM, Bruce Momjian wrote: > > Is this a TODO? > > It's on my (very long) personal TODO list. It would be great if > someone else took it, though. So, yes. TODO added. -- Bruce

Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?

On Tue, Dec 29, 2015 at 02:08:19PM -0500, Bruce Momjian wrote: > In the Windows MSVC build, we handle pg_config_os.h in the Perl scripts, > but not dynloader.h. The attached patch copies the process used for > pg_config_os.h to handle dynloader.h. I believe this is the only *.h > file that has

Re: [HACKERS] dynloader.h missing in prebuilt package for Windows?

On 12/30/15 20:40, Bruce Momjian wrote: > your hack will have to be active until 9.4 gets to end-of-life, or > perhaps 9.5 if we can't get this into 9.5.0. People who are using 9.5 > Beta or RC will still not have the file, meaning 9.5 end-of-life might > still be a requirement. ... by which

Re: [HACKERS] CREATE INDEX CONCURRENTLY?

This just hit us today... Admittedly on an old cluster still running 9.2, though I can't see any mention of it being addressed since. Any chance of getting this on to to-do list? On Sat, 1 Nov 2014 at 07:45, Simon Riggs wrote: > On 31 October 2014 17:46, Michael Banck

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

On Wed, Dec 30, 2015 at 4:31 AM, Haribabu Kommi wrote: > > Adding quotes to pg_hba_lookup function makes it different from others. > The issues regarding the same is already discussed in [1]. > > select a.database[1], b.datname from >

Re: [HACKERS] custom function for converting human readable sizes to bytes

On Tue, Dec 29, 2015 at 7:15 PM, Pavel Stehule wrote: > >> I didn't check out earlier versions of this patch, but the latest one >> still changes pg_size_pretty() to emit PB suffix. >> >> I don't think it is worth it to throw a number of changes together like >> that.

Re: [HACKERS] More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)

On Wed, Dec 30, 2015 at 7:16 AM, David Rowley wrote: > > A number of ideas were suggested on the other thread about how we might go > about solving this problem. In [3] Simon talked about perhaps enabling > extra optimisations when the planner sees that the plan

Re: [HACKERS] Better detail logging for password auth failures

On 2015-12-29 11:07:26 -0500, Tom Lane wrote: > In passing, the patch gets rid of a vestigial CHECK_FOR_INTERRUPTS() > call; it was added by e710b65c and IMO should have been removed again > by 6647248e. There's certainly no very good reason to have one right > at that spot anymore. Why? Doesn't

Re: [HACKERS] Making tab-complete.c easier to maintain

Michael Paquier wrote: > OK, here are new patches. > - 0001 switches a bunch of TailMatches to Matches. Do we want to care > about the case where a schema is created following by a bunch of > objects? I mean stuff like "CREATE SCHEMA hoge CREATE TABLE ..." where > the current completion would

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Dec 30, 2015 at 9:14 AM, Michael Paquier wrote: > On Wed, Dec 30, 2015 at 6:26 AM, Thomas Munro wrote: >> I see that you changed INSERT and DELETE (but not UPDATE) to use >> MatchesN rather than TailMatchesN. Shouldn't these stay with >> TailMatchesN for the reason Tom gave above? > > Er,

[HACKERS] Re: More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)

On 12/30/2015 08:16 AM, David Rowley wrote: I do strongly believe that we need to come up with something to solve this problem. I already summarised my thoughts on the other thread. One approach that I don't see mentioned on any of the threads is plan caching, which allows reusing the plan

Re: [HACKERS] pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

On 12/30/2015 06:46 AM, Simon Riggs wrote: On 30 December 2015 at 00:17, Joe Conway > wrote: On 12/29/2015 07:15 AM, Tom Lane wrote: > Yeah. Use of the same x/y notation with two different bases seems like > a recipe for

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

Here is a clean version of the patch. Step 1 is an optimization. Step 2 refactors this: HTAB * ShmemInitHash(const char *name, /* table string name for shmem index */ - long init_size, /* initial table size */ + long init_size, /* initial table size XXX ignored,

Re: [HACKERS] Better detail logging for password auth failures

On Wed, Dec 30, 2015 at 1:07 AM, Tom Lane wrote: > We often tell people to look in the postmaster log for more information > about authentication problems; but an off-list question prompted me to > notice that many of the common authentication failure cases don't actually >

[HACKERS] Improved tab completion for FDW DDL

Hi, Here is a patch which adds the below missing tab completions for the FDW DDL commands. I noticed these were missing while playing around with FDWs a while ago. "ALTER SERVER " with "RENAME TO" "CREATE SERVER FOREIGN DATA WRAPPER" with fdw name "CREATE|ALTER USER MAPPING FOR SERVER "

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

Aleksander Alekseev wrote: > Here is a funny thing - benchmark results I shared 22.12.2015 are wrong > because I forgot to run `make clean` after changing lwlock.h (autotools > doesn't rebuild project properly after changing .h files). Running configure with --enable-depend should avoid this

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

On 2015-12-30 11:37:19 -0300, Alvaro Herrera wrote: > Aleksander Alekseev wrote: > > > Here is a funny thing - benchmark results I shared 22.12.2015 are wrong > > because I forgot to run `make clean` after changing lwlock.h (autotools > > doesn't rebuild project properly after changing .h files).

[HACKERS] rows estimate in explain analyze for the BRIN index

Hi, While experimenting with BRIN on PostgreSQL 9.5RC1 I came across the following plan (which is, btw a very good example of how BRIN rocks for the clustered data, the size of this table is around 90GB, the size of the index is around 3MB): explain (analyze, buffers, verbose) select 1 from

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

Andres Freund wrote: > On 2015-12-30 11:37:19 -0300, Alvaro Herrera wrote: > > Aleksander Alekseev wrote: > > > > > Here is a funny thing - benchmark results I shared 22.12.2015 are wrong > > > because I forgot to run `make clean` after changing lwlock.h (autotools > > > doesn't rebuild project

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

Agree. --enable-depend turned on by default could save me a lot of time. Now I'm aware regarding --enable-depend and `make clean`. Still other people will definitely do the same mistake over and over again. On Wed, 30 Dec 2015 11:49:13 -0300 Alvaro Herrera wrote: >

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

On Wed, Dec 30, 2015 at 5:44 PM, Andres Freund wrote: > On 2015-12-30 11:37:19 -0300, Alvaro Herrera wrote: > > Aleksander Alekseev wrote: > > > > > Here is a funny thing - benchmark results I shared 22.12.2015 are wrong > > > because I forgot to run `make clean` after

Re: [HACKERS] Better detail logging for password auth failures

Andres Freund writes: > On 2015-12-29 11:07:26 -0500, Tom Lane wrote: >> In passing, the patch gets rid of a vestigial CHECK_FOR_INTERRUPTS() >> call; it was added by e710b65c and IMO should have been removed again >> by 6647248e. There's certainly no very good reason to have

Re: [HACKERS] pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

=?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= writes: > On 12/30/2015 06:46 AM, Simon Riggs wrote: >> There is already long precedent about how to represent an XID with an >> epoch... and it is neither of those two formats. > IMHO, we have been telling users that XIDs are