Re: [HACKERS] More flexible LDAP auth search filters?

On 08/09/17 16:33, Peter Eisentraut wrote: > A couple of comments on this patch. I have attached a "fixup" patch on > top of your v4 that should address them. > > - I think the bracketing of the LDAP URL synopsis is wrong. > > - I have dropped the sentence that LDAP URL extensions are not > sup

Re: [HACKERS] More flexible LDAP auth search filters?

On 01/08/17 23:17, Thomas Munro wrote: > On Wed, Aug 2, 2017 at 5:36 AM, Peter Eisentraut > wrote: >> On 7/16/17 19:09, Thomas Munro wrote: >>> On Mon, Jul 17, 2017 at 10:26 AM, Thomas Munro >>> wrote: ldap-search-filters-v2.patch >>> >>> Gah, it would help if I could spell "occurrences" co

Re: [HACKERS] More flexible LDAP auth search filters?

On 17/07/17 18:08, Magnus Hagander wrote: > On Mon, Jul 17, 2017 at 6:47 PM, Mark Cave-Ayland > mailto:mark.cave-ayl...@ilande.co.uk>> > wrote: > Great to hear from you! It has definitely been a while... > > Indeed. You should spend more time on these lists :P

Re: [HACKERS] More flexible LDAP auth search filters?

On 17/07/17 13:09, Magnus Hagander wrote: Hi Magnus, Great to hear from you! It has definitely been a while... > Generally you find that you will be given the option to set the > attribute for the default search filter of the form > "(attribute=username)" which defaults to uid for UN

Re: [HACKERS] More flexible LDAP auth search filters?

On 17/07/17 00:14, Stephen Frost wrote: >> If it helps, we normally recommend that clients use ldaps for both AD >> and UNIX environments, although this can be trickier from an >> administrative perspective in AD environments because it can require >> changes to the Windows firewall and certificat

Re: [HACKERS] More flexible LDAP auth search filters?

On 16/07/17 23:26, Thomas Munro wrote: > Thank you very much for this feedback and example, which I used in the > documentation in the patch. I see similar examples in the > documentation for other things on the web. > > I'll leave it up to Magnus and Stephen to duke it out over whether we > wan

Re: [HACKERS] More flexible LDAP auth search filters?

On 16/07/17 00:08, Thomas Munro wrote: > On Fri, Jul 14, 2017 at 11:04 PM, Magnus Hagander wrote: >> On Thu, Jul 13, 2017 at 9:31 AM, Thomas Munro >> wrote: >>> A post on planet.postgresql.org today reminded me that a colleague had >>> asked me to post this POC patch here for discussion. It all

Re: [HACKERS] Commitfest problems

On 16/12/14 15:42, Claudio Freire wrote: >> Also >> with a submission from git, you can near 100% guarantee that the author >> has actually built and run the code before submission. > > I don't see how. Forks don't have travis ci unless you add it, or am I > mistaken? Well as I mentioned in my

Re: [HACKERS] Commitfest problems

On 16/12/14 13:44, David Fetter wrote: > On Tue, Dec 16, 2014 at 11:09:34AM +0000, Mark Cave-Ayland wrote: >> On 16/12/14 07:33, David Rowley wrote: >> >>> On 16 December 2014 at 18:18, Josh Berkus >> <mailto:j...@agliodbs.com>> wrote: >>> >>

Re: [HACKERS] Commitfest problems

On 16/12/14 13:37, Claudio Freire wrote: >> For the second project, I can skim through my inbox daily picking up >> specific areas I work on/are interested in, hit reply to add a couple of >> lines of inline comments to the patch and send feedback to the >> author/list in just a few minutes. > >

Re: [HACKERS] Commitfest problems

On 16/12/14 10:49, Marko Tiikkaja wrote: > On 12/16/14 11:26 AM, Mark Cave-Ayland wrote: >> On 15/12/14 19:27, Robert Haas wrote: >>> So, there are certainly some large patches that do that, and they >>> typically require a very senior reviewer. But there are lo

Re: [HACKERS] Commitfest problems

On 16/12/14 07:33, David Rowley wrote: > On 16 December 2014 at 18:18, Josh Berkus > wrote: > > > Man. You're equating stuff that's not the same. You didn't get your way > > (and I'm tentatively on your side onthat one) and take that to imply > > that we don

Re: [HACKERS] Commitfest problems

