On Sun, Apr 24, 2016 at 05:07:10PM +0100, Tomas J Stehlik wrote:
>> Have you even tried a schema only dump from the original instance?
>
> That's an odd question. However, I understand that maybe a lot of beginners
> come onto this mailing list.
:-)
> You can safely assume that I wrote the orig
Hello Adrian,
> Then I am of no further use to this conversation.
No problem at all.
Thank you for your well considered input and ideas.
Have a lovely day.
Kindest regards,
Tomas
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
ht
On 04/24/2016 09:07 AM, Tomas J Stehlik wrote:
Hello Andrian,
Thank you
Have you even tried a schema only dump from the original instance?
That's an odd question. However, I understand that maybe a lot of beginners
come onto this mailing list.
To the contrary, this is a non-trivial situatio
Hello Karsten,
> In that case I must surely have missed it and feel I
> can no longer be of any assistance, even if it only
> amounted to but contributing leads to be investigated.
> Sorry.
No problem at all.
I very much appreciate all your input and ideas.
Thank you.
Kindest regards,
Toma
Hello Karsten,
Thank you.
> Like replacing (some of) the pg_* containing raw files with
> those from an uncorrupted database (having been suggested
> earlier this year) which may work if the corrupted blocks in
> pg_* only affect data actually describing _that_ database
> rather than establis
On Sunday, April 24, 2016, Karsten Hilbert > wrote:
> On Sun, Apr 24, 2016 at 04:35:56PM +0100, Tomas J Stehlik wrote:
>
> >> Well if the corrupted raw files include the system information
> >> then I think you are out of luck.
> >
> > Well, this topic is not about "luck".
>
> Surely, English isn'
On Sun, Apr 24, 2016 at 04:58:48PM +0100, Tomas J Stehlik wrote:
>>> The question potentially targets someone who could tell
>>> whether something like this is possible.
>>
>> "possible" depends no the exact circumstances, the details of
>> which people have been trying to tease out.
>
> All th
Hello Andrian,
Thank you
> Have you even tried a schema only dump from the original instance?
That's an odd question. However, I understand that maybe a lot of beginners
come onto this mailing list.
To the contrary, this is a non-trivial situation.
You can safely assume that I wrote the origin
On Sun, Apr 24, 2016 at 04:42:21PM +0100, Tomas J Stehlik wrote:
>> If I recall correctly, you stated that the data isn't
>> important in this
>
> Yes, exactly. However, pages in blocks apparently store also the
> representations of the database schemas. And those are also corrupt.
In that case
Hello Karsten,
Thank you.
> I believe Adrian wanted to know whether you attempted a
> schema or complete dump *after* the fact, like what he
> suggested a mail ago or so.
>
> In case the FS corruption "only" affects raw files related to
> user data (as opposed to also affecting data in pg_*
On 04/24/2016 08:54 AM, Karsten Hilbert wrote:
On Sun, Apr 24, 2016 at 04:35:56PM +0100, Tomas J Stehlik wrote:
Well if the corrupted raw files include the system information
then I think you are out of luck.
Well, this topic is not about "luck".
Surely, English isn't my vernacular language
On 04/24/2016 08:35 AM, Tomas J Stehlik wrote:
Hello Adrian,
Thank you.
So did you do a schema only dump or a complete dump?
There is no dump. There are just raw files.
Have you even tried a schema only dump from the original instance?
Well if the corrupted raw files include the system
On Sun, Apr 24, 2016 at 04:35:56PM +0100, Tomas J Stehlik wrote:
>> Well if the corrupted raw files include the system information
>> then I think you are out of luck.
>
> Well, this topic is not about "luck".
Surely, English isn't my vernacular language - but "out of
luck" has seemed to be an
On Sun, Apr 24, 2016 at 04:35:56PM +0100, Tomas J Stehlik wrote:
> > So did you do a schema only dump or a complete dump?
>
> There is no dump. There are just raw files.
I believe Adrian wanted to know whether you attempted a
schema or complete dump *after* the fact, like what he
suggested a mai
Hello Karsten,
> If I recall correctly, you stated that the data isn't
> important in this
Yes, exactly. However, pages in blocks apparently store also the
representations of the database schemas. And those are also corrupt.
A tiny bit only but still corrupt.
Therefore the overall information
Hello Adrian,
Thank you.
> So did you do a schema only dump or a complete dump?
There is no dump. There are just raw files.
> Well if the corrupted raw files include the system information
> then I think you are out of luck.
Well, this topic is not about "luck".
The question potentially ta
Hello Melvin,
Thank you.
Your reply is similar to the first one in that it makes assumptions to the
contrary of my original e-mail.
Therefore I shall tackle only the relevant bits:
1. This is not related to any existing bug. It was a corruption of the file
system.
2. OID of the corrupt databas
On Sun, Apr 24, 2016 at 04:16:10PM +0100, Tomas J Stehlik wrote:
> Please note that I mentioned previously that the database is corrupt.
Given the facts that Adrian attempted to engage in a
solution-bound conversation all the while mentioning that he
doesn't know how to recover the schema from th
On 04/24/2016 08:16 AM, Tomas J Stehlik wrote:
Please note that I mentioned previously that the database is corrupt.
"pg_class" table can be queried but it is not possible to dump the database
in question as some of the pages in blocks are missing.
So did you do a schema only dump or a complet
On Sun, Apr 24, 2016 at 11:16 AM, Tomas J Stehlik
wrote:
> Please note that I mentioned previously that the database is corrupt.
>
> "pg_class" table can be queried but it is not possible to dump the database
> in question as some of the pages in blocks are missing.
>
> In this case, it is necess
Please note that I mentioned previously that the database is corrupt.
"pg_class" table can be queried but it is not possible to dump the database
in question as some of the pages in blocks are missing.
In this case, it is necessary to rely on raw files only. Thanks.
T
--
Sent via pgsql-gener
On 04/24/2016 07:09 AM, Karsten Hilbert wrote:
On Sun, Apr 24, 2016 at 03:00:09PM +0100, Tomas J Stehlik wrote:
What happened if you connected to another database in the cluster?
That's irrelevant.
I dare assume Adrian asked for a reason :-)
Yes, the reason being that the OP was asking ab
On Sun, Apr 24, 2016 at 03:00:09PM +0100, Tomas J Stehlik wrote:
> > What happened if you connected to another database in the cluster?
>
> That's irrelevant.
I dare assume Adrian asked for a reason :-)
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537
Hello Adrian,
> So to be clear, all that remains of the database cluster are the files
> you copied out from the data directory, correct?
Yes and no. For the purpose of this discussion, it may be better to say "yes"
though.
> That would imply that the server actually started, is that the case?
On 04/24/2016 03:54 AM, Tomas J Stehlik wrote:
Hello Venkata,
Thank you for your reply.
You are stating the obvious though. If those conditions were met, I would have
formulated my question differently.
So to be clear, all that remains of the database cluster are the files
you copied out fr
Hello Venkata,
Thank you for your reply.
You are stating the obvious though. If those conditions were met, I would have
formulated my question differently.
Kind regards,
Tomas
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http:/
On Sun, Apr 24, 2016 at 2:30 AM, Tomas J Stehlik
wrote:
> Hello,
>
> There was a corruption to the file system due to sudden shutdown of Windows
> 7.
>
> The attempt to connect to one of the databases results in multiple errors,
> like the following one:
> ERROR: invalid page in block 58 of rela
Hello,
There was a corruption to the file system due to sudden shutdown of Windows
7.
The attempt to connect to one of the databases results in multiple errors,
like the following one:
ERROR: invalid page in block 58 of relation base/161326/233745
Several raw files were completely lost (zeroed)
28 matches
Mail list logo
