Re: [HACKERS] Can we add sample systemd service file to git repo?
On 12 November 2013 20:54, Nigel Heron wrote: > On Tue, Nov 12, 2013 at 11:47 AM, Devrim GÜNDÜZ wrote: ... >> http://svn.pgrpms.org/browser/rpm/redhat/9.3/postgresql/F-19/postgresql-9.3.service >> is an example of what we use in the RPMs. (if website fails, please just >> reload) >> >> Attached is a modified version that will work with the compile defaults. > Hi, should we put PGPORT in the systemd file without an easy way to override > it? > As an example, when yum updating minor versions on fedora 18 (using > the yum.postgresql.org rpms), any changes to the systemd service file > are overwritten by the new rpm and the port is forced back to 5432. > This makes having pg9.2 and pg9.3 on the same box conflict after each > minor version update. IIRC there's a "%config(noreplace)" directive in the .spec that can cause the new file to be saved with an extension (.rpmnew?) instead of overwriting the old one. -- 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] SPGist "triple parity" concept doesn't work
On 7 June 2013 02:32, Tom Lane wrote: > Hm, good point. That reinforces my feeling that the page-number-based > approach isn't workable as a guarantee; though we might want to keep > that layout rule as a heuristic that would help reduce contention. Can the locks just be taken in, say, numeric order of the pages involved? -- 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] [PATCH] binary heap implementation
Assert(!"description of error") is an idiom I've seen more than once,
although I'm not sure I understand why it's not written as Robert says with
the condition in the brackets (or as a print to STDERR followed by abort()
instead).
On 15 November 2012 15:11, Robert Haas wrote:
> On Wed, Nov 14, 2012 at 8:11 AM, Abhijit Menon-Sen
> wrote:
> > Comments? Suggestions?
>
> It could use a run through pgindent. And the header comments are
> separated by a blank line from the functions to which they are
> attached, which is not project style.
>
> + if (heap->size + 1 == heap->space)
> + Assert("binary heap is full");
>
> This doesn't really make any sense. Assert("binary heap is full")
> will never fail, because that expression is a character string which
> is, therefore, not NULL. I think you want Assert(heap->size <
> heap->space). Or you could use (heap->size + 1 >= heap->space)
> elog(LEVEL, message) if there's some reason this needs to be checked
> in non-debug builds.
>
> + {
> + sift_down(heap, i);
> + }
>
> Project style is to omit braces for a single-line body. This comes up
> a few other places as well.
>
> Other than the coding style issues, I think this looks fine. If you
> can fix that up, I believe I could go ahead and commit this, unless
> anyone else objects.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> 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] What are the advantages of not being able to access multiple databases with one connection?
On 30 October 2012 12:37, crocket wrote: > MySQL permits a connection to access multiple databases. > But Postgresql restricts a connection to one database. > I think postgresql database connection is somewhat limited. > > Is it an old and decrepit design? or does it deserve some appreciations? Actually, a "database" in postgresql supports multiple "schemas", and the "databases" in mysql are more or less congruent to those. To put it another way, pg has a three-level namespace which can be accessed through the same host and port combination; mysql only has two levels. Is that better? -- 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] Successor of MD5 authentication, let's use SCRAM
On 14 October 2012 22:17, Daniel Farina wrote: > The problem there is that it's a pain to get signed certs in, say, a > test environment, so "don't check certs" will make its way into the > default configuration, and now you have all pain and no gain. This is precisely the issue that Debian deals with in providing the "default Snake Oil" certificate; software development teams - especially small shops with one or two developers - don't want to spend time learning about CAs and creating their own, etc, and often their managers would see this as wasted time for setting up development environments and staging systems. Not saying they're right, of course; but it can be an uphill struggle, and as long as you get a real certificate for your production environment, it's hard to see what harm this (providing the "snake oil" certificate) actually causes. -- 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] Last gasp
On 6 April 2012 01:19, Noah Misch wrote: > On Thu, Apr 05, 2012 at 02:34:30PM -0400, Robert Haas wrote: >> On Thu, Apr 5, 2012 at 2:23 PM, Tom Lane wrote: >> > The FK arrays one I'm kind of queasy about. ?It's a cool-sounding idea >> > but I'm not convinced that all the corner-case details have been >> > adequately thought through, and I'm scared of being unable to fix any >> > such bugs in later versions because of backwards compatibility worries. >> > It'd be a lot better to be pushing this in at the start of a devel cycle >> > than the end. >> >> I've been feeling that that patch has been suffering from a lack of >> reviewer attention, which is a real shame, because I think the >> functionality is indeed really cool. But I haven't looked at it >> enough to know what kind of shape it's in. > > As the reviewer, I'm not aware of any unexplored corner cases or problems that > ought to preclude commit. That said, it is a large patch; I doubt anyone > could pick it up from scratch and commit it with less than a solid day's > effort, and 2-3 days might be more likely. In retrospect, I should have > suggested splitting the new ON DELETE/ON UPDATE actions into their own patch. > That would have nicely slimmed the base patch and also isolated it from the ON > DELETE EACH CASCADE judgement call. As a likely user of this feature (not sure if this needs a "disclaimer", but my employer offered a small bounty towards the development), I'd only need "ON DELETE RESTRICT" behaviour, currently, and wouldn't ever need "ON UPDATE ..." as the referent column would always be a SERIAL. In the meantime, I'm pretty sure the restriction could be handled by a hand-rolled trigger on insert and delete, but the delete one would be a lot slower without some kind of indexing. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