On 16/12/14 04:57, Noah Misch wrote: >> But that doesn't mean we should be turning anyone away. We should not. > > +1. Some of the best reviews I've seen are ones where the reviewer expressed > doubts about the review's quality, so don't let such doubts keep you from > participating. Every defe

Re: [HACKERS] Commitfest problems

On 15/12/14 19:27, Robert Haas wrote: > On Sun, Dec 14, 2014 at 4:53 PM, Mark Cave-Ayland > wrote: >> What I find frustrating is that I've come back from a workflow where >> I've been reviewing/testing patches within months of joining a project >> because the

Re: [HACKERS] Commitfest problems

On 15/12/14 19:24, Andrew Dunstan wrote: > On 12/15/2014 02:08 PM, Robert Haas wrote: >> On Sun, Dec 14, 2014 at 2:24 PM, Mark Cave-Ayland >> wrote: >>> However if it were posted as part of patchset with a subject of "[PATCH] >>> gram.y: add EXCLUDED pseudo

Re: [HACKERS] Commitfest problems

On 15/12/14 19:08, Robert Haas wrote: > On Sun, Dec 14, 2014 at 2:24 PM, Mark Cave-Ayland > wrote: >> However if it were posted as part of patchset with a subject of "[PATCH] >> gram.y: add EXCLUDED pseudo-alias to bison grammar" then this may pique >> my intere

Re: [HACKERS] Commitfest problems

On 15/12/14 16:28, Andres Freund wrote: > I don't believe this really is a question of the type of project. I > think it's more that especially the kernel has had to deal with similar > problems at a much larger scale. And the granular approach somewhat > works for them. Correct. My argument was

Re: [HACKERS] Commitfest problems

On 14/12/14 20:07, Craig Ringer wrote: > On 12/15/2014 02:46 AM, Mark Cave-Ayland wrote: >> Interestingly enough, I tend to work in a very similar way to this. When >> submitting patches upstream, I tend to rebase on a new branch and then >> squash/rework as required. >

Re: [HACKERS] Commitfest problems

On 14/12/14 18:24, Peter Geoghegan wrote: > On Sun, Dec 14, 2014 at 9:05 AM, Tom Lane wrote: >> TBH, I'm not really on board with this line of argument. I don't find >> broken-down patches to be particularly useful for review purposes. An >> example I was just fooling with this week is the GROU

Re: [HACKERS] Commitfest problems

On 14/12/14 17:30, Andrew Dunstan wrote: > On 12/14/2014 12:05 PM, Tom Lane wrote: >> Craig Ringer writes: >>> On 12/14/2014 10:35 PM, Mark Cave-Ayland wrote: >>>> Compare this to say, for example, huge patches such as RLS. >>> I specifically objecte

Re: [HACKERS] Commitfest problems

On 14/12/14 17:05, Tom Lane wrote: > Craig Ringer writes: >> On 12/14/2014 10:35 PM, Mark Cave-Ayland wrote: >>> Compare this to say, for example, huge patches such as RLS. > >> I specifically objected to that being flattened into a single monster >> patch wh

Re: [HACKERS] Commitfest problems

On 14/12/14 15:57, Craig Ringer wrote: > On 12/14/2014 10:35 PM, Mark Cave-Ayland wrote: > >> If I could name just one thing that I think would improve things it >> would be submission of patches to the list in git format-patch format. >> Why? Because it enables two

Re: [HACKERS] Commitfest problems

On 14/12/14 15:51, Craig Ringer wrote: > On 12/14/2014 10:35 PM, Mark Cave-Ayland wrote: >> Compare this to say, for example, huge patches such as RLS. > > I specifically objected to that being flattened into a single monster > patch when I saw that'd been done. If you

Re: [HACKERS] Commitfest problems

On 13/12/14 09:37, Craig Ringer wrote: >> Speaking as the originator of commitfests, they were *always* intended >> to be a temporary measure, a step on the way to something else like >> continuous integration. > > I'd really like to see the project revisit some of the underlying > assumptions th

Re: [HACKERS] Spinlocks and compiler/memory barriers

On 02/07/14 08:36, Andres Freund wrote: On 2014-07-01 20:21:37 -0400, Tom Lane wrote: Andres Freund writes: On 2014-07-01 23:21:07 +0100, Mark Cave-Ayland wrote: Also if you're struggling for Sun buildfarm animals, recent versions of QEMU will quite happily install and run later versio

