On Fri, Dec 20, 2013 at 5:28 AM, Anand Kumar, Karthik
wrote:
> HI,
>
> We have an issue with possibly corrupt data in our postgresql server. Errors
> like:
>
> ERROR: index "photos_p00_n2" contains unexpected zero page at block 0
> ERROR: invalid page header in block 12707 of relation
> pg_tblsp
On Thu, Dec 19, 2013 at 10:07 PM, Laurentius Purba
wrote:
> Hi Greg,
>
> I just wanted to know if you were able successfully upgrading from 9.0 to
> 9.3.
>
> I have been doing this upgrading this past week, but always ended up with
> unsuccessful upgrade.
>
> It will be great if you can share you
14 replies so far, and the OP hasn't chimed in with any feedback as to
what their presumed requirements are based on.
*meh*
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, Dec 20, 2013 at 8:48 AM, Michael Paquier
wrote:
> On Thu, Dec 19, 2013 at 11:18 PM, Chris Travers
> wrote:
>>
>>
>>
>> On Thu, Dec 19, 2013 at 6:52 AM, Wolfgang Keller wrote:
>>>
>>> > 2. With sync replication, you have coordination problems and
>>> > therefore it is never (at least IM
On Thu, Dec 19, 2013 at 11:18 PM, Chris Travers wrote:
>
>
>
> On Thu, Dec 19, 2013 at 6:52 AM, Wolfgang Keller wrote:
>>
>> > 2. With sync replication, you have coordination problems and
>> > therefore it is never (at least IME) a win compared to master-slave
>> > replication since all writes m
On 12/19/2013 01:50 PM, Joseph Kregloh wrote:
On Thu, Dec 19, 2013 at 4:14 PM, John R Pierce mailto:pie...@hogranch.com>> wrote:
On 12/19/2013 1:06 PM, Joseph Kregloh wrote:
It's easier to keep things segregated. It is not anymore
different than doing the upgrade in the same
On Thu, Dec 19, 2013 at 4:18 PM, Bruce Momjian wrote:
> On Thu, Dec 19, 2013 at 01:08:18PM -0800, Sergey Konoplev wrote:
> > On Thu, Dec 19, 2013 at 12:49 PM, Joseph Kregloh
> > wrote:
> > > On Thu, Dec 19, 2013 at 3:46 PM, Sergey Konoplev
> wrote:
> > >> On Thu, Dec 19, 2013 at 12:27 PM, Josep
On Thu, Dec 19, 2013 at 4:16 PM, Adrian Klaver wrote:
> On 12/19/2013 01:06 PM, Joseph Kregloh wrote:
>
>> It's easier to keep things segregated. It is not anymore different than
>> doing the upgrade in the same jail. Which at the end of the day you are
>> doing the upgrade in the same jail, becau
On Thu, Dec 19, 2013 at 4:14 PM, John R Pierce wrote:
> On 12/19/2013 1:06 PM, Joseph Kregloh wrote:
>
>> It's easier to keep things segregated. It is not anymore different than
>> doing the upgrade in the same jail. Which at the end of the day you are
>> doing the upgrade in the same jail, becau
On Thu, Dec 19, 2013 at 1:18 PM, Bruce Momjian wrote:
> On Thu, Dec 19, 2013 at 01:08:18PM -0800, Sergey Konoplev wrote:
>> On Thu, Dec 19, 2013 at 12:49 PM, Joseph Kregloh
>> wrote:
>> > On Thu, Dec 19, 2013 at 3:46 PM, Sergey Konoplev wrote:
>> >> Can you show what ls -l /home/jkregloh/pg_data
HI,
We have an issue with possibly corrupt data in our postgresql server. Errors
like:
ERROR: index "photos_p00_n2" contains unexpected zero page at block 0
ERROR: invalid page header in block 12707 of relation
pg_tblspc/5020557/PG_9.1_201105231/16393/9014673
Thanks to all the suggestions fr
On Thu, Dec 19, 2013 at 01:14:15PM -0800, John R Pierce wrote:
> On 12/19/2013 1:06 PM, Joseph Kregloh wrote:
> >It's easier to keep things segregated. It is not anymore different
> >than doing the upgrade in the same jail. Which at the end of the
> >day you are doing the upgrade in the same jail,
Hi Jerry,
Thanks for the suggestion
Yes, until about a month ago, we weren't wrapping our snapshots with
pg_start_backup and pg_stop_backup. Same reason as you mentioned, the
database would start up and "trivial checks" would be okay, and so we
figured "why write a script?".
However we did chang
On Thu, Dec 19, 2013 at 01:08:18PM -0800, Sergey Konoplev wrote:
> On Thu, Dec 19, 2013 at 12:49 PM, Joseph Kregloh
> wrote:
> > On Thu, Dec 19, 2013 at 3:46 PM, Sergey Konoplev wrote:
> >> On Thu, Dec 19, 2013 at 12:27 PM, Joseph Kregloh
> >> wrote:
> >> > So what I get from this is that it doe
On 12/19/2013 01:06 PM, Joseph Kregloh wrote:
It's easier to keep things segregated. It is not anymore different than
doing the upgrade in the same jail. Which at the end of the day you are
doing the upgrade in the same jail, because at the end of the day
pg_upgrade just needs the old data an bin
On 12/19/2013 1:06 PM, Joseph Kregloh wrote:
It's easier to keep things segregated. It is not anymore different
than doing the upgrade in the same jail. Which at the end of the day
you are doing the upgrade in the same jail, because at the end of the
day pg_upgrade just needs the old data an bi
On Thu, Dec 19, 2013 at 12:49 PM, Joseph Kregloh
wrote:
> On Thu, Dec 19, 2013 at 3:46 PM, Sergey Konoplev wrote:
>> On Thu, Dec 19, 2013 at 12:27 PM, Joseph Kregloh
>> wrote:
>> > So what I get from this is that it does create the correct 9.3 files in
>> > the
>> > new location, however it cann
It's easier to keep things segregated. It is not anymore different than
doing the upgrade in the same jail. Which at the end of the day you are
doing the upgrade in the same jail, because at the end of the day
pg_upgrade just needs the old data an binary to start and create some dump
files.
But th
On 12/19/2013 12:53 PM, Bruce Momjian wrote:
Currently I am testing on the development database which is only 100GB with a
>same number of tablespaces. I am working on FreeBSD with jails. So one jail
>contains 9.0 and the other 9.3. In the 93 jail I mount the data and binary
>directories for the
On Thu, Dec 19, 2013 at 11:34:24AM -0500, Joseph Kregloh wrote:
> Hello,
>
> I am trying to upgrade from 9.0.14 to 9.3. I am using the pg_upgrade utility.
> I
> need to use pg_upgrade because my production database is 800GB+ and with over
> 80 tablespaces and doing an export from 9.0 and importin
Within the jail it would be:
[pgsql@postgres-93-upgrade ~]$ mount
sata-data/usr/jails/postgres-93-upgrade on / (zfs, local, nfsv4acls)
But I am mounting those directories from the host, which will be:
[root@v1 /postgres_data/p3-dev-db-93]# mount -l | grep postgres-93-upgrade
sata-data/usr/jails/po
[pgsql@postgres-93-upgrade ~]$ ls -l /home/jkregloh/pg_data/data/pg_tblspc/
lrwxr-xr-x 1 pgsql pgsql41 Dec 19 19:53 11047389 ->
/home/jkregloh/pg_data/data/stats_dbspace
lrwxr-xr-x 1 pgsql pgsql44 Dec 19 19:53 11047390 ->
/home/jkregloh/pg_data/data/stats_indexspace
lrwxr-xr-x
On 12/19/2013 12:46 PM, Joseph Kregloh wrote:
I'm not sure what you mean by that question.
When you run the mount command in the jail what does it show?
-Joseph
--
Adrian Klaver
adrian.kla...@gmail.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make chang
On Thu, Dec 19, 2013 at 12:27 PM, Joseph Kregloh
wrote:
> So what I get from this is that it does create the correct 9.3 files in the
> new location, however it cannot copy the relation over because the old data
> is in the /home/jkregloh/pg_data/data/drupal_dbspace/ not in
> /usr/local/pgsql/data
I'm not sure what you mean by that question.
-Joseph
On Thu, Dec 19, 2013 at 3:41 PM, Adrian Klaver wrote:
> On 12/19/2013 12:27 PM, Joseph Kregloh wrote:
>
>> Here is the output of my last test run:
>>
>>
>
>> So what I get from this is that it does create the correct 9.3 files in
>> the new l
"Anand Kumar, Karthik" writes:
> Thanks Shaun!
>
> Yes, we're getting synchronous_commit on right now.
>
> The log_min_duration was briefly set to 0 at the time I sent out the post,
> just to see what statements were logged right before everything went to
> hell. Didn't yield much since we very q
On 12/19/2013 12:27 PM, Joseph Kregloh wrote:
Here is the output of my last test run:
So what I get from this is that it does create the correct 9.3 files in
the new location, however it cannot copy the relation over because the
old data is in the /home/jkregloh/pg_data/data/drupal_dbspace/
Here is the output of my last test run:
[pgsql@postgres-93-upgrade ~]$ time pg_upgrade -b /home/jkregloh/pg_bin/ -B
/usr/local/bin/ -d /home/jkregloh/pg_data/data -D /usr/local/pgsql/data/ -p
5452 -P 5451
Performing Consistency Checks
-
Checking cluster versions
Thanks Shaun!
Yes, we're getting synchronous_commit on right now.
The log_min_duration was briefly set to 0 at the time I sent out the post,
just to see what statements were logged right before everything went to
hell. Didn't yield much since we very quickly realized we couldn't cope
with the vol
On 12/19/2013 12:42 PM, Anand Kumar, Karthik wrote:
> ERROR: index "mv_visits_p03_n2" contains unexpected zero page at block
> 15939
> ERROR: invalid page header in block 344713 of relation
> pg_tblspc/4376157/PG_9.1_201105231/16393/8367465
I don't care what kind of checks your admins have perf
Hi,
We're looking for help with possible corruption of our indexes and tables.
Seemingly in the middle of normal operations, we will run into errors like
the below:
ERROR: index "mv_visits_p03_n2" contains unexpected zero page at block
15939
ERROR: invalid page header in block 344713 of relati
Hi, did you find a resolution to this issue? I'm running into the same
problem now!
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/After-dump-restoring-from-32bit-8-4-windows-to-64bit-9-2-4-linux-experiencing-10x-slowdown-on-queries-tp5751526p5784087.html
Sent from the
Yes, the port numbers are correct. Both instances start by themselves on
their own jails.
On Thu, Dec 19, 2013 at 11:52 AM, Adrian Klaver wrote:
> On 12/19/2013 08:34 AM, Joseph Kregloh wrote:
>
>> Hello,
>>
>> I am trying to upgrade from 9.0.14 to 9.3. I am using the pg_upgrade
>> utility. I ne
On 13-12-19 11:34 AM, Joseph Kregloh wrote:
Hello,
I am trying to upgrade from 9.0.14 to 9.3. I am using the pg_upgrade
utility. I need to use pg_upgrade because my production database is
800GB+ and with over 80 tablespaces and doing an export from 9.0 and
importing to 9.3 would take at least
On 12/19/2013 08:34 AM, Joseph Kregloh wrote:
Hello,
I am trying to upgrade from 9.0.14 to 9.3. I am using the pg_upgrade
utility. I need to use pg_upgrade because my production database is
800GB+ and with over 80 tablespaces and doing an export from 9.0 and
importing to 9.3 would take at least
Hello,
I am trying to upgrade from 9.0.14 to 9.3. I am using the pg_upgrade
utility. I need to use pg_upgrade because my production database is 800GB+
and with over 80 tablespaces and doing an export from 9.0 and importing to
9.3 would take at least 2 days.
Currently I am testing on the developme
On 12/18/2013 09:36 PM, Bob Futrelle wrote:
I uninstalled 9.2 before installing 9.3.1.0.
The app is called Postgres93, it is version 9.3.1.0
I downloaded the latest pgAdmin, it is pgAdmin3 version 1.18.1
I have a database "MiniServer" which is supposed to use postgres
as its Maintenance databas
On Thu, Dec 19, 2013 at 1:27 AM, wd wrote:
>
> On Thu, Dec 19, 2013 at 2:24 PM, Amit Langote wrote:
>
>> "unexpected pageaddr" log entry in this case means the standby reached
>> the end of existing WAL.
>> So, just before connecting to walsender for streaming replication, it
>> logs this.
>>
>
>
On Thu, Dec 19, 2013 at 6:52 AM, Wolfgang Keller wrote:
> > 2. With sync replication, you have coordination problems and
> > therefore it is never (at least IME) a win compared to master-slave
> > replication since all writes must occur in the same order in the set,
> > or you need global sequen
> 2. With sync replication, you have coordination problems and
> therefore it is never (at least IME) a win compared to master-slave
> replication since all writes must occur in the same order in the set,
> or you need global sequences, or such.
*snip*
> You will never get better read or writ
Hi Greg,
I just wanted to know if you were able successfully upgrading from 9.0 to
9.3.
I have been doing this upgrading this past week, but always ended up with
unsuccessful upgrade.
It will be great if you can share you knowledge on this.
Thanks!
-Laurent
On Thu, Nov 7, 2013 at 2:07 PM, Gre
Am 19.Dez. 2013 um 09:41 schrieb Andreas Kretschmer :
> hello all,
>
> don't ask why, but a customer created tables with foreign key constraints but
> with inconsistent data.
>
> Because of this he disabled all triggers (alter table foo disable trigger
> all).
> So far, so bad ...
> (he can't
On Thu, Dec 19, 2013 at 2:24 PM, Amit Langote wrote:
> "unexpected pageaddr" log entry in this case means the standby reached
> the end of existing WAL.
> So, just before connecting to walsender for streaming replication, it logs
> this.
>
Thanks for your reply. So this means I can safely omit t
hello all,
don't ask why, but a customer created tables with foreign key constraints but
with inconsistent data.
Because of this he disabled all triggers (alter table foo disable trigger all).
So far, so bad ...
(he can't clean the data at the moment)
In the dump there are the constraints, but
44 matches
Mail list logo
