Hi Josef,
i must analyze a customer's database offline. Can i import the databse
of the customer into our PostgreSQL environment ?
What must the customer send us ?
Whats the doings for us to open it in our envioronment ?
use pg_dump -o -b -Fc [database to export] > [backup file] in your
c
Hi,
[ please keep CCing to the list (reply all), as this certainly isn't a
personal discussion and could help others. ]
anorganic anorganic wrote:
my opinion:
partitioning is vertical and horizontal, dived table into two or more
parts.
>
replicated only part of some object,here table = rep
Earlier this evening I made the usual mistake someone makes at some
point in their lives - and dropped a database thinking I didn't need it,
then realised later I did.
So, because I have DDL statement logging turned on, I could find the
exact time/date it happened, and attempted to restore from
How can I specify the "Encoding" in the connectionString using pgOleDB with
Visual Basic.?
Doing a quick Google search, it appears to be, you add
"*Encoding*=UNICODE" or whatever you want your encoding to be, in your
connection string.
Try the pgsql-interfaces list - that's more appropriate for this sort of
thing.
Sistemas C.M.P. wrote:
How can I specify the "Encoding" in the con
Excuse the asterisks - they were added in by my mail client - it should
be "Encoding=UNICODE"
Andy Shellam (Mailing Lists) wrote:
Doing a quick Google search, it appears to be, you add
"*Encoding*=UNICODE" or whatever you want your encoding to be, in your
connection string.
Try the pgsql-int
"Andy Shellam (Mailing Lists)" <[EMAIL PROTECTED]> writes:
> (Note, after writing this, I tried restoring to a minute earlier (ie.
> 18:57:40) and still have the same problem.
The PITR recovery process in effect rolls forward until it finds
a transaction-commit record >= the specified time. Now
Hmm OK was worth a shot - probably best bet would be to ask on
pgsql-interfaces.
Andy.
Sistemas C.M.P. wrote:
With or without asterisks it doesn't work. This string work on ODBC but not
with pgOLEDB
- Original Message -
From: "Andy Shellam (Mailing Lists)" <[EMAIL PROTECTED]>
To:
S
Thanks for the info Tom, too much data will have been entered into the
other databases in the cluster by now so I cannot give it another shot
on that server, plus all of yesterday's WAL logs will have been purged
by now by the daily backup routine.
Is it enough to simply have re-copied in the
"Andy Shellam (Mailing Lists)" <[EMAIL PROTECTED]> writes:
> Is it enough to simply have re-copied in the base/xxx directory from the
> base backup, after the PITR recovery had completed (obviously any
> changes made to that database since the base backup won't have been
> restored but thankfull
Hi List! I'm really in need of some guidance here..
We're running PostgreSQL 8.0 and I have PGAdmin v.1.4.3 on my local pc and
version 1.2.2 on my server & the other developer's pc - when I open PGAdmin
to connect to the database(s), I can do so without any problems, however,
when we go to view t
nning
PostgreSQL 8.1.4. When I try to restore these table's contents I've got
an error:
$ time pg_restore -v -d espsm_asme -O -L
espsm_asme_components_statistics_data.list espsm_asme-20070105-0619.custom
pg_restore: connecting to database for restore
pg_restore: implied data-only res
Well, I'd be a little worried about whether the base backup was
self-consistent, but if it was taken at a time where the DB was idle
then you can probably get away with this.
It gets backed up at 2am in the morning and AFAIK there'd be very few
(if any) transactions going through until abo
Hi Jeanna,
Does pgAdmin give you back any error, like permission denied, or
anything like that? Can you see all the properties of the table, such
as indexes, tables etc before you open it?
As it's happening on various PCs and versions of pgAdmin, I'd hazard a
guess that it's server-side, but
Maybe this is answered somewhere or maybe self-evident, but I just wanted
to make sure. I want to know if it's possible to do PITR between different
platforms. I can try and learn, but if anyone knows, I'd appreciate it.
1. file formats
What is the chance that the file format of files under
Thanks for the reply, Andy.
No, no error from pgadmin, and, yes, I can see all the properties of the
tables before opening it. You can open the tables and see menu bars and
what-not, just no data in the tables/views, but like I said, I know the data
is in there, because I can access it using psql
One other thing I've just thought of, if you issue a manual query from
within pgAdmin - does this succeed?
Also roughly how big are the tables (i.e. number of rows) - does it help
if you set a LIMIT in the SQL clause (by default I think it's 1000 rows
but try setting a LIMIT of 1 row and see if
On Fri, Jan 05, 2007 at 12:59:51 -0600,
"Ben K." <[EMAIL PROTECTED]> wrote:
>
> Maybe this is answered somewhere or maybe self-evident, but I just wanted
> to make sure. I want to know if it's possible to do PITR between different
> platforms. I can try and learn, but if anyone knows, I'd appr
We had a vacuum fail recently with the following error:
invalid page header in block 846 of relation "move_pkey"
Anyone have an idea what could cause this problem and what we need to do
to resolve it?
Running on Red Hat Enterprise 3, postgres 7.4.13
--
Until later, Geoffrey
Those who would
Geoffrey wrote:
We had a vacuum fail recently with the following error:
invalid page header in block 846 of relation "move_pkey"
Anyone have an idea what could cause this problem and what we need to do
to resolve it?
Running on Red Hat Enterprise 3, postgres 7.4.13
Regarding the issue abo
On Fri, 2007-01-05 at 16:19, Geoffrey wrote:
> Geoffrey wrote:
> > We had a vacuum fail recently with the following error:
> >
> > invalid page header in block 846 of relation "move_pkey"
> >
> > Anyone have an idea what could cause this problem and what we need to do
> > to resolve it?
> >
>
On Jan 2, 2007, at 6:09 PM, Sriram Dandapani wrote:
I read the release notes for 8.2 which mentioned that transaction
id wraparounds are now on a per-table basis versus database-wide.
Currently for 8.1 I issue a vacuumdb –a command which takes a coule
of days due to the size of the databse.
"Jeanna Geier" <[EMAIL PROTECTED]> writes:
> We're running PostgreSQL 8.0 and I have PGAdmin v.1.4.3 on my local pc and
> version 1.2.2 on my server & the other developer's pc - when I open PGAdmin
> to connect to the database(s), I can do so without any problems, however,
> when we go to view the
Arnau <[EMAIL PROTECTED]> writes:
>I have to restore a database that its dump using custom format (-Fc)
> takes about 2.3GB. To speed the restore first I have restored everything
> except (played with pg_restore -l) the contents of some tables that's
> where most of the data is stored.
I th
24 matches
Mail list logo
