Re: [HACKERS] Portability issues in TAP tests

Noah Misch writes: > On Thu, Jul 17, 2014 at 03:31:19PM -0400, Tom Lane wrote: >> 4. IPC::Run isn't installed by default on RHEL, and probably not on other >> distros either. If there's a reasonably painless way to remove this >> dependency, it'd improve the portability of the tests. This is low

Re: [HACKERS] New functions in sslinfo module

Hello, Andreas and others!I make a new version of patch. I corrected your notes for my previous version of patch. Could you test it? Thank you.03.07.2014, 01:54, "Andreas Karlsson" : On 07/02/2014 02:17 PM, Воронин Дмитрий wrote:  I apologize, that I am writing this message today

[HACKERS] option -T in pg_basebackup doesn't work on windows

During my recent work on pg_basebackup, I noticed that -T option doesn't seem to work on Windows. The reason for the same is that while updating symlinks it doesn't consider that on Windows, junction points can be directories due to which it is not able to update the symlink location. Fix is to mak

Re: [HACKERS] Portability issues in TAP tests

On Thu, Jul 17, 2014 at 03:31:19PM -0400, Tom Lane wrote: > My Salesforce colleagues have been complaining that the TAP tests added > in 9.4 don't work terribly well for them. I've been poking at this, > and I believe this is a reasonably complete list of the problems: > 3. Many of the tests depe

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On 16 July 2014 12:13, Magnus Hagander Wrote, >Yeah, those are exactly my points. I think it would be significantly simpler >to do it that way, rather than forking and threading. And also easier to make >portable... >(and as a optimization on Alvaros suggestion, you can of course reuse the >

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

On Thu, Jul 17, 2014 at 4:51 PM, Magnus Hagander wrote: > > Did anyone actually test this patch? :) > > I admit I did not build it on Windows specifically because I assumed > that was done as part of the development and review. And the changes > to pg_event.c can never have built, since the file d

Re: [HACKERS] [TODO] Process pg_hba.conf keywords as case-insensitive

On 07/17/2014 01:41 AM, Tom Lane wrote: > Christoph Berg writes: >> Re: Viswanatham kirankumar 2014-07-16 >> >>> Attached patch is implementing following TODO item >>> Process pg_hba.conf keywords as case-insensitive > >> Hmm. I see a case for accepting "ALL" (as in hosts.allow(5)), so +1 on >>

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On 2014-07-17 16:53, Greg Stark wrote: On Thu, Jul 17, 2014 at 4:45 AM, Thor Lancelot Simon wrote: Except, of course, for IEEE floating point, because the VAX's floating point unit simply does not provide that Actually I think that's relevant. We usually get focused on the concurrency because

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Thu, Jul 17, 2014 at 07:47:28AM -0400, Robert Haas wrote: > On Wed, Jul 16, 2014 at 11:45 PM, Thor Lancelot Simon wrote: > > Well, I have to ask this question: why should there be any "vax-specific > > code"? What facilities beyond what POSIX with the threading extensions > > offers on a moder

Re: [HACKERS] Making joins involving ctid work for the benefit of UPSERT

On Thu, Jul 17, 2014 at 6:18 PM, Peter Geoghegan wrote: > This appears to be a Simple Matter of Programming (at least > for someone that happens to already have a good understanding of the > optimizer), and is anticipated by this comment within tidpath.c: > > * There is currently no special suppo

Re: [HACKERS] [v9.5] Custom Plan API

> I personally don't see how this patch is 'ready for committer'. I realize > that that state is sometimes used to denote that review needs to be > "escalated", but it still seemspremature. > > Unless I miss something there hasn't been any API level review of this? > Also, aren't there several ope

Re: [HACKERS] [v9.5] Custom Plan API

> Alvaro Herrera writes: > > I haven't followed this at all, but I just skimmed over it and noticed > > the CustomPlanMarkPos thingy; apologies if this has been discussed > > before. It seems a bit odd to me; why isn't it sufficient to have a > > boolean flag in regular CustomPlan to indicate tha

[HACKERS] Making joins involving ctid work for the benefit of UPSERT

I'm working on UPSERT again. I think that in order to make useful progress, I'll have to find a better way of overcoming the visibility issues (i.e. the problem of what to do about a still-in-progress-to-our-snapshot row being locked at READ COMMITTED isolation level [1][2]). I've made some tentat

Re: [HACKERS] [GSoC2014] Patch ALTER TABLE ... SET LOGGED

