Hello
we develop applications on postgresql, use alot of functions, edit
them very often so there is a need for a version control. Is there a
solution like CVS or something for PG databases? Well - for schemas at
least.
--
Julius Tuskenis
Programavimo skyriaus vadovas
UAB nSoft
mob. +370682
I have a user with a problem on his PostgreSQL 8.1 server running
Windows:
The server only has one superuser, and for some reason he decided to
remove the logon privilege on this user in PgAdmin III. So now he has
lost superuser access to the database server.
Is there some way to override this se
> The server only has one superuser, and for some reason he
> decided to
> remove the logon privilege on this user in PgAdmin III. So
> now he has
> lost superuser access to the database server.
>
> Is there some way to override this setting? Or some way to
> trick
> PostgreSQL into creating a ne
Julius Tuskenis wrote:
> Hello
>
> we develop applications on postgresql, use alot of functions, edit them
> very often so there is a need for a version control. Is there a solution
> like CVS or something for PG databases? Well - for schemas at least.
Not directly. People are used to storing
On Sep 18, 2:35 pm, [EMAIL PROTECTED] (Glyn Astill) wrote:
> > The server only has one superuser, and for some reason he
> > decided to
> > remove the logon privilege on this user in PgAdmin III. So
> > now he has
> > lost superuser access to the database server.
>
> > Is there some way to override
Bernt Drange escribió:
> After a lot of fiddling with being able to enter single user mode on a
> windows machine (I had to figure out how to run the command line as
> the correct user, then for some reason -D didn't work, but SET
> PGDATA=xxx worked), I finally managed to fix my problem.
Hmm, th
Hi all,
We've got a PostgreSQL 8.1.11 database that started displaying these
error messages almost immediately AFTER it was restored. It restored
fully and successfully. They occur every few seconds to every few
minutes. Here are the error messages.
[2008-09-18 10:18:14 CDT] idleERROR: invalid by
Hi,
Thanks for the reply and advice.
Scott Marlowe kirjoitti:
Version : 8.1.11Vendor: CentOS
So, you built it its own machine, but you didn't upgrade to at least 8.2?
Now it is: 8.4devel_15092008
The machine was installed by the production team from
Hi,
The only other thing to check is what indexes are defined for
your schema. You can look at a previous post about PostgreSQL
indexing for RT to see what we are using here at Rice. Let me
know if you have any questions.
Cheers,
Ken
On Thu, Sep 18, 2008 at 09:00:14PM +0300, Mauri Sahlberg wrote
Randall Wilson <[EMAIL PROTECTED]> writes:
> We've got a PostgreSQL 8.1.11 database that started displaying these
> error messages almost immediately AFTER it was restored.
> ...
> Is there any way to figure out where the 0x8b character is?
Hmm, did you perhaps change the database encoding from it
On Thu, Sep 18, 2008 at 12:00 PM, Mauri Sahlberg
<[EMAIL PROTECTED]> wrote:
>> So, you built it its own machine, but you didn't upgrade to at least 8.2?
>>
>>
>
> Now it is: 8.4devel_15092008
I don't think I'd be running production data on a dev version of the
db. Not that it's likely to crash an
Yes, the encoding was changed from SQL_ASCII to UTF-8. Does the fact
that it's an "Idle" error conform your theory that some client is
causing the error? I thought the "Idle" error was caused by errors found
during background processes, like vacuums.
I made a plain text backup of the live database
Greetings one and all,
I am porting all my databases from a 32 bit Postgres engine to 64 bit
Postgres. To do this, I did a pg_dumpall and I'm restoring. I got
an error on the restoration as follows:
psql:/dbsdisk/data_load/dbdev_all_080915.sql:3920581: WARNING:
column "collection" has
Randall Wilson <[EMAIL PROTECTED]> writes:
> Yes, the encoding was changed from SQL_ASCII to UTF-8. Does the fact
> that it's an "Idle" error conform your theory that some client is
> causing the error? I thought the "Idle" error was caused by errors found
> during background processes, like vacuum
Carol Walter <[EMAIL PROTECTED]> writes:
> Postgres. To do this, I did a pg_dumpall and I'm restoring. I got
> an error on the restoration as follows:
> psql:/dbsdisk/data_load/dbdev_all_080915.sql:3920581: WARNING:
> column "collection" has type "unknown"
> DETAIL: Proceeding with relatio
log_line_prefix = '[%t] %i'
So, "idle" is just the "command tag", which probably means it's not
associated with a command.
Unless you think grepping my plain text backup is a waste of time,
you've answered all my questions (Thanks) and I don't need a reply.
Thanks again,
Randy Wilson
Tom Lane wro
Well, it''s a guess. A "CREATE VIEW" follows the line that specifies
the warning. (An "ALTER TABLE" immediately precedes it.) This made
me think that is was on a view; then I went through the views till I
found one with a column called "collection". Is there another way I
can isolate wh
Randall Wilson <[EMAIL PROTECTED]> writes:
> log_line_prefix = '[%t] %i'
> So, "idle" is just the "command tag", which probably means it's not
> associated with a command.
No, you missed my point: if an incoming command contains invalidly
encoded characters, the error about that will be thrown *be
Carol Walter <[EMAIL PROTECTED]> writes:
> Well, it''s a guess. A "CREATE VIEW" follows the line that specifies
> the warning. (An "ALTER TABLE" immediately precedes it.) This made
> me think that is was on a view; then I went through the views till I
> found one with a column called "coll
19 matches
Mail list logo