Re: [HACKERS] Spinlocks and compiler/memory barriers

On 01/07/14 11:04, Andres Freund wrote: Since we have a Sun Studio machine in the buildfarm, we shouldn't give up on SPARC completely, but maybe we should only add the cases for sparcv8+ and above? That at least has some chance of getting tested. That we have code for sparcv7 is ridiculous bt

Re: [HACKERS] Interrupting long external library calls

On 16/05/12 11:39, Heikki Linnakangas wrote: One of the issues we've been looking at with PostGIS is how to interrupt long-running processing tasks in external libraries, particularly GEOS. After a few tests here, it seems that even the existing SIGALRM handler doesn't get called if statement_ti

[HACKERS] Interrupting long external library calls

Hi all, One of the issues we've been looking at with PostGIS is how to interrupt long-running processing tasks in external libraries, particularly GEOS. After a few tests here, it seems that even the existing SIGALRM handler doesn't get called if statement_timeout is reached when in an externa

Re: [HACKERS] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

On 14/12/11 13:59, Andrew Dunstan wrote: Hmm. Yeah, if I remove -O0 and instead set CFLAGS to -ffloat-store the error goes away. So, would we want to use that just for this file, or for the whole build? Well the latest documentation for gcc gives 2 options: -ffloat-store and -fexcess-precisi

Re: [HACKERS] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

NightStrike from the MingW-W64 project to fix previous bugs, and as long as they can build the offending source themselves then they are very helpful and quick to respond. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through f

Re: [HACKERS] improved parallel make support

lopers to suddenly start maintaining the Windows build is a total non-starter. My hope is that one day CMake will enable us to come up with a universal solution, but we're some way from that yet. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation

Re: [HACKERS] improved parallel make support

Windows, we use MingW builds in order to generate the Makefiles we need (there is no native MSVC build for Windows). Not being able to do this would cause us great inconvenience :( ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control

Re: [HACKERS] knngist - 0.8

at we'd want to include additional information in the future related to geometry validity, for example, which would mean further reducing the range allowed within the spatial_ref_sys table in its existing form. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGI

Re: [HACKERS] knngist - 0.8

airs - i.e. something we can extend in the future if required. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs -- Sent

Re: [HACKERS] PostGIS vs. PGXS in 9.0beta3

re.ac Looks like we need to push a new release in time for 9.0... ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs -- Se

Re: [HACKERS] PostGIS vs. PGXS in 9.0beta3

other words, configure is picking up the wrong pg_config. Since the path fix in the thread was not backported to < 8.3, then the presence of an another pg_config for PostgreSQL < 8.3 in PATH will break things :( ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL -

Re: [HACKERS] Why are these modules built without respecting my LDFLAGS?

ractions.net/pipermail/postgis-users/2010-April/026349.html. Would LDFLAGS_EX in this case be what we need? If so, could it be exposed via a pg_config --libpq option or similar? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc

Re: [HACKERS] [CFReview] Red-Black Tree

E INDEX Time: 1647609.300 ms 0.11 patch == rbtest=# CREATE INDEX idin_rbtree_idx ON links2 USING gin (idin); CREATE INDEX Time: 1864013.526 ms rbtest=# CREATE INDEX idout_rbtree_idx ON links2 USING gin (idout); CREATE INDEX Time: 1661200.454 ms HTH, Mark. -- Mark Cave-Ayland - Senior Tec

Re: [HACKERS] CommitFest Status Summary - 2010-02-03

Robert Haas wrote: Here's an overview of where we stand with the remaining 14 patches, according to my best understanding of the situation. * rbtree - I have done a lot of work reviewing this, and Mark Cave-Ayland has done some work on it, too. But there are some unanswered perfor

Re: [HACKERS] [CFReview] Red-Black Tree

before the first index had even been created. So there is a definite order of magnitude speed increase with this patch applied. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +

Re: [HACKERS] development setup and libdir

ion makefile to see how it all works: http://trac.osgeo.org/postgis/browser/trunk/postgis/Makefile.in http://trac.osgeo.org/postgis/browser/trunk/regress/Makefile.in HTH, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freed

[HACKERS] [CFReview] Red-Black Tree

s with no significant performance regression. It would have been nice to be able to reproduce the whole set of test cases but this was not possible from the information specified. With perhaps some minor tweaks to some of the names and a rework of the else clause in ginInsertEntry(), I feel thi

Re: [HACKERS] Add subdirectory support for DATA/DOCS with PGXS

Tom Lane wrote: Why do DOCS still go into doc/contrib? Shouldn't that become doc/$MODULEDIR for consistency? Hmmm it looks as if the code was correct but I missed the comment at the top of the file. Sorry for the confusion - revised version attached. ATB, Mark. -- Mark Cave-A

Re: [HACKERS] Add subdirectory support for DATA/DOCS with PGXS

ets need their files installed in two separate locations. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs diff --git a/src/mak

Re: [HACKERS] Add subdirectory support for DATA/DOCS with PGXS

place. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

[HACKERS] Add subdirectory support for DATA/DOCS with PGXS

in its current form, but I'd be interested to get some initial feedback as to whether the introduction of a new MODULEDIR variable is the best way to add this new piece of functionality. Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius

Re: [HACKERS] Another try at reducing repeated detoast work for PostGIS

raphy (cost=0.00..8.28 rows=1 width=0) (actual time=43.079..172.788 rows=29687 loops=1) Index Cond: (centroid && $0) Filter: ((type)::text = 'Z'::text) Total runtime: 272.185 ms (8 rows) So in conclusion, I think that patch looks good and that the extra time

Re: [HACKERS] Another try at reducing repeated detoast work for PostGIS

Tom Lane wrote: There was recently another go-round on the postgis-devel list about the same problem Mark Cave-Ayland complained about last year: http://archives.postgresql.org/pgsql-hackers/2008-06/msg00384.php Basically, what is happening is a nestloop join where the inner indexscan gets a

Re: [HACKERS] Proper entry of polygon type data

quito. Interesting metaphor... ;) ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make chang

Re: [HACKERS] mingw check hung

- for reference the final patch is here http://postgis.refractions.net/pipermail/postgis-commits/2008-January/000199.html. I appreciate it may not be 100% relevant, but I thought I'd flag it up as possibly being a fault with the MingW putenv implementation. HTH, Mark. -- Mark Cav

Re: [HACKERS] [postgis-devel] CLUSTER in 8.3 on GIST indexes break

some bizarre interaction between CLUSTER/VACUUM/autovacuum? ATB, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] [postgis-devel] CLUSTER in 8.3 on GIST indexes break

