Re: Inheritence issue scheme advice?

Ok - loaded up Linux - fun stuff. 
Figured out how to get the code PostgreSQL version 9.0.4 - Have that in a
directory. 
Got the patch from above... 
Placed into same directory. 

Loaded the dependents for the final compile and install with .configure. 

BUT 

When I run the patch I'm getting some Hunk fails?  Is this because I'm not
using the same version that the author intended the patch for? 

From the output it looks to be going through the files properly but just no
able to inset the new code? 

I've tried ignoring white space and even tried a force - of course I backed
everything up prior to this. :)

Do you happen to know what version will work with this?   Do - I need to get
the tree via git?   Or can I download the .gz extract the code - add the
patched code - then recompile - and install? 

Thanks! 

-----
Warmest regards, 

Casey Havenor
--

Re: Contrib source

On 07/01/2011 12:48 AM, gnuoytr <at> rcn.com wrote:
> I just got wholly confused.  Synaptic makes it appear that *contrib is a separate entity.  And the source
isn't in a src subdirectory, but in the contrib directory directly.
Debian, like most distros, produces several binary packages from a 
single source package, so you can only install parts of it if you want.

It sounds like you installed the binary package for the contrib modules, 
rather than downloading the source code.

If you'd used "apt-get source postgresql-8.4-contrib" (or whatever the 
package name is) you would've found that the source package it 
downloaded was just "postgresql-8.4".

If you "apt-cache show postgresql-8.4-contrib" you'll see that the 
source package line will just show "postgresql-8.4" or something like 
that, and will be the same for most of the other packages like the 
client and server binary packages.

--
Craig Ringer

--

