Harpreet Dhaliwal wrote:
> Can anyone help me out with funciton(s) to write a debug
> output in a perl function on postgres.
Check out DBI-Link and see how it is done there:
http://pgfoundry.org/projects/dbi-link/
Yours,
Laurenz Albe
---(end of broadcast)
On Mon, Jun 25, 2007 at 12:35:11AM -0400, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > On Mon, Jun 25, 2007 at 09:51:30AM +0900, [EMAIL PROTECTED] wrote:
> >> It seems that real takes 8 byte storage sizes.
>
> > Real is 4 bytes but other columns' alignment requirements might
> >
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Mon, Jun 25, 2007 at 09:51:30AM +0900, [EMAIL PROTECTED] wrote:
>> But PostgreSQL's data disk usage did not shrinked.
>> And pg_dump size remained same.
>> It seems that real takes 8 byte storage sizes.
> Real is 4 bytes but other columns' alignment re
On Mon, Jun 25, 2007 at 09:51:30AM +0900, [EMAIL PROTECTED] wrote:
> Real type takes 4 byte storage sizes and double precision takes 8 bytes.
> I altered a data type from double precision to real and vacuumed DB.
Altering a column's type rewrites the table so vacuuming afterward
shouldn't be neces
Real type takes 4 byte storage sizes and double precision takes 8 bytes.
I altered a data type from double precision to real and vacuumed DB.
But PostgreSQL's data disk usage did not shrinked.
And pg_dump size remained same.
It seems that real takes 8 byte storage sizes.
Here's my environments:
"So frequently the best advice for someone who's thinking of doing
something like this is "redesign your schema so you don't need to". "
I've thought about that. The obvious way to do it would be to split
into two tables, one for the originals, one for the translations (the
objects are actually ph
Jeff Amiel <[EMAIL PROTECTED]> writes:
> I was looking at some logs this morning and spotted this on my backup
> database
> Jun 24 04:08:46 back-app-1 postgres[82445]: [2-1] pgsql 82445 LOG:
> transaction ID wrap limit is 41612954, limited by database "back"
> Should I be worried?
No. It's j
Ragnar <[EMAIL PROTECTED]> writes:
> On sun, 2007-06-24 at 09:54 +, danmcb wrote:
>> Say I have a table, say my_table, that is self-referencing. ...
>> in other words: the row pointed to by orig_id cannot reference any row
>> other than itself.
>> How might I implement this as a constraint?
>
Whenever I read the documentation on the transaction wraparound stuff,
my head spins with all the references to frozen xids and min/max ages.
When it comes down to it, my interpretation of the whole kaboodle is
"run postgresql v8.1 or later and autovacuum, and you will not have
to deal wit
On sun, 2007-06-24 at 09:54 +, danmcb wrote:
> Say I have a table, say my_table, that is self-referencing. It looks
> like this :
> id integer pk,
> orig_id integer references my_table(id),
> Now this set of rows would be legal
>
> id/orig_id
> 1 /1
> 2/1
> 3/1
> 4/4
> 5/4
>
> but this not
On sun, 2007-06-24 at 17:58 +0800, carter ck wrote:
> >From: Ragnar <[EMAIL PROTECTED]>
> >On sun, 2007-06-24 at 16:55 +0800, carter ck wrote:
> > > I am experiencing thgis problem since this morning. I seldom heard about
> > > unique key constraint violation to happen when updating a table.
> > >
Hi..
No. The only unique key is the myid, which is also the primary key. I have
extracted the records out from this database and dump all to a new database.
Everything is fine. But, this is the second time I have encountered this
problem.
Hopefully those who have solutions for this can kindl
Say I have a table, say my_table, that is self-referencing. It looks
like this :
id integer pk,
orig_id integer references my_table(id),
.
.
.
Now this set of rows would be legal
id/orig_id
1 /1
2/1
3/1
4/4
5/4
but this not:
id/orig_id
1 /1
2/1
3/1
4/1
5/4
in other words: the row pointed to
On sun, 2007-06-24 at 16:55 +0800, carter ck wrote:
> I am experiencing thgis problem since this morning. I seldom heard about
> unique key constraint violation to happen when updating a table.
>
> It happens to 1 or few records at early stage, but then to all.
>
> My updating command is as foll
thanks both for this. I haven't got around to writing this part of the
code yet, but will do soon. I appreciate the pointers.
On 21 Jun, 19:13, [EMAIL PROTECTED] (Michael Glaesemann) wrote:
> On Jun 21, 2007, at 11:57 , Josh Tolley wrote:
>
>
>
> > On 6/21/07, danmcb <[EMAIL PROTECTED]> wrote:
>
On Sat, Jun 23, 2007 at 10:33:49PM +0100, Gregory Stark wrote:
> "Martijn van Oosterhout" <[EMAIL PROTECTED]> writes:
> > On Fri, Jun 22, 2007 at 07:38:01PM +0300, Tzahi Fadida wrote:
> >> Let me simplify it in lamer terms.
> >> Basically, you have a cycle in your relations schema. i.e.
> >> rel A
Hi all,
I am experiencing thgis problem since this morning. I seldom heard about
unique key constraint violation to happen when updating a table.
It happens to 1 or few records at early stage, but then to all.
My updating command is as following:
update mytable set my_status='Y' where myid='
17 matches
Mail list logo
