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 =
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
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
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 for
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:
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 thankfully it's
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
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
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 appreciate
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
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?
Running on Red
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 data in
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 think
20 matches
Mail list logo
