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 EXEC

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 again > >> by 6647248e.

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 man

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 release will _not_

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 new package *would* f

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 RC

[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 mailto:tomas.von...@2ndquadrant.com>> 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 such as: select * from t where my

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 th

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 tim

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 th

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 Momjian http

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

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 changes to your subs

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 pg_stat_statements > was: > >

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 stuff like "CREATE SCHEMA

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 very good plan to me. I me

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 already discussed in [1]. >> >> select a.database[1], b.datnam

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 amgetbitmap is documented thusly

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 > >> practical standpoint, a “b

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 rearranged to avoid that,

[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 about perhaps enabling > extra optimisations when the p

[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 approach that I don't see mentioned on

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] Simon talked about perhaps enab

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 “unknown” for most people, and from 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 standpoint, a “best effo

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 be

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 don't think it is worth it to throw a number of chang

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 freezing, even though that is not necessar

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 this: >> ... > Being

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

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 On Dec 29, 2015 4:47 PM, "Tom

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

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 li

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 > considered a bug. T

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

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 failure if SSL_read wer

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: ht

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 by optimized code. Ye

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 80788a431e. Specifically se

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 yo

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?

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 it'

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] 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 actual rows, I > thi

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. 4

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?

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 > http://archives.postgresql.org/message-id/CADT4RqBo79_0Vx%

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 the tsvectors. OTOH I don't se

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 ar

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 better to provide nothin

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. > > You think it sho

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 in

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 reasonable to me.

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 rea

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 W

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 Windows (versions 10 and

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 http://archives.postgresql.org/message-id/CADT4RqBo79_0Vx%3D-%2By%3DnFv3zdnm_-CgGzbtSv9Lh

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 15.10. Nor OS X

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, reltuples/relpages), with a fallback to 100 >>> if relpages=0. This'd only b

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 runni

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

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 Ubun

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 posteritie

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 designs. >> At first,

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 if the bitmap scan node has >> the parent

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. We should focus on adding pg_s

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() - '5 mons'::interval)) >> Rows Removed by

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 bottlenecked by other th

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 dependency failures are

[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] 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 Blocks: lossy=128 >

--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 >> absurdly optimizing toward

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 enough situation. I don't want

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 32bits forever, so > showing a

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 one right >> at that

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 changing lwlock.h (autotool

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: > Andres Freund wrote: > > On 20

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 pr

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

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

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 prob

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 work

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] 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 > get any useful commenta

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, refa

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 confusion. It's probably too l

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

[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 " wit

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,

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 wrote: > > > I wonder whet

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 > pg_hba_lookup('postgres','kommih','::1') >

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. We should focus on adding p

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 will cost more than > some given t