"Clarence" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I seem to recall having fixed a bug like this in the past. What PG
>> version are you running?
> We're running 8.0.3
Um. Extract from the 8.0.5 CVS logs:
2005-12-08 14:19 tgl
* src/backend/: postmaster/bgwriter.c, utils/reso
nuno wrote:
>hi, there. i'm trying to write a SQL statement which does the following
>things.
>
>1. checks if data already exists in the database
>2. if not, insert data into database otherwise skip.
>
>
>
Check this thread :
http://archives.postgresql.org/pgsql-general/2005-10/msg01787.php
So far, here are the candidates: Andromeda, Lazarus, and Rekall.
I was probably fairly inarticulate in my first post, but none of these
seem to meet my criteria for automatic generation of forms based on the
database definition. Most of the above frameworks have a good deal
more functionality th
Tom Lane wrote:
> "Clarence" <[EMAIL PROTECTED]> writes:
> > I have a completely idle postgresql system (all backends "idle", none
> > "in transaction"); every time I attempt to vacuum a particular table,
> > it hangs after a while.
> > ...
> > In the system error log there is this line:
> >cou
Scott, Ken and Tim,
Thanks for the assistance, I appreciate the advice.
Scott,
The example of
select id1 = nextval(somesequence)
could work for me. I have multiple users with our GUI and imagine I
could use transaction protection to ensure no duplicates between
selecting and incrementing th
Jim Nasby <[EMAIL PROTECTED]> writes:
> > My RFE: When vacuuming a table, pg should try to vacuum the primary key
> > first. If that results in 0 recovered entries, then assume the table has
> > no
> > updates/deletes and skip the rest of that table.
That makes no sense. Vacuum starts by sc
Hi Tom.
Thanks for your suggestion, this was my choice, after I was unable to
find any reference.
On 6/23/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Marco Bizzarri" <[EMAIL PROTECTED]> writes:
> I would like to study the protocol for large object operations
> (lo_read, lo_write,...) between the
Hi Tom, thanks for your reply.On 23-Jun-06, at 11:17 AM, Tom Lane wrote:--oids is only meant to preserve OIDs within user tables; it never hasand never will preserve OIDs for system-catalog entries.So just to clarify, the table's OID itself will never be preserved, but the data inside the table wil
On 6/22/06 2:57 PM, "Jim Nasby" <[EMAIL PROTECTED]> wrote:
> If nothing else, you should bring it up on -hackers and ask to have
> this added as a TODO. It seems like a worth-while addition to pg_dump/
> restore to me...
Thanks for the suggestion.
> To answer another of your emails in this threa
Dylan Hansen <[EMAIL PROTECTED]> writes:
> Since we've started using the pg_autovacuum table we've come to
> realize that keeping OID values between our database dumps is
> critical. I've been doing some testing using the pg_dump command
> with the --oids option.
--oids is only meant to pre
> We've PostgreSQL database, with SQL_ASCII or LATIN1 encoding. We would
> like to migrate them to UNICODE. Is there some contributed/available
> script, or this is something we should do at hand?
I had a similar problem migrating from 7.4 to 8.1 and wanting to
go from sql_ascii to utf8. I did the
I like to make sure the vacuum takes place during off peak times, which
is why I don't use autovacuum.
Jim Nasby wrote:
On Jun 22, 2006, at 7:12 PM, Joseph Shraibman wrote:
I'm running a 8.0 database. I have a very large log table that is
rarely updated or deleted from. The nightly vacuum do
Greetings everyone,Since we've started using the pg_autovacuum table we've come to realize that keeping OID values between our database dumps is critical. I've been doing some testing using the pg_dump command with the --oids option. For some reason, it doesn't seem like the the OID values are be
"Marco Bizzarri" <[EMAIL PROTECTED]> writes:
> I would like to study the protocol for large object operations
> (lo_read, lo_write,...) between the front-end and back-end.
> I've found this
> http://www.postgresql.org/docs/8.1/static/protocol.html, but it looks
> like it has no message specific fo
> SQL Server had a nifty feature here. You could simply toss a SELECT
> statement at the end of a trigger of sproc and the results would be
> returned.
>
> This in effect made a table the potential return type of all commands,
> which could be exploited very powerfully.
>
> Do the hackers have a
On Fri, Jun 23, 2006 at 07:49:19AM -0600, Michael Fuhr wrote:
> This behavior isn't specific to PL/Perl. A standalone Perl program
> exhibits the same behavior, so you might find a better explanation
> in a Perl-specific forum like the comp.lang.perl.misc newsgroup.
If you run it standalone with
Rhys Stewart wrote:
hi all,
something is not adding up. the following query is taking a long time
to run.(its still running right now)
select distinct on (prem) prem, num, addy, mynum,myad,ff.address,
matchtype,
the_geom
from daily.recheck2, _sp_myparcels ff
where
prem not in (
select distinc
On Fri, Jun 23, 2006 at 11:33:42AM +0200, Philippe Lang wrote:
> Am I missing something maybe? It sounds like a bug with lexical variables to
> me...
I think what's happening is that sub init is created once with $val
referencing the lexically-scoped $val from sub foo's first invocation.
When you
hi all,
something is not adding up. the following query is taking a long time
to run.(its still running right now)
select distinct on (prem) prem, num, addy, mynum,myad,ff.address, matchtype,
the_geom
from daily.recheck2, _sp_myparcels ff
where
prem not in (
select distinct on (prem) prem from d
Jim Nasby wrote:
On Jun 21, 2006, at 7:42 AM, H.J. Sanders wrote:
The last 15 years we also used Informix and we never, never had to
unload/load
the database because of an upgrade.
Perhaps somebody knows how they do the trick?
Do they provide a migration/upgrade utility?
In the case of
Hi,
I have something strange here, with Postgresql 8.1.4 under Linux ES 4,
installed from the PG Group binaries:
If I run this script:
CREATE OR REPLACE FUNCTION foo() RETURNS void
AS
$$
my $val;
sub init
{
$val = @_[0];
elog(NOTICE, "1: @_[0]\n");
Hi all.
I would like to study the protocol for large object operations
(lo_read, lo_write,...) between the front-end and back-end.
I've found this
http://www.postgresql.org/docs/8.1/static/protocol.html, but it looks
like it has no message specific for large object...
How is it implemented in c
22 matches
Mail list logo