On 2014-07-16 20:45:15 -0300, Fabrízio de Royes Mello wrote: > On Wed, Jul 16, 2014 at 7:26 PM, Andres Freund > wrote: > > > > On 2014-07-16 20:53:06 +0200, Andres Freund wrote: > > > On 2014-07-16 20:25:42 +0200, Andres Freund wrote: > > > > Hi, > > > > > > > > I quickly looked at this patch and

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 06/30/2014 09:46 AM, Alvaro Herrera wrote: > If we only had bricks and mortar, I think we would have a tool to > display and tweak pg_control separately from emptying pg_xlog, rather > than this odd separation between pg_controldata and pg_resetxlog, each > of which do a mixture of those things.

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Wed, Jun 25, 2014 at 10:50:47AM -0700, Greg Stark wrote: > On Wed, Jun 25, 2014 at 10:17 AM, Robert Haas wrote: > > Well, the fact that initdb didn't produce a working configuration and > > that make installcheck failed to work properly are bad. But, yeah, > > it's not totally broken. > > Yea

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 2014-07-18 00:41:05 +0200, Andres Freund wrote: > On 2014-06-27 00:51:02 +0200, Petr Jelinek wrote: > > - while ((c = getopt(argc, argv, "fl:m:no:O:x:e:")) != -1) > > + while ((c = getopt(argc, argv, "fl:m:no:O:x:e:s::")) != -1) > > Why two :? Obviously strike that, wanted to delete the pa

Re: [HACKERS] Set new system identifier using pg_resetxlog

