headers
Marvin | 1 Aug 2003 01:08
Picon

Re: Starting PostgreSQL server as root

You don't have to LOGOUT and LOGIN again as another user,
you just do: # su <user>

#su postgres

The postgres must exist and this is who will own the database.

Regards,


MAGO
 
-------Mensaje original-------
 
De: Daniel Gerardo Lucero Baylon
Fecha: Jueves, 31 de Julio de 2003 05:03:08 p.m.
A: pgsql-admin <at> postgresql.org
Asunto: [ADMIN] Starting PostgreSQL server as root
 
I installed PostgreSQL 7.3.4 on Red Hat Linux 8.0.

When I tried to mount database (using initdb command), following error
appear:

You cannot run initdb as root. Please log in as the (unprivileged) user that
will own the server process.

I read at Postgre documentation, and I need to log on as another user and
strt
process.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephan Szabo | 1 Aug 2003 02:12

Re: Parallel transactions failing oddly


On 31 Jul 2003, Mauri Sahlberg wrote:

> Either we have found a bug in Postgres (which I seriously doubt) or we
> are being stupid clever enough way to not notice it.
>
> We have five complex "transactions" that are executed thru pq++/c++
> interface. If we run them one by one everything goes fine. But if I
> run them in parallel - in separate processes - all but the first one
> claiming the lock for "ryhmalaiset"-table will fail. And they will
> fail as soon as the first one is finished by trying to insert
> duplicate row in the shared table. Incidentally this row would also be
> the very first row they are trying to insert. They all run the same code
> but with different data.
>
> Each transaction fails in the following insert:
>  LOOP
>   SELECT * INTO r FROM kelaaryhma(aToimiala, aKielikoodi, pKoodi);
>
>   SELECT INTO pRyhmalaiset * FROM ryhmalaiset
>   WHERE
>           toimiala      = aToimiala             AND
>           ryhma         = pKoodi                AND
>           kuukausi      = aKuukausi             AND
>           vuosi         = aVuosi;
>
>   IF NOT FOUND THEN
>           aMessage:= pKoodi::VARCHAR(16)||''/''||aKoodi::VARCHAR(16);
>           RAISE NOTICE ''ins-ryhmalaiset %'', aMessage;
>           INSERT INTO ryhmalaiset
(Continue reading)

Permalink | Reply | 7 comments |
headers
Romildo Wildgrube | 1 Aug 2003 02:18

Re: a question

There are two interfaces that I know of.

1) pgAdmin II is a windows based  interface to postgress but they 
already have a alpha code for pgAdmin III wich will work on unix and 
other platforms. http://www.pgadmin.org

2) phpPgAdmin which is a web based interface to postgres done in php. 
Very cool tool.  http://phppgadmin.sourceforge.net/

Hope this helps.

Romi

Mehrab Erfani wrote:

>I am looking for a GUI interface offered by Postgresql if you could help me
>with that I'd really appreciate it.
>
>Thanks
>
> 
>
>M.Erfani
>
>
>  
>

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Lane | 1 Aug 2003 02:29
Picon

Re: time zone on timestamp fields

"Arno A. Karner" <karner <at> tnss.com> writes:
> I'm playing with redhat 9.0 which is postgresql 7.3..2
> I set my date style like I have on previous releases to "ISO" the time 
> stamps show up in ISO format, but with out time zone info?

"timestamp" now means "timestamp without time zone", per SQL spec.

You want datatype "timestamp with time zone" (or "timestamptz" if you're
lazy).

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo <at> postgresql.org)
Permalink | Reply | 0 comments |
headers
Tom Lane | 1 Aug 2003 02:38
Picon

Re: Stuck Spinlock Error Message

Ludwig Isaac Lim <ludz_lim <at> yahoo.com> writes:
>      What can cause a stuck spinlock?

In theory, that shouldn't ever happen.  Can you reproduce it?

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Permalink | Reply | 2 comments |
headers
maillist | 1 Aug 2003 04:41

time zone on timestamp fields

Ok me dumb, I've spend copple days editing my table definintions from
Dlm     DATETIME NOT NULL DEFAULT TEXT 'now'
Dlm = date time last modified to
Dlm     timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP

which from my previous post I was told should be
Dlm     timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP

