Re: Getting non_NULL right-side values on a non-matching join?

From: Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org>, Michael James <mjames(at)plymouthhousing(dot)org>
Subject: Re: Getting non_NULL right-side values on a non-matching join?
Date: 2013-11-24 09:17:56
Message-ID: CAD3a31XyrAJkPxC8ue1zS9ym-iRfijx_-5=Nh+3i82p3ySzwiw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, Nov 23, 2013 at 9:21 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com> writes:
> > On Sat, Nov 23, 2013 at 2:20 AM, Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>
> wrote:
> >> Chapter 15 of our documentation handles installing from source.
> >> http://www.postgresql.org/docs/current/static/installation.html
>
> > Thanks for the link. I really do appreciate all the documentation that
> > Postgres has put together. In this case I especially like the short
> > version provided, which covers part of what I was looking for. It would
> be
> > great if there were a similar page that addressed how to set this up
> > side-by-side with an existing installation, and had a cheat sheet for
> > pulling in build tools and libraries. (As in, on Cent OS run "yum
> install
> > x y z...", Ubunutu "apt-get install a x z".) I get that the build
> > environment and libraries are outside of the scope of Postgres proper and
> > maybe unfair to ask it be documented, but they're still steps people have
> > to go through. If they were included in that short version format, it
> > would be fantastic!
>
> FWIW, I think this is outside the scope of Chapter 15, and especially
> outside the scope of the short version ;-). If you're not wanting to
> do the /usr/local approach, you're most likely wanting to build a
> replacement for some distro-supplied packaging of Postgres.

Well yes and no. In my case I'm actually running CentOs with the PGDG
packages straight from you folks.

My starting point was that right now I don't have a non-production spare
machine. So I need to _assure_ myself I'm not going to screw things up
(time sink!). I don't keep a build environment, but don't mind installing
one temporarily.

The two approaches I'd thought of were:

1) Build a new binary, stop server, move new binary into place; start server
(Not sure if this works or not!)

2) Build the whole thing, install and run side-by-side

So maybe /usr/local would work, but it seems like SRPM + patch will be the
closest to matching my current setup, and do the quickest job of pulling in
everything needed.

> There
> are too many of those, and they change too often, for us to be able
> to provide reasonable instructions for that in our formal docs.
> Moreover, 99% of what you need to know for that is not PG-specific but
> distro-specific.
>
> Perhaps it'd be worth setting up page(s) on our wiki about this, though?
> The question certainly comes up often enough.
>
> regards, tom lane
>

As a side thought, what about creating a source RPM configured to install
side-by-side, and on a different port? Wouldn't that be just a few tweaks
to make? And since you're maintaining packages anyway...

But if not, it would be great if the wiki page included a "to build a
side-by-side RPM, these are the X things you have to change after you
install the source" section, and I guess that would work for the
distro-supplied RPMs as well.

Then I could boil it down to:

rpm -qa > original.packages
Download source RPM
yum-builddep source RPM
rpm -i source RPM
Apply patch(es)
Tweak side-by-side config (if not done already)
Build & install binary RPM
(possibly copy binary, or data directory)
test / run / test /run...
rpm -e $( rpm -qa | cat - original.packages | sort | uniq -u )
and maybe remove a few files or folders (listed on the wiki page of course!)

And then it's done, with little hassle and no trace left behind. Although
maybe I'm missing some complexities here. And while I know it's easy to
suggest work for other people, it does seem that at least documenting it
would really simplify things for casual or occasional builders or testers.
I can say for sure that if I'd found something like this documented I
would have tested your patch. Of course in this case it wouldn't have
ended up doing any good... ;)

Cheers,
Ken

--
AGENCY Software
A data system that puts you in control
100% Free Software
*http://agency-software.org/ <http://agency-software.org/>*
ken(dot)tanzer(at)agency-software(dot)org
(253) 245-3801

Subscribe to the mailing
list<agency-general-request(at)lists(dot)sourceforge(dot)net?body=subscribe>
to
learn more about AGENCY or
follow the discussion.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Christofer C. Bell 2013-11-24 13:34:02 Re: ERROR: out of memory DETAIL: Failed on request of size ???
Previous Message Sebastian Hilbert 2013-11-23 18:45:11 Re: [GENERAL] pg_upgrade ?deficiency