Hello,
We currently use psotgres 9.3 in our products. Recently we upgraded to
postgres 9.6. But with 9.6 we have seen a drastic reduction in throughput.
After analyzing carefully I found that "planner time" in 9.6 is very high.
Below are the details:
Scenario:
1 Create a table with 10 rows.
2
Hi,
Recently we observed below errors while taking dump after upgrading from
9.0.13 to 9.1.9.
pg_dump: schema with OID 0 does not exist
I referred similar issues reported previously (
http://www.postgresql.org/message-id/CAGWYGjXRJj=zugejv0ckvn4zf9hb92q+7e3aqfcvbgbmb9z...@mail.gmail.com)
and get
Hi,
Can someone confirm is this really an issue? or any reasons for missing
rows?
On Tue, Feb 25, 2014 at 3:51 PM, Prakash Itnal wrote:
> Hi,
>
> Recently we observed below errors while taking dump after upgrading from
> 9.0.13 to 9.1.9.
>
> pg_dump: schema with OID 0 do
Hi,
Recently we faced an issue with postgres server where it is throwing error:
ERROR: catalog is missing 2 attribute(s) for relid 16584
CONTEXT: automatic analyze of table "DBRNW.public.act_wsta"
I checked in the database and found that this table is not present but the
entry for the same is
Hi,
I have create the following tables:
1. rnc table
CREATE TABLE act_rnc(rnc_id integer NOT NULL PRIMARY KEY, rnc_data BYTEA);
2. rncgen table
CREATE TABLE act_rncgen(rnc_id integer NOT NULL PRIMARY KEY, rncsubObj_Cnt
integer, rncgen_data BYTEA);
3. iuo table which has a foreign key reference to
Hello,
Recently we encountered a issue where the disc space is continuously
increasing towards 100%. Then a manual vacuum freed the disc space. But
again it is increasing. When digged more it is found that auto-vacuuming
was not running or it is either stucked/hanged.
Version: 9.1.12
Auto vacuum
I suspect the time change is the root cause! It would be great if
someone can clarify if this is the root cause for auto-vacuum stopped.
On Wed, Jun 10, 2015 at 8:19 PM, Alvaro Herrera
wrote:
> Prakash Itnal wrote:
> > Hello,
> >
> > Recently we encountered a issue wh
-vacuuming stops working. Even after changing system time back
to current time, the auto-vacuuming did not resume.
So the question is, "does postrges supports system time changes?".
On Tue, Jun 16, 2015 at 10:12 AM, Prakash Itnal
wrote:
> Hi,
>
> @Avaro Herrera, Thanks for qu
Hi,
Currently we observed that certain postgres child process, for eg.
autovacuum worker, are not working as expected if there is a system time
change. So I wanted to know if postgres already supports system time
changes or not.
Please confirm if postgres already handles system time changes or no
Hi,
Sorry for the late response. The current patch only fixes the scenario-1
listed below. It will not address the scenario-2. Also we need a fix in
unix_latch.c where the remaining sleep time is evaluated, if latch is woken
by other events (or result=0). Here to it is possible the latch might go
o timeout) then above logic is not applicable.
On Sat, Jun 20, 2015 at 10:01 PM, Tom Lane wrote:
> Prakash Itnal writes:
> > Sorry for the late response. The current patch only fixes the scenario-1
> > listed below. It will not address the scenario-2. Also we need a fix in
&g
e patch in other
mail chain. Please check and share your inputs.
For quick reference please find the scenarios below:
On Mon, Jun 22, 2015 at 8:02 AM, Craig Ringer wrote:
> On 17 June 2015 at 15:36, Prakash Itnal wrote:
> > Hi,
> >
> > Currently we observed that certain
-half-day -> corrected to current_time (2015)
*Scenario-2:* current_time (2015) -> changed_to_future (2020) ->
stays-here-for-half-day -> corrected to current_time (2015)
We are waiting for your response.
On Sun, Jun 21, 2015 at 2:56 PM, Prakash Itnal wrote:
> Hi,
>
> To my understan
13 matches
Mail list logo