On 2014-06-27 00:51:02 +0200, Petr Jelinek wrote: > - while ((c = getopt(argc, argv, "fl:m:no:O:x:e:")) != -1) > + while ((c = getopt(argc, argv, "fl:m:no:O:x:e:s::")) != -1) Why two :? > { > switch (c) > { > @@ -227,6 +229,33 @@ main(int argc, char *argv

Re: [HACKERS] [TODO] Process pg_hba.conf keywords as case-insensitive

On 18/07/14 04:08, Tom Lane wrote: Christoph Berg writes: One place that's been bugging me where case-insensitivity would really make sense is this: # set work_mem = '1mb'; ERROR: 22023: invalid value for parameter "work_mem": "1mb" HINT: Valid units for this parameter are "kB", "MB", and "GB

Re: [HACKERS] gaussian distribution pgbench

However, ISTM that it is not the purpose of pgbench documentation to be a primer about what is an exponential or gaussian distribution, so the idea would yet be to have a relatively compact explanation, and that the interested but clueless reader would document h..self from wikipedia or a text b

Re: [HACKERS] BUFFER_LOCK_EXCLUSIVE is used in ginbuildempty().

Peter Geoghegan writes: > On Thu, Jul 17, 2014 at 7:47 AM, Alvaro Herrera > wrote: >> I don't understand the point of having these GIN_EXCLUSIVE / GIN_SHARED >> symbols. It's not like we could do anything different than >> BUFFER_LOCK_EXCLUSIVE etc instead. It there was a GinLockBuffer() it >>

Re: [HACKERS] [v9.5] Custom Plan API

Alvaro Herrera writes: > I haven't followed this at all, but I just skimmed over it and noticed > the CustomPlanMarkPos thingy; apologies if this has been discussed > before. It seems a bit odd to me; why isn't it sufficient to have a > boolean flag in regular CustomPlan to indicate that it suppo

[HACKERS] Portability issues in TAP tests

My Salesforce colleagues have been complaining that the TAP tests added in 9.4 don't work terribly well for them. I've been poking at this, and I believe this is a reasonably complete list of the problems: 1. "make [install]check-world" tries to run the TAP tests even when "prove" was not found b

Re: [HACKERS] BUFFER_LOCK_EXCLUSIVE is used in ginbuildempty().

On Thu, Jul 17, 2014 at 7:47 AM, Alvaro Herrera wrote: > I don't understand the point of having these GIN_EXCLUSIVE / GIN_SHARED > symbols. It's not like we could do anything different than > BUFFER_LOCK_EXCLUSIVE etc instead. It there was a GinLockBuffer() it > might make more sense to have spe

Re: [HACKERS] BUFFER_LOCK_EXCLUSIVE is used in ginbuildempty().

Kyotaro HORIGUCHI wrote: > Hello, > > As far as I see gin seems using GIN_EXCLUSIVE instead of > BUFFER_LOCK_EXCLUSIVE for LockBuffer, but the raw > BUFFER_LOCK_EXCLUSIVE appears in ginbuildempty(). > > Does it has a meaning to fix them to GIN_EXCLUSIVE? I don't understand the point of having th

Re: [HACKERS] RLS Design

Tom Lane wrote: > 20MB messages to the list aren't that friendly. Please don't do that > again, unless asked to. FWIW the message was not distributed to the list. I got a note from Adam and dropped it from the moderation queue. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ Post

Re: [HACKERS] [v9.5] Custom Plan API

I haven't followed this at all, but I just skimmed over it and noticed the CustomPlanMarkPos thingy; apologies if this has been discussed before. It seems a bit odd to me; why isn't it sufficient to have a boolean flag in regular CustomPlan to indicate that it supports mark/restore? -- Álvaro He

Re: [HACKERS] Doing better at HINTing an appropriate column within errorMissingColumn()

I am not opposed to moving the contrib code into core in the manner that you oppose. I don't feel strongly either way. I noticed in passing that your revision says this *within* levenshtein.c: + * Guaranteed to work with Name datatype's cstrings. + * For full details see levenshtein.c. On Thu,

Re: [HACKERS] [v9.5] Custom Plan API

On 2014-07-16 10:43:08 +0900, Shigeru Hanada wrote: > Kaigai-san, > > 2014-07-15 21:37 GMT+09:00 Kouhei Kaigai : > > Sorry, expected result of sanity-check test was not updated on > > renaming to pg_custom_plan_provider. > > The attached patch fixed up this point. > > I confirmed that all regress

Re: [HACKERS] Re: 9.3: more problems with "Could not open file "pg_multixact/members/xxxx"

On Wed, Jul 16, 2014 at 12:46 AM, Alvaro Herrera wrote: > (Maybe I'm just too tired and I'm failing to fully understand the torn > page protection. I thought I understood how it worked, but now I'm not > sure -- I mean I don't see how it can possibly have any value at all. > Surely if the disk wr

Re: [HACKERS] gaussian distribution pgbench

On Wed, Jul 16, 2014 at 12:57 AM, Fabien COELHO wrote: >> Well, I think the feedback has been pretty clear, honestly. Here's >> what I'm unhappy about: I can't understand what these options are >> actually doing. > > We can try to improve the documentation, once more! > > However, ISTM that it is

Re: [HACKERS] [TODO] Process pg_hba.conf keywords as case-insensitive

Christoph Berg writes: > One place that's been bugging me where case-insensitivity would really > make sense is this: > # set work_mem = '1mb'; > ERROR: 22023: invalid value for parameter "work_mem": "1mb" > HINT: Valid units for this parameter are "kB", "MB", and "GB". Yeah ... there was some

Re: [HACKERS] [TODO] Process pg_hba.conf keywords as case-insensitive

Re: Tom Lane 2014-07-16 <30956.1405532...@sss.pgh.pa.us> > Christoph Berg writes: > > Re: Viswanatham kirankumar 2014-07-16 > > > >> Attached patch is implementing following TODO item > >> Process pg_hba.conf keywords as case-insensitive > > > Hmm. I see a case for accepting "ALL" (as in hosts.

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Thu, Jul 17, 2014 at 4:04 PM, Johnny Billquist wrote: > Also, VAX did not use CAS as the general paradigm for atomic writes and so > on, but have other explicit instructions that are guaranteed to be atomic. > NetBSD/vax don't use the VAX specific instructions, but emulates CAS in the > kernel

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Thu, Jul 17, 2014 at 4:45 AM, Thor Lancelot Simon wrote: > Except, of course, for IEEE floating point, because the VAX's floating point > unit simply does not provide that Actually I think that's relevant. We usually get focused on the concurrency because that's an area where architectures var

Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD

On Wed, Jul 16, 2014 at 11:45 PM, Thor Lancelot Simon wrote: > Well, I have to ask this question: why should there be any "vax-specific > code"? What facilities beyond what POSIX with the threading extensions > offers on a modern system do you really need? Why? We have a spinlock implementation

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

On Thu, Jul 17, 2014 at 12:45 PM, Magnus Hagander wrote: > On Wed, Jul 16, 2014 at 2:01 PM, MauMau wrote: >> From: "Amit Kapila" >> >> So as a conclusion, the left over items to be handled for patch are: >>> >>> 1. Remove the new usage related to use of same event source name >>> for registratio

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

On Wed, Jul 16, 2014 at 2:01 PM, MauMau wrote: > From: "Amit Kapila" > > So as a conclusion, the left over items to be handled for patch are: >> >> 1. Remove the new usage related to use of same event source name >> for registration from pgevent. >> 2. Document the information to prevent loss of