Jolles, Peter M (GE Infra, Energy) wrote:
I am trying to migrate several years of historical data with timestamps
from an MS Access database to Postgres. I am running into an issue where
specific dates/times get pushed one hour ahead, which creates duplicate
date/time stamps or failes the import
On Sat, Jan 3, 2009 at 5:59 PM, Jolles, Peter M (GE Infra, Energy)
wrote:
> For example, on these days, 4/7/02 2:00 AM imports to 4/7/02 3:00 AM.
> 4/6/03 2:15 AM imports as 4/6/03 3:15 AM, etc. All other dates and times
> do not give any errors. I have tried to extract the date and create a
> t
I am trying to migrate several years of historical data with timestamps
from an MS Access database to Postgres. I am running into an issue where
specific dates/times get pushed one hour ahead, which creates duplicate
date/time stamps or failes the import if I have that defined as my
primary key. Th
Hi,
searchelite wrote:
...
i can use pg_sleep..but i have thousands of data to be inserted..is there
any better way using pg_sleep?
I wonder what is you complete problem? It seems all the advices given
so far are shots-in-the-dark. Could you perhaps expand a bit?
Also for sophisticated solut
Hello.
I am testing different security models to use on a new database, where I
want different users to be restricted to their own data.
Users would be able to connect to the database through an interface, but
in particular cases of advanced users, they will be able to directly
connect to the da
On Saturday 03 January 2009 10:43:09 am Kenneth Lundin wrote:
> Tom,
>
> Well, it's not really "I" that change the password, it happens in the
> backup dump file created automatically by pg_dumpall.
>
> The thing is as an administrator, you want to be able to take a backup at
> certain points in ti
Tom,
Well, it's not really "I" that change the password, it happens in the backup
dump file created automatically by pg_dumpall.
The thing is as an administrator, you want to be able to take a backup at
certain points in time and then later flawlessly be able to restore that
backup and end up in
"Kenneth Lundin" writes:
> How do I avoid this scenario?
Don't change the postgres user's password in the middle of a dump/restore?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.p
Hi All,
I have a backup/restore problem I need help with.
I do a simple dump of the whole cluster using pg_dumpall, with role
definitions and tutti.
When performing restores, I start with a fresh empty database directory that
i create using the createdb utility and specify the super-user to be n
Hi,
I think I am experiencing the "forest through the trees" type of scenario
here.
In a nightly cron I have a shell script that executes a couple of things for
our data warehouse.
I call it like this from the cron:
/home/postgres/DB1/sys/createDB1.sh >> /home/postgres/DB1/logs/createDB1.log
2
You need to write a process that will do it.
At best you can use crontab if your a lucky and use Unix.
--
Fahrbahn ist ein graues Band
weisse Streifen, grüner Rand
On Saturday January 3 2009 11:46:47 searchelite wrote:
> Daniel Verite wrote:
> > searchelite wrote:
> >
> >
> > How about usin
Daniel Verite wrote:
>
> searchelite wrote:
>
>
> How about using pg_sleep ?
>
> INSERT ;
> COMMIT;
> SELECT pg_sleep(60);
>
> INSERT...;
> COMMIT;
> SELECT pg_sleep(60);
>
>
>
>
i can use pg_sleep..but i have thousands of data to be inserted..is there
any better way using
12 matches
Mail list logo