YZE count --- 0 (1 row) CLUSTER ANALYZE count --- 0 (1 row) So in other words, the contents of the temporary table has just disappeared :( ATB, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 -- Count s

[HACKERS] Patch status for reducing de-TOAST overhead?

there still scope for getting something like this in 8.4 - or this patch still far shy of anything ready for a commit fest? I have a feeling that working on this is something currently beyond my own capability :( ATB, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts

[HACKERS] Missing results from scroll cursor in PostgreSQL 8.3.3?

are not ordered? Perhaps the only thing that is wrong is that a suitable ERROR message is missing? ATB, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 -- -- Initial data -- CREATE TABLE ctest ( id int8, nam

Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing

while back of enabling some assertions in production builds. ATB, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscri

Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing

d affect the unpatched result, but I was obviously wrong ;) (cut) > On the whole I'm still feeling pretty discouraged about this patch ... At the very least we have some more information on how an eventual solution should work, and a test case to help analyse the effectiveness of any pote

Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing

throws an error if this is present. ATB, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresq

Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing

.7092.00 rows=1 width=4387) (actual time=23.780..54.362 rows=1 loops=1) Filter: (id = 69495::numeric) -> Seq Scan on geography (cost=0.00..7092.00 rows=1 width=0) (actual time=55.016..9073.084 rows=32880 loops=1) Filter: (centroid && $0) Total runtime: 9117.174

Re: [HACKERS] Strange issue with GiST index scan taking far too long

n the geometry would get converted to its bounding box (which would not require deTOASTing) before being used as an index scan key. ATB, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] Strange issue with GiST index scan taking far too long

y(mem, pgl, VARSIZE_EXTERNAL(pgl)); PG_RETURN_POINTER(mem); } ...and of course, this now takes the slower runtime of 2.5s. ATB, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] Strange issue with GiST index scan taking far too long

se that last point in the coordinate sequence, but nothing major. I've removed the -VARHDRSZ part just to check and it doesn't make any difference. Many thanks, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 --

