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
-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
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
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
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
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
-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
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
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
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 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,
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
13 matches
Mail list logo