-- 
Sent via pgsql-general mailing list (pgsql-general <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: How to create "auto-increment" field WITHOUT a sequence object?

On 07/01/2011 02:20 AM, Dmitry Koterov wrote:
>
> The problem is that these INSERTs are rolled back oftenly (i.e. they 
> are executed within a transaction block which is rolled back time to 
> time), this is an existing design of the current architecture and 
> unfortunately we have to live with it. And I need as compact uniq_id 
> generation (with minimum "holes") as it possible - this is a VERY 
> important requirement (to export these values into external systems 
> which accepts only IDs limited from 1 to 100000).

What you want is often referred to as a "gapless sequence". Searching 
the mailing list archives for that will find you lots of information.

> but seems it performs too hard locking - time to time this query is 
> timed out (or sometimes deadlocks with other queries).
You'll have that problem with any gapless sequence approach. You'll have 
to be prepared to re-try failed transactions after deadlocks, or be 
*extremely* strict about the order in which you perform operations so 
you avoid any deadlocks.

--
Craig Ringer

--

-- 
Sent via pgsql-general mailing list (pgsql-general <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: Inheritence issue scheme advice?

Never-mind I'll just do it by hand. 

-----
Warmest regards, 

Casey Havenor
--
View this message in context: http://postgresql.1045698.n5.nabble.com/Inheritence-issue-scheme-advice-tp4536626p4540532.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

--

-- 
Sent via pgsql-general mailing list (pgsql-general <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: How to create "auto-increment" field WITHOUT a sequence object?

Having done gapless numbering for some users of accounting software,
there are two suggestions I would make.

The first is that any sort of gapless numbering inherently runs into
scalability.  You HAVE to lock relevant records, and this means that
only one insert can run at a time, and it must commit before the next
insert can run.  This means you have to keep your transactions short
and predictable in terms of table order.  The suggestion of using for
update is a good one, but it doesn't entirely get rid of the problem,
which is inherent in ensuring gapless numbering in a system with
concurrent transactions.

The second is that you absolutely should use this approach as rarely
as you can get away with.  If it isn't required, don't use it!

Best Wishes,
Chris Travers

--

-- 
Sent via pgsql-general mailing list (pgsql-general <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: Contrib source

Yeah, I didn't realize that contrib source is in regular source download, nor did I notice that Synaptic was
installing its own version of PG.  The bulb wasn't lit.  In all, I think I should have had two installs of PG;
the one I built from source way back when (and stored out of standard location), and this one.  It did, in fact
build the standard version.  The only reason I noticed was the perpetual error message about being unable
to start PG due to some "server.key" not being found whenever the repository refreshed my machine.  I
figure that it should be able to start the one it built.  

I just did a complete removal, and my home brew PG still works fine.  I'll worry about adding contrib modules later.

Robert

---- Original message ----
>Date: Fri, 01 Jul 2011 07:20:24 +0800
>From: Craig Ringer <craig <at> postnewspapers.com.au>  
>Subject: Re: [GENERAL] Contrib source  
>To: gnuoytr <at> rcn.com
>Cc: pgsql-general <at> postgresql.org
>
>On 07/01/2011 12:48 AM, gnuoytr <at> rcn.com wrote:
>> I just got wholly confused.  Synaptic makes it appear that *contrib is a separate entity.  And the source
isn't in a src subdirectory, but in the contrib directory directly.
>Debian, like most distros, produces several binary packages from a 
>single source package, so you can only install parts of it if you want.
>
>It sounds like you installed the binary package for the contrib modules, 
>rather than downloading the source code.
>
>If you'd used "apt-get source postgresql-8.4-contrib" (or whatever the 
>package name is) you would've found that the source package it 
>downloaded was just "postgresql-8.4".

statically compiling postgres and problem with initdb

Re: How to create "auto-increment" field WITHOUT a sequence object?

Re: How to create "auto-increment" field WITHOUT a sequence object?

On Fri, Jul 1, 2011 at 1:16 AM, Dmitriy Igrishin <dmitigr <at> gmail.com> wrote:
> Hey Chris,
>
>> The suggestion of using for
>> update is a good one, but it doesn't entirely get rid of the problem,
>> which is inherent in ensuring gapless numbering in a system with
>> concurrent transactions.
>
> Why not?

Just because it locks less doesn't mean that it doesn't lock.

The point is:  if gaps are acceptable then the sequences which exist
outside of transactions are idea.  If gaps are not acceptable, you
have to lock and force transactions through the system serially which
means a possibility of deadlocks and performance issues.  These issues
are inherent in gapless numbering because you can't get a gapless
sequence when things roll back without such locks.
>
> I mean the following solution:
>
> CREATE TABLE myseq(tabnm text not null, lastid integer not null);
>
> INSERT INTO myseq SELECT 'mytab', 0; -- initialization
>
> CREATE OR REPLACE FUNCTION public.myseq_nextval(a_tabnm text)
>  RETURNS integer
>  LANGUAGE sql
>  STRICT
> AS $function$
> UPDATE myseq SET lastid = li + 1 FROM
>   (SELECT lastid li FROM myseq WHERE tabnm = $1 FOR UPDATE) foo
>   RETURNING lastid;
> $function$
>
> -- Test
>
> dmitigr=> BEGIN;
> BEGIN
> dmitigr=> SELECT myseq_nextval('mytab');
>  myseq_nextval
> ---------------
>              1
> (1 row)
>
> dmitigr=> ROLLBACK;
> ROLLBACK
> dmitigr=> SELECT * FROM myseq;
>  tabnm | lastid
> -------+--------
>  mytab |      0
> (1 row)
>
> So, with this approach you'll get a lock only on INSERT.

True.  But the point us that you MUST lock on insert to get gapless
sequences, and this creates inherent problems in terms of performance
and concurrency, so that you should not use it unless you really have
no other choice (i.e. because the tax authorities demand it).

Best Wishes,
Chris Travers

--

-- 
Sent via pgsql-general mailing list (pgsql-general <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: statically compiling postgres and problem with initdb

On 1/07/2011 3:28 PM, mona attariyan wrote:
> Hi,
> I statically compiled my postgres and I got the following message when I
> ran initdb:

How did you compile Pg statically?

Please show your configure command line, any environment variables you 
set, etc.

You've also left out a huge amount of information, like your Pg version, 
where you got the sources from, your OS version, your compiler version, 
etc. I strongly suggest that you read this:

   http://wiki.postgresql.org/wiki/Guide_to_reporting_problems

before posting a follow-up.

> There was a discussion about this in the archive, but there wasn't any
> fix for it. I have to compile postgres statically for the project I'm
> doing.

Why? Perhaps if you explained that in a bit more detail it'd be possible 
to find an alternative.

--
Craig Ringer

--

-- 
Sent via pgsql-general mailing list (pgsql-general <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general