Re: [HACKERS] StrategyGetBuffer optimization, take 2

On 2013-08-19 15:17:44 -0700, Jeff Janes wrote: > On Wed, Aug 7, 2013 at 7:40 AM, Merlin Moncure wrote: > > > I agree; at least then it's not unambiguously better. if you (in > > effect) swap all contention on allocation from a lwlock to a spinlock > > it's not clear if you're improving things; i

Re: [HACKERS] Personal note: taking some vacation time in Sep/Oct

On 20/08/13 15:26, Tom Lane wrote: I will be taking a long (and long-overdue) vacation from Sep 10 to Oct 20. I expect to have email access, but won't be doing much more than minimally keeping up with my inbox. This means I'll be pretty much AWOL for the September commitfest :-(. That's unfortun

Re: [HACKERS] Backup throttling

2013-08-20 08:37 keltezéssel, Heikki Linnakangas írta: On 19.08.2013 21:15, Boszormenyi Zoltan wrote: 2013-08-19 19:20 keltezéssel, Andres Freund írta: Based on a quick look it seems like you're throttling on the receiving side. Is that a good idea? Especially over longer latency links, TCP buf

Re: [HACKERS] Backup throttling

On 19.08.2013 21:15, Boszormenyi Zoltan wrote: 2013-08-19 19:20 keltezéssel, Andres Freund írta: Based on a quick look it seems like you're throttling on the receiving side. Is that a good idea? Especially over longer latency links, TCP buffering will reduce the effect on the sender side conside

Re: [HACKERS] ereport documentation patch

On 19.08.2013 23:40, Christophe Pettus wrote: Is it reasonable to note in the documentation that ereport does not return if the error severity is greater than or equal to ERROR? Yeah, it probably would be good to mention that. Got a patch? - Heikki -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

2013-08-20 08:13 keltezéssel, Pavel Stehule írta: 2013/8/20 David Fetter mailto:da...@fetter.org>> On Mon, Aug 19, 2013 at 07:45:23PM +0200, Pavel Stehule wrote: > Hello > > Harder maybe but it may still be cleaner in the long run. > > > > Overall, it's my intention h

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

2013/8/20 David Fetter > On Mon, Aug 19, 2013 at 07:45:23PM +0200, Pavel Stehule wrote: > > Hello > > > > Harder maybe but it may still be cleaner in the long run. > > > > > > Overall, it's my intention here to remove as many as feasible of the > old > > >> reasons why one might use an SRF in th

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

On Mon, Aug 19, 2013 at 07:45:23PM +0200, Pavel Stehule wrote: > Hello > > Harder maybe but it may still be cleaner in the long run. > > > > Overall, it's my intention here to remove as many as feasible of the old > >> reasons why one might use an SRF in the select list. > >> > > > > Indeed, it's

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

On 08/20/2013 02:03 AM, Josh Berkus wrote: > On 08/19/2013 09:23 AM, Boszormenyi Zoltan wrote: >> >> Indeed, it's a big nail in the coffin for SRFs-in-targetlist. Having >> WITH ORDINALITY and this feature, I would vote for removing >> SRF-in-targetlist and call the release PostgreSQL 10.0. > > Th

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Tue, Aug 20, 2013 at 10:26 AM, Alvaro Herrera wrote: > Amit Kapila escribió: > >>3. postgresql.conf will contain include directive in below form: >>#include = 'postgresql.auto.conf' >>Whenever user wants to use Alter System, he needs to enable it >> after first time using AL

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

2013-08-19 22:04 keltezéssel, Andrew Gierth írta: Boszormenyi Zoltan wrote: This parser hackery is of course somewhat ugly. But given the objective of implementing the spec's unnest syntax, it seems to be the least ugly of the possible approaches. (The hard part of doing it any other way would b

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

Amit Kapila escribió: >3. postgresql.conf will contain include directive in below form: >#include = 'postgresql.auto.conf' >Whenever user wants to use Alter System, he needs to enable it > after first time using ALTER SYSTEM. This seems wrong to me. If the auto file is read b

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

Tom Lane wrote: > Alvaro Herrera writes: > > Pushed with those fixes, thanks. I noticed we also needed to match > > files global.stat and global.tmp. Also I added another conversion to > > the sscanf pattern, to ignore files named "db_1234.tmp.foo" and such > > (i.e. stuff after whitespace). >

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Tue, Aug 20, 2013 at 9:33 AM, Stephen Frost wrote: > * Amit Kapila (amit.kapil...@gmail.com) wrote: >>Do you mean to say, that when user uses ALTER SYSTEM and include is >> disabled, then we can give ERROR in >>ALTER SYSTEM, that to reflect the values, he need to enable it? >>Actual

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

* Amit Kapila (amit.kapil...@gmail.com) wrote: >Do you mean to say, that when user uses ALTER SYSTEM and include is > disabled, then we can give ERROR in >ALTER SYSTEM, that to reflect the values, he need to enable it? >Actually in previous version of patch, there was WARNING on such a

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Tue, Aug 20, 2013 at 8:43 AM, Stephen Frost wrote: > * Amit Kapila (amit.kapil...@gmail.com) wrote: >> initdb will create the empty auto file. If we don't enable by default, >> then if user uses >> ALTER SYSTEM and do sighup/restart, changed config parameter values >> will not come into affect

Re: [HACKERS] Personal note: taking some vacation time in Sep/Oct

On Tue, Aug 20, 2013 at 12:26 PM, Tom Lane wrote: > I will be taking a long (and long-overdue) vacation from Sep 10 to Oct 20. > I expect to have email access, but won't be doing much more than minimally > keeping up with my inbox. > > This means I'll be pretty much AWOL for the September commitfe

Re: [HACKERS] Fix Windows socket error checking for MinGW

On 08/19/2013 07:35 PM, Noah Misch wrote: That was option #1. (You weren't planning to change just the one symbol causing the failure at hand, were you?) Reasonable choice. The point in the code comment quoted above looks bad, but the lack of reports of that nature against official 9.2 binarie

[HACKERS] Personal note: taking some vacation time in Sep/Oct

I will be taking a long (and long-overdue) vacation from Sep 10 to Oct 20. I expect to have email access, but won't be doing much more than minimally keeping up with my inbox. This means I'll be pretty much AWOL for the September commitfest :-(. That's unfortunate, but the dates for this trip were

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

* Amit Kapila (amit.kapil...@gmail.com) wrote: > initdb will create the empty auto file. If we don't enable by default, > then if user uses > ALTER SYSTEM and do sighup/restart, changed config parameter values > will not come into affect > until he manually enables it by removing '#' from '#include

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Tue, Aug 20, 2013 at 8:27 AM, Stephen Frost wrote: > * Amit Kapila (amit.kapil...@gmail.com) wrote: >> If both are okay, then I would like to go with second option (include >> file mechanism). >> I think by default, we should allow auto file to be included and if >> user faces any problem or ot

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

On Monday, August 19, 2013, Alvaro Herrera wrote: > Tom Lane wrote: > > Alvaro Herrera > writes: > > > > Here's the second attachment. > > > > This looks good except that it can't tell "db_123.statfoo" isn't a match. > > The scan limit/buffer size needs to be greater than the longest string > > yo

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

* Amit Kapila (amit.kapil...@gmail.com) wrote: > If both are okay, then I would like to go with second option (include > file mechanism). > I think by default, we should allow auto file to be included and if > user faces any problem or otherwise, > then he can decide to disable it. If it's enabled

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Tue, Aug 20, 2013 at 5:49 AM, Stephen Frost wrote: > * Amit Kapila (amit.kapil...@gmail.com) wrote: >> I think disabling ALTER SYSTEM can be more easily supported if we >> choose one of below options: >> a. UI into contrib module, people who don't want doesn't include it >> b. Have an include f

Re: [HACKERS] [PATCH] pg_sleep(interval)

* Josh Berkus (j...@agliodbs.com) wrote: > Well, if that's the alternative, I'd vote for taking it. For me, > personally, I think the usefulness of it would outstrip the number of > functions I'd have to debug. Agreed. Having it take an interval makes a whole lot more sense than backing a decisi

Re: [HACKERS] 9.4 regression

* Andres Freund (and...@2ndquadrant.com) wrote: > I vote for adapting the patch to additionally zero out the file via > write(). In your tests that seemed to perform at least as good as the > old method... It also has the advantage that we can use it a littlebit > more as a testbed for possibly usi

Re: [HACKERS] Fix Windows socket error checking for MinGW

On Sun, Aug 18, 2013 at 01:02:57PM -0400, Andrew Dunstan wrote: > On 08/17/2013 01:16 AM, Noah Misch wrote: >> /* >> * For Microsoft Visual Studio 2010 and above we intentionally redefine >> * the regular Berkeley error constants and set them to the WSA constants. >> * Note that this will bre

Re: [HACKERS] System catalog vacuum issues

On Thu, Aug 15, 2013 at 7:03 PM, Vlad Arkhipov wrote: >> Do you have some processes that intensively create tables or columns >> and then delete them or create them in transaction and rollback the >> transaction? >> > There are many processes that create and drop temporary tables. That is the pro

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

* Amit Kapila (amit.kapil...@gmail.com) wrote: > I think disabling ALTER SYSTEM can be more easily supported if we > choose one of below options: > a. UI into contrib module, people who don't want doesn't include it > b. Have an include file mechanism, so that user can comment the > include in post

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Robert Haas escribió: > > On Fri, Aug 9, 2013 at 8:44 AM, Stephen Frost wrote: > > > A shared catalog which defined which *database* to run the trigger in, > > > with a way to fire off a new backend worker in that database and tell it > > > to r

Re: [HACKERS] Feature Request on Extensions

On Mon, Aug 19, 2013 at 11:44:36PM +0200, Dimitri Fontaine wrote: > Bruce Momjian writes: > > That's pretty vague. Exactly what does "keys to the kingdom" mean? If > > it means you can do anything to the database, you are right. If it > > means executing arbitrary code, including arbitrary kern

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

Alvaro Herrera writes: > Pushed with those fixes, thanks. I noticed we also needed to match > files global.stat and global.tmp. Also I added another conversion to > the sscanf pattern, to ignore files named "db_1234.tmp.foo" and such > (i.e. stuff after whitespace). After reading the sscanf ma

Re: [HACKERS] StrategyGetBuffer optimization, take 2

On Mon, Aug 19, 2013 at 5:17 PM, Jeff Janes wrote: > On Wed, Aug 7, 2013 at 7:40 AM, Merlin Moncure wrote: > >> I agree; at least then it's not unambiguously better. if you (in >> effect) swap all contention on allocation from a lwlock to a spinlock >> it's not clear if you're improving things; i

Re: [HACKERS] StrategyGetBuffer optimization, take 2

On Mon, Aug 19, 2013 at 5:02 PM, Jeff Janes wrote: > > My concern is how we can ever move this forward. If we can't recreate > it on a test system, and you probably won't be allowed to push > experimental patches to the production systemwhat's left? > > Also, if the kernel is introducing new

Re: [HACKERS] StrategyGetBuffer optimization, take 2

On Wed, Aug 7, 2013 at 7:40 AM, Merlin Moncure wrote: > I agree; at least then it's not unambiguously better. if you (in > effect) swap all contention on allocation from a lwlock to a spinlock > it's not clear if you're improving things; it would have to be proven > and I'm trying to keep things

Re: [HACKERS] StrategyGetBuffer optimization, take 2

On Mon, Aug 5, 2013 at 8:49 AM, Merlin Moncure wrote: > > *) What I think is happening: > I think we are again getting burned by getting de-scheduled while > holding the free list lock. I've been chasing this problem for a long > time now (for example, see: > http://postgresql.1045698.n5.nabble.co

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

Tom Lane wrote: > Alvaro Herrera writes: > > Here's the second attachment. > > This looks good except that it can't tell "db_123.statfoo" isn't a match. > The scan limit/buffer size needs to be greater than the longest string > you care about, not only equal to. I think strcmp not strncmp would

Re: [HACKERS] Feature Request on Extensions

Bruce Momjian writes: > That's pretty vague. Exactly what does "keys to the kingdom" mean? If > it means you can do anything to the database, you are right. If it > means executing arbitrary code, including arbitrary kernel calls, I > would like to hear how that is done. You've now heard ab

[HACKERS] ereport documentation patch

Is it reasonable to note in the documentation that ereport does not return if the error severity is greater than or equal to ERROR? -- -- Christophe Pettus x...@thebuild.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://w

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

Andres Freund writes: > On 2013-08-19 15:51:16 -0400, Tom Lane wrote: >> Yeah, the stats temp directory will act pretty much the same way: there >> will be an interval where backends might not get the most up-to-date data, >> but it's not clear that it's worth the trouble to get it to be more near

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

Boszormenyi Zoltan wrote: >> This parser hackery is of course somewhat ugly. But given the objective >> of implementing the spec's unnest syntax, it seems to be the least ugly >> of the possible approaches. (The hard part of doing it any other way >> would be generating the description of the resul

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

On 2013-08-19 15:51:16 -0400, Tom Lane wrote: > Josh Berkus writes: > > Tom, > >> I note BTW that similar complaints could be lodged against the > >> log_directory setting. We've not worried about that one too much. > > > Actually, it does happen that when you change log_directory on a reload, >

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

2013-08-19 21:21 keltezéssel, Karol Trzcionka írta: W dniu 19.08.2013 19:56, Boszormenyi Zoltan pisze: * Does it apply cleanly to the current git master? No. There's a reject in src/backend/optimizer/plan/initsplan.c Thank you, merged in attached version. * Does it include reasonable tests?

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

Josh Berkus writes: > Tom, >> I note BTW that similar complaints could be lodged against the >> log_directory setting. We've not worried about that one too much. > Actually, it does happen that when you change log_directory on a reload, > stuff takes an uneven amount of time to "cut over"; that

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

On 2013-08-19 12:47:05 -0700, Josh Berkus wrote: > Tom, > > > I note BTW that similar complaints could be lodged against the > > log_directory setting. We've not worried about that one too much. > > Actually, it does happen that when you change log_directory on a reload, > stuff takes an uneven

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

Tom, > I note BTW that similar complaints could be lodged against the > log_directory setting. We've not worried about that one too much. Actually, it does happen that when you change log_directory on a reload, stuff takes an uneven amount of time to "cut over"; that is, there's a few seconds wh

Re: [HACKERS] 9.4 regression

On 2013-08-19 14:40:07 -0500, Jon Nelson wrote: > On Fri, Aug 16, 2013 at 3:57 PM, Bruce Momjian wrote: > > On Thu, Aug 15, 2013 at 12:08:57PM -0500, Jon Nelson wrote: > >> > Where are we on this issue? > >> > >> I've been able to replicate it pretty easily with PostgreSQL and > >> continue to loo

Re: [HACKERS] 9.4 regression

On Fri, Aug 16, 2013 at 3:57 PM, Bruce Momjian wrote: > On Thu, Aug 15, 2013 at 12:08:57PM -0500, Jon Nelson wrote: >> > Where are we on this issue? >> >> I've been able to replicate it pretty easily with PostgreSQL and >> continue to look into it. I've contacted Theodore Ts'o and have gotten >> s

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

On 2013-08-19 15:25:38 -0400, Tom Lane wrote: > Andres Freund writes: > > Hm. Is a check like that actually sufficient? The idea of setting > > stats_temp_directory to /dev/shm/postgres or similar in all of several > > clusters on one machine doesn't seem to be that far fetched. > > Hm. We could

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

Andres Freund writes: > Hm. Is a check like that actually sufficient? The idea of setting > stats_temp_directory to /dev/shm/postgres or similar in all of several > clusters on one machine doesn't seem to be that far fetched. Hm. We could fairly easily have the lockfile management code also writ

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

W dniu 19.08.2013 19:56, Boszormenyi Zoltan pisze: > * Does it apply cleanly to the current git master? > > No. There's a reject in src/backend/optimizer/plan/initsplan.c Thank you, merged in attached version. > > * Does it include reasonable tests? > > Yes but the test fails after trying to fix th

Re: [HACKERS] Backup throttling

2013-08-19 21:11 keltezéssel, Andres Freund írta: On 2013-08-19 20:15:51 +0200, Boszormenyi Zoltan wrote: 2013-08-19 19:20 keltezéssel, Andres Freund írta: Hi, On 2013-07-24 09:20:52 +0200, Antonin Houska wrote: Hello, the purpose of this patch is to limit impact of pg_backup on running serve

Re: [HACKERS] [GENERAL] currval and DISCARD ALL

2013-08-19 21:02 keltezéssel, Boszormenyi Zoltan írta: Hi, 2013-04-19 16:58 keltezéssel, Fabrízio de Royes Mello írta: On Fri, Apr 19, 2013 at 11:12 AM, Robert Haas > wrote: On Fri, Apr 19, 2013 at 10:05 AM, Fabrízio de Royes Mello mailto:fabriziome...@g

Re: [HACKERS] Backup throttling

On 2013-08-19 20:15:51 +0200, Boszormenyi Zoltan wrote: > 2013-08-19 19:20 keltezéssel, Andres Freund írta: > >Hi, > > > >On 2013-07-24 09:20:52 +0200, Antonin Houska wrote: > >>Hello, > >>the purpose of this patch is to limit impact of pg_backup on running server. > >>Feedback is appreciated. > >B

Re: [HACKERS] [GENERAL] currval and DISCARD ALL

Hi, 2013-04-19 16:58 keltezéssel, Fabrízio de Royes Mello írta: On Fri, Apr 19, 2013 at 11:12 AM, Robert Haas > wrote: On Fri, Apr 19, 2013 at 10:05 AM, Fabrízio de Royes Mello mailto:fabriziome...@gmail.com>> wrote: > The attached wip patch do that a

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

On 2013-08-19 13:50:38 -0400, Alvaro Herrera wrote: > Tom Lane wrote: > > > I think we should change 9.3 to be restrictive about ownership/permissions > > on the stats_temp_directory (ie, require owner = postgres user, > > permissions = 0700, same as for the $PGDATA directory). > > Not an easy th

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

Andres Freund writes: > On 2013-08-19 14:28:28 -0400, Tom Lane wrote: >> One possibility is to do the initial check somewhere shortly after >> ChangeToDataDir(), and have the GUC check hook only attempt to make a >> check in SIGHUP context. Unfortunately we aren't passing the context to >> check

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

On 2013-08-19 14:28:28 -0400, Tom Lane wrote: > One possibility is to do the initial check somewhere shortly after > ChangeToDataDir(), and have the GUC check hook only attempt to make a > check in SIGHUP context. Unfortunately we aren't passing the context to > check hooks, only GucSource which i

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

Alvaro Herrera writes: > The implementation I chose for the actual check was to separate the > permission checks from checkDataDir() into src/port/pgcheckdir.c that > returns different error codes for each case; see first attachment. > This part seems pretty reasonable, except that the code should

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

2013-08-19 20:03 keltezéssel, Josh Berkus írta: On 08/19/2013 09:23 AM, Boszormenyi Zoltan wrote: Indeed, it's a big nail in the coffin for SRFs-in-targetlist. Having WITH ORDINALITY and this feature, I would vote for removing SRF-in-targetlist and call the release PostgreSQL 10.0. That's not r

Re: [HACKERS] Backup throttling

2013-08-19 19:20 keltezéssel, Andres Freund írta: Hi, On 2013-07-24 09:20:52 +0200, Antonin Houska wrote: Hello, the purpose of this patch is to limit impact of pg_backup on running server. Feedback is appreciated. Based on a quick look it seems like you're throttling on the receiving side. Is

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

Alvaro Herrera writes: > Alvaro Herrera wrote: >>> In addition to that, it might be a good idea to do what the comment in the >>> code suggests, namely do more than zero checking on each file name to try >>> to make sure it looks like a stats temp file name that we'd generate >>> before we delete

Re: [HACKERS] Should we remove "not fast" promotion at all?

On 19.08.2013 20:27, Tom Lane wrote: Bruce Momjian writes: On Mon, Aug 19, 2013 at 11:20:42AM +0300, Heikki Linnakangas wrote: I think "promote" file should trigger the fast promotion, and the filename to trigger the slow mode should be called "fallback_promote" or "safe_promote" or something

Re: [HACKERS] pgstat_reset_remove_files ignores its argument

Jeff Janes escribió: > No, you are right, I too realized I missed a couple more spots. Your > patch looks just like the one I eventually arrived at, before I got > distracted thinking about how to implement the regex > /^(global|db_\d+)\.stat$/ in C and forgot to post a correction. > > Is the re

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

Alvaro Herrera wrote: > > In addition to that, it might be a good idea to do what the comment in the > > code suggests, namely do more than zero checking on each file name to try > > to make sure it looks like a stats temp file name that we'd generate > > before we delete it. The ownership/permis

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

On 08/19/2013 09:23 AM, Boszormenyi Zoltan wrote: > > Indeed, it's a big nail in the coffin for SRFs-in-targetlist. Having > WITH ORDINALITY and this feature, I would vote for removing > SRF-in-targetlist and call the release PostgreSQL 10.0. That's not realistic. We'd have to deprecate that sy

Re: [HACKERS] pgstat_reset_remove_files ignores its argument

On Fri, Aug 16, 2013 at 12:38 PM, Robert Haas wrote: > On Wed, Aug 14, 2013 at 12:13 AM, Jeff Janes wrote: >> in 9.3 and 9.4, pgstat_reset_remove_files uses the global variable >> pgstat_stat_directory rather than the argument it is passed, "directory". >> On crash recovery, this means the tmp di

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

Hi, mini-review follows. 2013-07-22 21:52 keltezéssel, Karol Trzcionka írta: I've noticed problem with "UPDATE ... FROM" statement. Fix in new version. Regards, Karol * Does it apply cleanly to the current git master? No. There's a reject in src/backend/optimizer/plan/initsplan.c * Does it

Re: [HACKERS] danger of stats_temp_directory = /dev/shm

Tom Lane wrote: > I think we should change 9.3 to be restrictive about ownership/permissions > on the stats_temp_directory (ie, require owner = postgres user, > permissions = 0700, same as for the $PGDATA directory). Not an easy thing to do, this. It should be done as a GUC check hook, ISTM, but

Re: [HACKERS] Should we remove "not fast" promotion at all?

On Mon, Aug 19, 2013 at 01:27:29PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Mon, Aug 19, 2013 at 11:20:42AM +0300, Heikki Linnakangas wrote: > >> I think "promote" file should trigger the fast promotion, and the > >> filename to trigger the slow mode should be called > >> "fallback_pr

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

Hello Harder maybe but it may still be cleaner in the long run. > > Overall, it's my intention here to remove as many as feasible of the old >> reasons why one might use an SRF in the select list. >> > > Indeed, it's a big nail in the coffin for SRFs-in-targetlist. Having > WITH ORDINALITY and th

Re: [HACKERS] GetTransactionSnapshot() in enum.c

Andres Freund writes: > ISTM that we shouldn't use GetTransactionSnapshot() in enum.c but > GetLatestSnapshot() in <= 9.3 and NULL/GetCatalogSnapshot() > 9.3. > typecache.c's usage was converted to GetLatestSnapshot() but enum.c's > was not. That was intentional, see the comments for commit 9ad4

Re: [HACKERS] Should we remove "not fast" promotion at all?

Bruce Momjian writes: > On Mon, Aug 19, 2013 at 11:20:42AM +0300, Heikki Linnakangas wrote: >> I think "promote" file should trigger the fast promotion, and the >> filename to trigger the slow mode should be called >> "fallback_promote" or "safe_promote" or something like that. There >> wasn't any

Re: [HACKERS] Backup throttling

Hi, On 2013-07-24 09:20:52 +0200, Antonin Houska wrote: > Hello, > the purpose of this patch is to limit impact of pg_backup on running server. > Feedback is appreciated. Based on a quick look it seems like you're throttling on the receiving side. Is that a good idea? Especially over longer laten

Re: [HACKERS] Backup throttling

2013-07-31 22:50 keltezéssel, Antonin Houska írta: On 07/31/2013 07:13 AM, Gibheer wrote: Hi, That is a really nice feature. I don't pretend it's my idea, I just coded it. My boss proposed the feature as such :-) I took a first look at your patch and some empty lines you added (e.g. line 60

Re: [HACKERS] [BUGS] 9.3beta2: Failure to pg_upgrade

Jesse Denardo escribió: > Alvaro, > > I applied the patch and tried upgrading again, and everything seemed to > work as expected. We are now up and running the beta! Pushed, thanks. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Se

Re: [HACKERS] Should we remove "not fast" promotion at all?

On Mon, Aug 19, 2013 at 11:20:42AM +0300, Heikki Linnakangas wrote: > And it's even worse if you use 9.3 pg_ctl against a 9.2 server: it > will create a filed called "fast_promote" and return success, but it > won't actually do anything. > > I think "promote" file should trigger the fast promotion

Re: [HACKERS] 9.3 release notes suggestions

On Mon, Aug 19, 2013 at 01:38:13PM +0900, Etsuro Fujita wrote: > > From: 'Bruce Momjian' [mailto:br...@momjian.us] > > > On Tue, Aug 13, 2013 at 05:59:05PM +0900, Etsuro Fujita wrote: > > > > Thanks for the many suggestions on improving the 9.3 release notes. > > > > There were many ideas I would

Re: [HACKERS] UNNEST with multiple args, and TABLE with multiple funcs

Hi, 2013-08-13 15:54 keltezéssel, Andrew Gierth írta: Summary: This patch implements a method for expanding multiple SRFs in parallel that does not have the surprising LCM behaviour of SRFs-in-select-list. (Functions returning fewer rows are padded with nulls instead.) It then uses this method

Re: [HACKERS] Feature Request on Extensions

On Mon, Aug 19, 2013 at 11:34:47AM +0200, Dimitri Fontaine wrote: > Dave Page writes: > > If you find a hole in the boat, the preferred option is to fix it, not > > to say "meh, well another won't hurt". > > My understanding is that there's no way to fix it. If you're superuser > you have the key

Re: [HACKERS] LATERAL quals revisited

Some time ago, I wrote: > I've been studying the bug reported at > http://www.postgresql.org/message-id/20130617235236.GA1636@jeremyevans.local > ... > After some contemplation, I think that the most practical way to fix > this is for deconstruct_recurse and distribute_qual_to_rels to > effectively

Re: [HACKERS] Fix Windows socket error checking for MinGW

On 08/19/2013 10:35 AM, Robert Haas wrote: TBH, I think Andrew is going above and beyond the call of duty by developing and testing a patch for the problem you reported. I've actually known about this problem for a while, but mistakenly thought it only occurred for cross-compilation:

Re: [HACKERS] Should we remove "not fast" promotion at all?

Robert Haas wrote: > Heikki Linnakangas wrote: >> I think "promote" file should trigger the fast promotion, and >> the filename to trigger the slow mode should be called >> "fallback_promote" or "safe_promote" or something like that. >> There wasn't any good reason to change the filename primari

Re: [HACKERS] Fix Windows socket error checking for MinGW

Michael Cronenworth wrote: > On 08/17/2013 12:16 AM, Noah Misch wrote: > > 1. Redefine those constants for more (all?) compilers. > > 2. Remove that block and put #ifdef around all usage of such constants in > > frontend code, as you have done. > > 3. Remove that block and make src/backend/port/win

Re: [HACKERS] Fix Windows socket error checking for MinGW

On Mon, Aug 19, 2013 at 10:18 AM, Michael Cronenworth wrote: > On 08/19/2013 09:11 AM, Andrew Dunstan wrote: >> I already gave you a sufficient identifier for the commit. In case you're not >> aware, git is quite happy dealing with small commit identifiers. If you do >> "git >> log -1 a099482" yo

Re: [HACKERS] Should we remove "not fast" promotion at all?

On Mon, Aug 19, 2013 at 4:20 AM, Heikki Linnakangas wrote: > Well, I don't see much harm in keeping the old behavior as an undocumented > escape hatch, as it is now. The way I'd phrase the current situation is > this: 9.3 now always does "fast promotion". However, for debugging and > testing purpo

Re: [HACKERS] Fix Windows socket error checking for MinGW

On 08/19/2013 09:11 AM, Andrew Dunstan wrote: > I already gave you a sufficient identifier for the commit. In case you're not > aware, git is quite happy dealing with small commit identifiers. If you do > "git > log -1 a099482" you should get the details you require. It should cross your mind tha

Re: [HACKERS] Fix Windows socket error checking for MinGW

On 08/19/2013 09:50 AM, Michael Cronenworth wrote: On 08/18/2013 12:02 PM, Andrew Dunstan wrote: There is a much simpler fix, which is to do these assignments unconditionally in src/port/win32.h. The following small change fixes the problem for me: No. Please do not do this. If you object

Re: [HACKERS] Automatic Index Creation for Column Types

Agree, these are significant concerns. Just to make sure the scope of the proposal is clear, I'm referring to col types created via CREATE TYPE, i.e. locally-defined col types of much tighter granularity than standard col types like INTEGER. Locally, one could adopt a naming convention for the

Re: [HACKERS] Fix Windows socket error checking for MinGW

On 08/17/2013 02:33 PM, Noah Misch wrote: > One of the reports Michael cited was apparently "native": > http://www.postgresql.org/message-id/e1uclpd-l4...@wrigleys.postgresql.org > > Perhaps only some versions of w32api trigger the problem. I agree we ought to > understand the necessary condi

Re: [HACKERS] Fix Windows socket error checking for MinGW

On 08/18/2013 12:02 PM, Andrew Dunstan wrote: > There is a much simpler fix, which is to do these assignments unconditionally > in > src/port/win32.h. The following small change fixes the problem for me: > No. Please do not do this. > > Note that the original patch appears to be not only misgu

Re: [HACKERS] Fix Windows socket error checking for MinGW

On 08/17/2013 12:16 AM, Noah Misch wrote: > 1. Redefine those constants for more (all?) compilers. > 2. Remove that block and put #ifdef around all usage of such constants in > frontend code, as you have done. > 3. Remove that block and make src/backend/port/win32/socket.c frontend-usable, > so fro

Re: [HACKERS] Automatic Index Creation for Column Types

On 08/19/2013 09:10 AM, Charles Sheridan wrote: Hi, I don't see indication that the capability described below exists in Postgres (or any RDBMS), so this is likely a feature request -- For column types that are frequently defined in tables, and which are typically indexed, it would be helpful

Re: [HACKERS] Automatic Index Creation for Column Types

2013/8/19 Charles Sheridan > In my use, mainly arrays and hstore cols, including arrays of hstores. > These are column types that I suspect benefit from indexes more than most > column types. > depends on usage when you use a arrays for time series, then you don't use a index usually and in h

Re: [HACKERS] StrategyGetBuffer optimization, take 2

On Sat, Aug 17, 2013 at 10:55 AM, Robert Haas wrote: > On Mon, Aug 5, 2013 at 11:49 AM, Merlin Moncure wrote: >> *) What I think is happening: >> I think we are again getting burned by getting de-scheduled while >> holding the free list lock. I've been chasing this problem for a long >> time now

Re: [HACKERS] Automatic Index Creation for Column Types

In my use, mainly arrays and hstore cols, including arrays of hstores. These are column types that I suspect benefit from indexes more than most column types. Charles On 13-08-19 8:14 AM, Pavel Stehule wrote: Hello 2013/8/19 Charles Sheridan > Hi, I d

Re: [HACKERS] Automatic Index Creation for Column Types

Hello 2013/8/19 Charles Sheridan > Hi, > > I don't see indication that the capability described below exists in > Postgres (or any RDBMS), so this is likely a feature request -- > > For column types that are frequently defined in tables, and which are > typically indexed, it would be helpful to

[HACKERS] Automatic Index Creation for Column Types

Hi, I don't see indication that the capability described below exists in Postgres (or any RDBMS), so this is likely a feature request -- For column types that are frequently defined in tables, and which are typically indexed, it would be helpful to be able to specify in the type definition of th

[HACKERS] GetTransactionSnapshot() in enum.c

Hi, ISTM that we shouldn't use GetTransactionSnapshot() in enum.c but GetLatestSnapshot() in <= 9.3 and NULL/GetCatalogSnapshot() > 9.3. typecache.c's usage was converted to GetLatestSnapshot() but enum.c's was not. I don't seem to have full mental capacity right now, but I think the current usa

Re: [HACKERS] LDAP: bugfix and deprecated OpenLDAP API

Magnus Hagander wrote: >> The patch should still be good, but if we keep the deprecated >> OpenLDAP API, it might be more consistent to use ldap_simple_bind_s >> instead of ldap_sasl_bind_s. >> >> If you agree, I'll change that. > > Sorry, you got this one in just as my vacation started. > > Yes,

  1   2   >