now some where along the line I expect to get asked what time zone, and
I don't want my stupid programs to have to me time zone aware,  Back in
the good ol days I could use someting like cst5cdt, but I don't think
that will work any more. and since the postgres programers who I am
grateful to, don't want to code this politicly controled stuff either,
their documentation reflects this. and realy this makes no difference to
me either except in one one in october from 2:00 am to 2:00 am. But
before I go back and change the 100 so table defenitions again, and
change the ones I haven't made it to yet could  someone please give me a
quick and dirty explaination as to what I should change it to, and If
you want to elaberate on why, I'll consider it a plus.

    Thanks in advance
    Arno

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match
Permalink | Reply | 0 comments |
headers
Rajesh Kumar Mallah | 1 Aug 2003 05:56

Re: Recall: help needed for performance tuning

Hi,

1. Please post performance related questions to
pgsql-performance <at> postgresql.org for better
response.

2. Please try to give as much information as possible in
 first place itself , eg
 a) you have not told what the query is
 b) what is the explain analyze output of the query (  explain analyze 
<query> )
 c) version of PostgreSQL  (select version() )

merely telling ur query is slow doesnt' help .

Regds
Mallah.

Priya Nair wrote:

>Priya Nair would like to recall the message, "help needed for performance tuning".
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: the planner will ignore your desire to choose an index scan if your
>      joining column's datatypes do not match
>  
>

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
(Continue reading)

Permalink | Reply | 0 comments |
headers
maillist | 1 Aug 2003 06:54

fyi

previous table definition guess no not null of default ''

curreent table definitionCREATE TABLE apps
(
Id      int not null unique,    -- AppId
Sym     varchar(8) not null default '', -- app symbol name
Nam     varchar(30) not null default '',    -- app full name
BitPriv varchar(10) not null default '',    -- app bit priv
NamPriv varchar(255) not null default '',   -- app nam priv
AppDir  varchar(80) not null default '',    -- app dir nam
AppPag  varchar(32),			    -- app page nam
Aka     int,                    -- ptr to real name
Uid     int not null default 0, -- ptr to las mod user id
Dlm     timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE apps
(
Id      int not null unique,    -- AppId
Sym     varchar(8) not null default '', -- app symbol name
Nam     varchar(30) not null default '',    -- app full name
BitPriv varchar(10) not null default '',    -- app bit priv
NamPriv varchar(255) not null default '',   -- app nam priv
AppDir  varchar(80) not null default '',    -- app dir nam
AppPag  varchar(32) not null default '',    -- app page nam
Aka     int,                    -- ptr to real name
Uid     int not null default 0, -- ptr to las mod user id
Dlm     timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
);
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mauri Sahlberg | 1 Aug 2003 07:26

Re: Parallel transactions failing oddly

On pe, 2003-08-01 at 03:12, Stephan Szabo wrote:
> > interface. If we run them one by one everything goes fine. But if I
> > run them in parallel - in separate processes - all but the first one
> > claiming the lock for "ryhmalaiset"-table will fail. And they will
> > fail as soon as the first one is finished by trying to insert
> > duplicate row in the shared table. Incidentally this row would also be
> > the very first row they are trying to insert. They all run the same code
> > but with different data.
> >
> The second transaction won't see the row inserted by the first transaction
> until it commits (at best).  Both transactions can think there are no
> matching rows.

Umh, but as the "ryhmalaiset" table is locked until the transaction is
commited? And what do you mean with "at best"? Is there any way ensuring
that the other transactions won't access the table until the first one
has finished updating it if the lock is not enough?

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
Permalink | Reply | 0 comments |
headers
Stephan Szabo | 1 Aug 2003 07:51

Re: Parallel transactions failing oddly


On 1 Aug 2003, Mauri Sahlberg wrote:

> On pe, 2003-08-01 at 03:12, Stephan Szabo wrote:
> > > interface. If we run them one by one everything goes fine. But if I
> > > run them in parallel - in separate processes - all but the first one
> > > claiming the lock for "ryhmalaiset"-table will fail. And they will
> > > fail as soon as the first one is finished by trying to insert
> > > duplicate row in the shared table. Incidentally this row would also be
> > > the very first row they are trying to insert. They all run the same code
> > > but with different data.
> > >
> > The second transaction won't see the row inserted by the first transaction
> > until it commits (at best).  Both transactions can think there are no
> > matching rows.
>
> Umh, but as the "ryhmalaiset" table is locked until the transaction is
> commited? And what do you mean with "at best"? Is there any way ensuring
> that the other transactions won't access the table until the first one
> has finished updating it if the lock is not enough?

I said at best because I dont think serializable mode transactions won't
see the row even after commit as long as its snapshot's been taken
already.  You are locking the table in access exclusive mode right?

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org
(Continue reading)

Permalink | Reply | 4 comments |

Gmane