Re: [HACKERS] Strange issue with GiST index scan taking far too long

> Index Scan using geography_geom_centroid_idx on geography (cost=0.00..8.28 rows=1 width=0) (actual time=43.218..286.535 rows=32880 loops=1) Index Cond: (centroid && ($0)::geometry) Filter: (centroid && ($0)::geometry) Total runtime: 376.117 ms (8 rows) ATB, Mark. -- Mar

[HACKERS] Strange issue with GiST index scan taking far too long

in the code, but I'd definitely appreciate any pointers. All these tests were done using PostgreSQL 8.3.1 and the latest PostGIS SVN. Many thanks, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Rewriting Free Space Map

Don't think I like "maps" though, as (a) that prejudges what the > alternate forks might be used for, and (b) the name fails to be > inclusive of the data fork. Other suggestions anyone? I believe that in the world of NTFS the concept is called "streams": http://su

Re: [HACKERS] PostgreSQL 8.4 development plan

stributed SCM, although it wouldn't be entirely out of the question to set up permissions using CVS/SVN. ATB, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Minor bug in src/port/rint.c

On Sun, 2008-01-20 at 16:47 -0500, Tom Lane wrote: > Your proposed fix wouldn't make it act the same as glibc, only move the > differences around. I believe glibc's default behavior for the > ambiguous cases is "round to nearest even number". You propose > replacing "round towards zero", which i

[HACKERS] Minor bug in src/port/rint.c

