2014-12-04 17:31 GMT-06:00 Adrian Klaver :
> On 12/04/2014 03:11 PM, Carlos Carcamo wrote:
>>
>> 2014-12-04 16:46 GMT-06:00 David G Johnston :
>>>
>>> Carlos Carcamo wrote
I read about oGlenrder of execution of triggers, is supposed that postgres
executes triggers in alphabetical ord
On 12/04/2014 03:11 PM, Carlos Carcamo wrote:
2014-12-04 16:46 GMT-06:00 David G Johnston :
Carlos Carcamo wrote
I read about order of execution of triggers, is supposed that postgres
executes triggers in alphabetical order, so I called the plpgsql
a_trigger and the second one b_trigger (as an
On 12/4/2014 6:11 PM, Carlos Carcamo wrote:
Yes because my update_remote.sh file calls a php file to update a
table in mysql, and it is updated after I perform another query to
in_kardex, so the mysql table is one query behind postgres... Any
thoughts?
My bet is that the query run from your
2014-12-04 16:46 GMT-06:00 David G Johnston :
> Carlos Carcamo wrote
>> I read about order of execution of triggers, is supposed that postgres
>> executes triggers in alphabetical order, so I called the plpgsql
>> a_trigger and the second one b_trigger (as an example), but it seems
>> that the seco
Carlos Carcamo wrote
> I read about order of execution of triggers, is supposed that postgres
> executes triggers in alphabetical order, so I called the plpgsql
> a_trigger and the second one b_trigger (as an example), but it seems
> that the second one always executes first.
>
> Is there any way
Hello list, hope you're well.
I need some help with postgres.
I have two triggers that are executed after insert, update and delete.
One trigger is with plpgsql language and the other one is with
pl/python, the first one just update some tables and last one calls a
*.sh that is executed to perfor
On Thu, Dec 4, 2014 at 9:02 AM, Mike Blackwell
wrote:
> check_postgres.pl (--action=autovac_freeze) recently complained that we
> needed to run VACUUM FREEZE. Doing so generated a boatload of WAL files -
> perhaps on the order of the of the database itself.
>
> Is VACUUM FREEZE something that is
On Thu, Dec 4, 2014 at 12:02 PM, Mike Blackwell wrote:
> check_postgres.pl (--action=autovac_freeze) recently complained that we
> needed to run VACUUM FREEZE. Doing so generated a boatload of WAL files -
> perhaps on the order of the of the database itself.
>
> Is VACUUM FREEZE something that is
I don't think autovacuum can predict you will not update your table(s)
anymore, so there's no way to know to run FREEZE on it.
On Thu, Dec 4, 2014 at 12:02 PM, Mike Blackwell
wrote:
> check_postgres.pl (--action=autovac_freeze) recently complained that we
> needed to run VACUUM FREEZE. Doing so
check_postgres.pl (--action=autovac_freeze) recently complained that we
needed to run VACUUM FREEZE. Doing so generated a boatload of WAL files -
perhaps on the order of the of the database itself.
Is VACUUM FREEZE something that is normally handled by autovac? If so, how
would we approach findi
"Day, David" writes:
> It is very likely that the date of the core was 'touched' to make the rebuilt
> Postgres binary with symbols play nice with gdb.
> Apparently, that was not a great idea based on your comments.
Oh, so you rebuilt with debug enabled and then retrospectively tried to
use that
Tom,
Thanks very much for the feedback.
It is very likely that the date of the core was 'touched' to make the rebuilt
Postgres binary with symbols play nice with gdb.
Apparently, that was not a great idea based on your comments.
In any case we are better prepared to analyze it on the next insta
On 12/04/2014 02:01 AM, Eric Svenson wrote:
So what if you load to the VM Postgres using the psql from the host?
I tried that: On the host I started psql with
psql -h 192.168.2.55 -U postgres -p 5432 my_Database < myFile.sql
I get the same error
ERROR: invalid input syntax for type double pre
On 12/04/2014 03:08 AM, M Tarkeshwar Rao wrote:
Hi,
We performed the following actions to recover
1. Restart the DB
2. Rebuild the index
3. Vacume the index
mgrdb=# select count(*) from mm_activealarm;
ERROR: missing chunk number 0 for toast value 54787 in pg_toast_2619
mgrdb=# REINDEX table p
On 12/03/2014 09:30 PM, M Tarkeshwar Rao wrote:
Hi Adrian,
Thanks Adrian for you quick reply. I am looking in this that why db came into
this stage.
--I have found overheating servers to be particularly prone to index corruption
and if indexes can get corrupt one has to worry about data becom
I tried that when I was testing .. if I stopped at the most recent
insert/update/delete previous to the drop database (with telling it to
include the change) it DIDN'T include the change (I assume because the
commit timestamp was slightly after the transaction timestamp) .. and if I
told it to stop
> So what if you load to the VM Postgres using the psql from the host?
I tried that: On the host I started psql with
psql -h 192.168.2.55 -U postgres -p 5432 my_Database < myFile.sql
I get the same error
ERROR: invalid input syntax for type double precision "0.2"
KONTEXT: COPY dev_my_settings, l
Hi all,
Finally DB was restored from the backup and the issue was solved.
Is the data corrupted?
I feel that data is corrupted as well as its some of the data dictionary also
corrupted.
That is the reason it is not displaying any columns for the table even the
table is present.
Regards
Tarke
Hi,
We performed the following actions to recover
1. Restart the DB
2. Rebuild the index
3. Vacume the index
mgrdb=# select count(*) from mm_activealarm;
ERROR: missing chunk number 0 for toast value 54787 in pg_toast_2619
mgrdb=# REINDEX table pg_toast.pg_toast_2619;
REINDEX
mgrdb=# VACUUM ANAL
19 matches
Mail list logo