Hi everyone, I believe that there is a small bug in src/port/rint.c when the input parameter has a fractional part of 0.5 which is demonstrated by the attached program. It appears that the PG version of rint() rounds in the wrong direction with respect to glibc. [EMAIL PROTECTED]:~$ ./test rint(-

Re: [HACKERS] Possible PostgreSQL 8.3beta4 bug with MD5 authentication in psql?

On Sat, 2007-12-08 at 17:09 -0500, Tom Lane wrote: > So what I think we must do is split the function into two: > > PQconnectionNeedsPassword: true if server demanded a password and there > was none to send (hence, can only be true for a failed connection) > > PQconnectionUsedPassword: true if s

Re: [HACKERS] Possible PostgreSQL 8.3beta4 bug with MD5 authentication in psql?

On Sat, 2007-12-08 at 10:09 -0500, Tom Lane wrote: > > My vote goes to (3), if the work can be done quickly, or (1) if it > > can't. Ditto. > I don't think it's a big problem to do, as long as we are agreed on > the behavior we want. In particular, consider: > > 1. If libpq obtains a password

Re: [HACKERS] Possible PostgreSQL 8.3beta4 bug with MD5 authentication in psql?

On Fri, 2007-12-07 at 11:03 -0500, Tom Lane wrote: > Hmmm ... it seems the problem is that we've defined > PQconnectionUsedPassword in such a way that it returns true (causing a > prompt) regardless of whether the reason for the connection failure was > a bad password or not. We might need to rec

[HACKERS] Possible PostgreSQL 8.3beta4 bug with MD5 authentication in psql?

Hi everyone, I think that I may have found a minor bug with PostgreSQL 8.3beta4 with respect to md5 authentication. I actually discovered this on Win32, but it appears that the behaviour is the same under Linux too. As part of the PostGIS install under Win32, I have a few scripts that check for t

Re: [HACKERS] Locating sharedir in PostgreSQL on Windows

On Mon, 2007-11-26 at 17:02 -0500, Tom Lane wrote: > I believe that that is talking specifically about shared libraries (or > DLLs in Windows-speak), and not about configuration or data files. > In particular, nothing under libdir would be a candidate to go under > sharedir, nor vice versa, since

Re: [HACKERS] Locating sharedir in PostgreSQL on Windows

On Mon, 2007-11-26 at 11:55 -0500, Tom Lane wrote: > I'm not sure why Mark's having a problem accessing my_exec_path --- > it *is* declared DLLIMPORT in miscadmin.h (which is where it counts, > AIUI) clear back to 8.0. Bah, I think that is the source of the problem. Having grepped the source for

[HACKERS] Locating sharedir in PostgreSQL on Windows

Hi everyone, I'm working on a piece of code for PostGIS to allow the loading of projection configuration files from the share/postgresql directory, but I can't find a way of getting this to work under Win32. AIUI the way to do this would be to use a combination of my_exec_path and get_share_path

Re: [HACKERS] msvc and vista fun

On Sun, 2007-06-24 at 13:23 -0400, Andrew Dunstan wrote: (cut) > On a somewhat related note, I have had spectacular lack of success in > getting either MSVC or MinGW builds to work on Vista - so much so that I > have currently abandoned my attempts on that platform and I resorted to > resuscit

Re: [HACKERS] Hierarchical Queries--Status

On Thu, 2007-02-08 at 20:49 -0500, Bruce Momjian wrote: > Who is working on this item? Jonah was trying to complete this for 8.3, but I believe that he has handed it onto Gregory Stark - I think http://archives.postgresql.org/pgsql-hackers/2007-01/msg01586.php is the latest update. Kind regards,

Re: [HACKERS] Function execution costs 'n all that

On Mon, 2007-01-15 at 15:05 -0500, Tom Lane wrote: > Brian Hurt <[EMAIL PROTECTED]> writes: > > Non-developer here, but we use a lot of plpgsql functions at work. And > > the functions we use fall into two broad, ill-defined catagories- > > "expensive" functions and "cheap" functions. What I'd

Re: [HACKERS] WITH support

On Wed, 2007-01-03 at 09:45 +0100, Hubert FONGARNAND wrote: > Why not looking at http://gppl.moonbone.ru/ evgen potemkin. has ever > made a patch for WITH and CONNECT BY? > > I'm ready to test these features... (RECURSIVE) when they'll land in > CVS... Hi Hubert, IIRC there were two issues - f

Re: [HACKERS] WITH support

On Sat, 2006-12-30 at 00:49 -0500, Jonah H. Harris wrote: > On 12/29/06, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > No code yet, and I don't remember who said they were working on it. > > I'm still waiting to hear from Mark Cave-Ayland on whether he's going

Re: [HACKERS] 8.2beta1 crash possibly in libpq

Hi Magnus, I finally got to the bottom of this - it seems that the flags being passed to MingW's linker were incorrect, but instead of erroring out it decided to create a corrupt executable. Here is the command line that was being used to link the pgsql2shp.exe executable, along with the associate

Re: [HACKERS] 8.2beta1 crash possibly in libpq

On Sun, 2006-10-08 at 17:53 +0200, Magnus Hagander wrote: > > AFAICT the backtrace and server log is indicating that the > > crash is happening somewhere in libpq. If someone can help me > > figure out how to load the libpq symbols into MingW's gdb > > then I can get a better backtrace if requir

[HACKERS] 8.2beta1 crash possibly in libpq

Hi everyone, I'm in the process of generating the Windows installer for the latest PostGIS 1.1.4 release and I'm getting a regression failure in one of libpq applications - the application in question is generating a segfault. Testing so far shows that the regression tests pass without segfaultin

Re: [HACKERS] [PATCHES] WIP: Hierarchical Queries - stage 1

Hi Tom, Thanks for your initial thoughts on this. On Wed, 2006-09-20 at 20:13 -0400, Tom Lane wrote: (cut) > You really can't get away with having the identical representation for > CTEs and ordinary sub-selects in the range table. For instance, it > looks like your patch will think that > >

Re: [HACKERS] -HEAD planner issue wrt hash_joins on dbt3 ?

On Mon, 2006-09-18 at 17:46 +0200, Matteo Beccati wrote: > Tom Lane ha scritto: > > Matteo Beccati <[EMAIL PROTECTED]> writes: > >> I cannot see anything bad by using something like that: > >> if (histogram is large/representative enough) > > > > Well, the question is exactly what is "large enough

Re: [HACKERS] Hierarchical Queries--Status

On Sat, 2006-08-26 at 22:46 -0400, Jonah H. Harris wrote: > On 8/26/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > Actually I was thinking in the design rather than the code ... > > Doh! We hadn't posted the design just yet. Let me write him and see > where he's at and we'll throw something t

Re: [HACKERS] Proposal for debugging of server-side stored procedures

> -Original Message- > From: Thomas Hallgren [mailto:[EMAIL PROTECTED] > Sent: 11 June 2006 10:07 > To: Mark Cave-Ayland > Cc: pgsql-hackers@postgresql.org > Subject: Re: Proposal for debugging of server-side stored procedures Hi Tom, (cut) > Obviously I'm no

Re: [HACKERS] Proposal for debugging of server-side stored procedures

> -Original Message- > From: Andrew Dunstan [mailto:[EMAIL PROTECTED] > Sent: 09 June 2006 17:01 > To: Mark Cave-Ayland > Cc: 'Tom Lane'; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Proposal for debugging of server-side stored > procedures (cut)

Re: [HACKERS] Proposal for debugging of server-side stored procedures

> -Original Message- > From: Thomas Hallgren [mailto:[EMAIL PROTECTED] > Sent: 09 June 2006 16:25 > To: Mark Cave-Ayland > Cc: pgsql-hackers@postgresql.org > Subject: Re: Proposal for debugging of server-side stored procedures > > Some thoughts from another Tom...

Re: [HACKERS] Proposal for debugging of server-side stored procedures

> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: 29 May 2006 18:05 > To: Mark Cave-Ayland > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Proposal for debugging of server-side stored > procedures (cut) > As far as the debug prot

[HACKERS] Proposal for debugging of server-side stored procedures

Hi everyone, Having browsed the TODO list, one of the items that I would be interested on working on is a debugger for stored procedures. Having searched on this topic in the archives, I'm still short of some answers that would allow me to come up with a complete proposal that I can use to start

Re: [HACKERS] WITH/WITH RECURSIVE implementation discussion

> -Original Message- > From: Jonah H. Harris [mailto:[EMAIL PROTECTED] > Sent: 01 May 2006 14:56 > To: Mark Cave-Ayland > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] WITH/WITH RECURSIVE implementation discussion > > On 5/1/06, Mark Cave-Ayland &

[HACKERS] WITH/WITH RECURSIVE implementation discussion

Hi folks, Looking ahead at some of the projects I'll be working on in the future, I'm seeing that having an implementation of WITH/WITH RECURSIVE for working with tree structures is going to be a very useful feature and so would like to re-start the discussions on this to see whether this could be

Re: [HACKERS] Any advice about function caching?

> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: 07 November 2005 23:06 > To: Mark Cave-Ayland (External) > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Any advice about function caching? (cut) > If you want per-query sta

[HACKERS] Any advice about function caching?

Hi everyone, I'm currently in the middle of trying to implement a cache for a PostGIS server-side function that uses an external library with an expensive startup cost, and was hoping to find some advice on the best way to implement it. The function currently takes 2 parameters - a customised C g

[HACKERS]

> Date: Thu, 04 Aug 2005 11:12:58 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: Matteo Beccati <[EMAIL PROTECTED]> > Cc: pgsql-hackers@postgresql.org > Subject: Re: Enhanced containment selectivity function > Message-ID: <[EMAIL PROTECTED]> > > Matteo Beccati <[EMAIL PROTECTED]> writes: > > Th

Re: [HACKERS] Implementing SQL/PSM for PG 8.2 - debugger

Hi guys, > I lean with you and Tom. While running it over the same libpq protocol > would be helpful in some ways, it would have a lot of drawbacks and > would really change the function of libpq. I think a separate debugging > protocol is in order. Just putting on my network hat for a momen

Re: [HACKERS] Fixing r-tree semantics

> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: 24 June 2005 14:27 > To: Mark Cave-Ayland (External) > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; oleg@sai.msu.su; > pgsql-hackers@postgresql.org; 'PostGIS Development Discussion'

Re: [HACKERS] Fixing r-tree semantics

Hi Tom, > What needs more discussion is that it seems to me to make sense to extend the standard > opclasses to handle the four Y-direction operators comparable to the X-direction > operators that are already there, that is "above", "below", "overabove", and > "overbelow". As part of PostGIS (

Re: [HACKERS] Quick-and-dirty compression for WAL backup blocks

> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: 04 June 2005 16:46 > To: Mark Cave-Ayland (External) > Cc: pgsql-hackers@postgresql.org > Subject: Re: Quick-and-dirty compression for WAL backup blocks (cut) > I've completed a test run

Re: [HACKERS] Quick-and-dirty compression for WAL backup blocks

> Date: Tue, 31 May 2005 16:26:20 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: pgsql-hackers@postgreSQL.org > Subject: Quick-and-dirty compression for WAL backup blocks > Message-ID: <[EMAIL PROTECTED]> (cut) > ... make the WAL writing logic aware of the layout > of buffer pages --- specific

  1   2   >