Re: [GENERAL] PostgreSQL advocacy

[Jernigan, Kevin]

On 3/22/16, 8:07 AM, "Bruce Momjian"  wrote:



>On Mon, Mar 21, 2016 at 04:46:51PM +, Jernigan, Kevin wrote:
>> Disk is only a single point of failure in RAC if you configure
>> non-redundant storage. In general, Oracle recommends triple mirroring
>> to protect against disk failures, as they have had many experiences
>> over the years where customers with mirrored disks would see
>> consecutive disk failures within short periods of time.
>>
>> And RAC is widely used by Oracle’s larger customers, not only
>> for HA, but also in some cases for scale-out. Having said that,
>> it’s very true that any application running on Oracle RAC must be
>> configured to avoid hot block contention across RAC nodes, so it’s
>> not a completely transparent solution for scale out.
>
>I get asked about Oracle RAC often.  My usual answer is that Oracle RAC
>gives you 50% of high reliability (storage is shared, mirroring helps)
>and 50% of scaling (CPU/memory is scaled, storage is not).  The
>requirement to partition applications to specific nodes to avoid cache
>consistency overhead is another downside.  (Slide 24 of my scaling
>presentation shows Oracle RAC,
>http://momjian.us/main/writings/pgsql/scaling.pdf .)
>
>I said the community is unlikely to go the Oracle RAC direction because
>it doesn't fully solve a single problem, and it is overly complex.  The
>community prefers fully-solved problems and simpler solutions.
>
>For me, streaming replication fully solves the high reliability problem
>and sharding fully solves the scaling problem.  Of course, if you need
>both, you have to deploy both, which gives you 100% of two solutions,
>rather than Oracle RAC which gives you 50% of each.  
>
>However, I do think database upgrades are easier with Oracle RAC, and I
>think it is much easier to add/remove nodes than with sharding.  For me,
>this chart summarizes it:
>
> HA   Scaling  Upgrade Add/Remove
>Oracle RAC   50% 50%easyeasy
>Streaming Rep.  100% 25%*   hardeasy
>Sharding  0%100%hardhard
>
>* Allows read scaling
>
>-- 
>  Bruce Momjian  http://momjian.us
>  EnterpriseDB http://enterprisedb.com
>
>+ As you are, so once was I. As I am, so you will be. +
>+ Roman grave inscription +

Implementing RAC-equivalent functionality is extremely hard, as evidenced by 
the lack of any directly comparable capability from any other relational db 
engine, until the release of IBM DB2 Shareplex a few years ago. And given the 
improvement of PostgreSQL and other open source solutions over the past 20 
years, it’s not clear that it makes sense to go through the initial design and 
implementation work and then the ongoing maintenance overhead - most of what 
RAC provides can be achieved through other existing capabilities. 

While I’m not sure that the percentage breakdowns in your chart are totally 
accurate, I agree with the general assessment, except for the highest-end 
applications which have zero-downtime requirements which can’t be met with 
streaming replication: the overhead of synchronous replication limits 
scalability, and the failover time for moving from primary to a failover target 
is significantly slower than RAC - which can be literally zero if configured 
correctly.

The higher-level point that I think is important is that while I may be able to 
win technical arguments that RAC is better for certain high-end extreme 
workloads - and maybe I can’t even win those arguments ;-) - the real issue is 
that there aren’t very many of those workloads, and the PostgreSQL community 
shouldn’t care: the vast majority of Oracle (and SQL Server etc) workloads 
don’t need all the fancy high-end RAC capabilities, or many of the other 
high-end commercial database capabilities. And those workloads can relatively 
easily be migrated to PostgreSQL, with minor disruption / change to schemas, 
data, triggers, constraints, procedural SQL…

-KJ

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PostgreSQL advocacy

[Jernigan, Kevin]

On 3/24/16, 3:09 PM, "Albe Laurenz"  wrote:


>Jernigan, Kevin wrote:
>> Disk is only a single point of failure in RAC if you configure non-redundant 
>> storage.
>> In general, Oracle recommends triple mirroring to protect against disk 
>> failures,
>> as they have had many experiences over the years where customers with 
>> mirrored disks
>> would see consecutive disk failures within short periods of time.
>
>The single point of failure in Oracle RAC is the ASM file system.
>
>Yours,
>Laurenz Albe

Only if you misconfigure ASM for RAC: with RAC, an ASM instance will run on 
every RAC node, and if the ASM instance fails on any one node, the RAC instance 
on that node will go down, but the RAC instances on the other nodes will 
continue to run - so the database will remain accessible, though with fewer 
processors available.

If you configure ASM to implement at least dual mirroring for storage - and I’m 
pretty sure Oracle intentionally makes it hard to configure ASM without 
mirroring - then ASM will continue run through any single disk failure.

-KJ

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PostgreSQL advocacy

[Albe Laurenz]

Jernigan, Kevin wrote:
> Disk is only a single point of failure in RAC if you configure non-redundant 
> storage.
> In general, Oracle recommends triple mirroring to protect against disk 
> failures,
> as they have had many experiences over the years where customers with 
> mirrored disks
> would see consecutive disk failures within short periods of time.

The single point of failure in Oracle RAC is the ASM file system.

Yours,
Laurenz Albe

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Multixacts wraparound monitoring

[Alvaro Herrera]

Pavlov, Vladimir wrote:
> There is nothing:
> select * from pg_prepared_xacts;
>  transaction | gid | prepared | owner | database
> -+-+--+---+--
> (0 rows)
> It is also noticed that a lot of files in a directory 
> main/pg_multixact/members/, now - 69640.

Can you attach pg_controldata output?

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Multixacts wraparound monitoring

[Pavlov, Vladimir]

There is nothing:
select * from pg_prepared_xacts;
 transaction | gid | prepared | owner | database
-+-+--+---+--
(0 rows)
It is also noticed that a lot of files in a directory 
main/pg_multixact/members/, now - 69640.

Kind regards,
 
Vladimir Pavlov


-Original Message-
From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com] 
Sent: Thursday, March 24, 2016 9:03 PM
To: Pavlov Vladimir
Cc: 'Adrian Klaver'; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Multixacts wraparound monitoring

Pavlov, Vladimir wrote:
> Thanks for your reply.
> Yes, the first thing I looked at the statistics from pg_stat_activity.
> But I have a transaction is not more than 60 seconds and the condition 'idle 
> in transaction' lasts only a few seconds.

Maybe you have a prepared transaction?  See select * from pg_prepared_xacts;


-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Way to get at parsed trigger 'WHEN' clause expression?

[James Robinson]

Folks,

I see that psql's \d displays trigger information of a table by making 
a call to pg_catalog.pg_get_triggerdef(), which abstracts away most all need to 
parse the contents of system catalog pg_trigger. However, we'd like to be able 
to get at a human readable representation of just the WHEN clause of the 
trigger expression. Function pg_get_expr() looked likely, but fails when fed a 
pgqual value from pg_trigger ala:

ERROR: bogus varno: 2 

I suspect that it is falling over dead trying to parse the 
representation of NEW and / or OLD. Anything built in, or should we just make 
call to pg_catalog.pg_get_triggerdef() and parse out the WHEN clause text?

Thanks!
--
James Robinson
Socialserve.com by Emphasys Software





-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Uninstalled working db by mistake

[Howard News]

On 24/03/2016 17:52, David Wilson wrote:
Per the heading printed by dpkg --list, this means the package is in 
the removed state, but it's config files are still present. "apt-get 
install postgresql-9.0" should be all required. David


David,

I owe you a beer. Nay - several drinks of your choice.

Howard.



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Multixacts wraparound monitoring

[Alvaro Herrera]

Pavlov, Vladimir wrote:
> Thanks for your reply.
> Yes, the first thing I looked at the statistics from pg_stat_activity.
> But I have a transaction is not more than 60 seconds and the condition 'idle 
> in transaction' lasts only a few seconds.

Maybe you have a prepared transaction?  See
select * from pg_prepared_xacts;


-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Uninstalled working db by mistake

[David Wilson]

On Thu, Mar 24, 2016 at 05:44:27PM +, Howard News wrote:
> Thanks David,
> 
> Unfortunately my cluster wont start - I am not entirely sure on the state of
> postgresql-9.0, this is the output from dpkd --list
> 
> 
> 
> rc  postgresql-9.0 9.0.4-1~lucid1 object-relational SQL database, version
> 9.0

Per the heading printed by dpkg --list, this means the package is in the
removed state, but it's config files are still present. "apt-get install
postgresql-9.0" should be all required.


David


> ii  postgresql-9.1 9.1.20-1.pgdg1 object-relational SQL database, version
> 9.1
> ii  postgresql-9.2 9.2.15-1.pgdg1 object-relational SQL database, version
> 9.2
> 
> Does this mean it is removed?
> 
> On 24/03/2016 17:34, David Wilson wrote:
> >Hi Howard,
> >
> >So long as you haven't touched anything else, simply reinstalling the
> >package should restore your cluster. Debian packages only do
> >initialization if the data directories are missing.
> >
> >
> >David
> >
> >On Thu, Mar 24, 2016 at 05:29:23PM +, Howard News wrote:
> >>Hi,
> >>
> >>I uninstalled the wrong version of postgres on Ubuntu using apt-get remove
> >>postgresql-9.0, convinced that this was an old unused version. You guess the
> >>rest...
> >>
> >>The data files still appear to be there, all 485GB of them. Can these be
> >>restored?
> >>
> >>Thanks.
> >
> 
> 
> 
> -- 
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Uninstalled working db by mistake

[Howard News]

Thanks David,

Unfortunately my cluster wont start - I am not entirely sure on the 
state of  postgresql-9.0, this is the output from dpkd --list




rc  postgresql-8.4 8.4.6-0ubuntu1 object-relational SQL database, 
version 8.4
rc  postgresql-9.0 9.0.4-1~lucid1 object-relational SQL database, 
version 9.0
ii  postgresql-9.1 9.1.20-1.pgdg1 object-relational SQL database, 
version 9.1
ii  postgresql-9.2 9.2.15-1.pgdg1 object-relational SQL database, 
version 9.2


Does this mean it is removed?

On 24/03/2016 17:34, David Wilson wrote:

Hi Howard,

So long as you haven't touched anything else, simply reinstalling the
package should restore your cluster. Debian packages only do
initialization if the data directories are missing.


David

On Thu, Mar 24, 2016 at 05:29:23PM +, Howard News wrote:

Hi,

I uninstalled the wrong version of postgres on Ubuntu using apt-get remove
postgresql-9.0, convinced that this was an old unused version. You guess the
rest...

The data files still appear to be there, all 485GB of them. Can these be
restored?

Thanks.






--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Uninstalled working db by mistake

[Karsten Hilbert]

On Thu, Mar 24, 2016 at 05:34:21PM +, David Wilson wrote:

> So long as you haven't touched anything else, simply reinstalling the
> package should restore your cluster. Debian packages only do
> initialization if the data directories are missing.

Just for good measure I would strongly suggest taking a full
file level copy of the datadir before reinstalling the package.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Uninstalled working db by mistake

[David Wilson]

Hi Howard,

So long as you haven't touched anything else, simply reinstalling the
package should restore your cluster. Debian packages only do
initialization if the data directories are missing.


David

On Thu, Mar 24, 2016 at 05:29:23PM +, Howard News wrote:
> Hi,
> 
> I uninstalled the wrong version of postgres on Ubuntu using apt-get remove
> postgresql-9.0, convinced that this was an old unused version. You guess the
> rest...
> 
> The data files still appear to be there, all 485GB of them. Can these be
> restored?
> 
> Thanks.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Uninstalled working db by mistake

[Howard News]

Hi,

I uninstalled the wrong version of postgres on Ubuntu using apt-get 
remove postgresql-9.0, convinced that this was an old unused version. 
You guess the rest...


The data files still appear to be there, all 485GB of them. Can these be 
restored?


Thanks.

Re: [GENERAL] Multixacts wraparound monitoring

[Pavlov, Vladimir]

Thanks for your reply.
Yes, the first thing I looked at the statistics from pg_stat_activity.
But I have a transaction is not more than 60 seconds and the condition 'idle in 
transaction' lasts only a few seconds.

Kind regards,
 
Vladimir Pavlov

-Original Message-
From: Adrian Klaver [mailto:adrian.kla...@aklaver.com] 
Sent: Thursday, March 24, 2016 4:36 PM
To: Pavlov Vladimir; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Multixacts wraparound monitoring

On 03/24/2016 12:54 AM, Pavlov, Vladimir wrote:
> Hello,
>
> How can we determine when an error of approximation multixacts wraparound?
>
> According to the information from pg_class:
>
> select datname,datminmxid from pg_database;
>
>  datname | datminmxid
>
> +
>
> template1  |  347462426
>
> template0  |  347462426
>
> postgres  |  347462426
>
> zabbix |  467261307
>
> db_3|  291141939
>
> db_1   |  388282963
>
> db|  388282963
>
> But when the vacuum/autovacuum starts up, an error occurs:
>
> WARNING:  oldest multixact is far in the past
>
> HINT:  Close open transactions with multixacts soon to avoid 
> wraparound problems.

The above would seem to be the key. Take a look at what is in:

select * from pg_stat_activity;

You are looking for long running queries and/or 'idle in transaction' 
queries'.

For more information see:

http://www.postgresql.org/docs/9.3/static/monitoring-stats.html#PG-STAT-ACTIVITY-VIEW

>
> If I understand correctly, approaching Multixact member wraparound.
>
> But how to understand when it comes exactly and what to do?
>
> PostgreSQL version - 9.3.10, OS Debian 7.8.
>
> Thank you.
>
> Sorry, if I chose the wrong mailing list.
>
> Kind regards,
>
> *Vladimir Pavlov*
>


--
Adrian Klaver
adrian.kla...@aklaver.com


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Only owners can ANALYZE tables...seems overly restrictive

[David G. Johnston]

On Thu, Mar 24, 2016 at 4:51 AM, Stephen Frost  wrote:

> David,
>
> * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > Which means that, aside from effort, the main blocking factors here are
> > code complexity (which I understand) and limited grant "bits" as Stephen
> > puts it.  So I pose the question: do any of the committers consider a
> grant
> > bit too valuable to consume on an ANALYZE grant?
>
> I wasn't referring to "bits" as "things" to do but rather as actual
> zeros and ones- AclMode is a 32bit integer, of which the bottom half are
> 'regular' grantable rights and the top half are "with grant option"
> indications, meanly we've only got 16 to work with, and every object
> uses AclMode, so we have to support *all* kinds of GRANTs with those 16
> bits.
>

​Yes, that is how I understood "bits"...sorry for the poor phrasing.​


> See src/include/nodes/parsenodes.h, around line 63.
>
> > If that and/or general code complexity means this will not be added even
> if
> > a patch was proposed for 9.7 then I'll move on and institute one of the
> > hacks that has been proffered.  Otherwise I have (more than) half a mind
> to
> > find some way to get a patch written.
>
> I don't see any reason why the patch itself would be terribly difficult,
> but are we sure we'd want just ANALYZE and not VACUUM also?  Which would
> have to be another bit, since those are pretty different actions.
>
>
In the limited experience that​ prompted this requested the benefit of
performing a VACUUM is significantly less than the benefit of performing
ANALYZE, and the cost of the former is considerably higher.  I'm quite
content to leave VACUUM decisions to the auto-vacuum process which balances
the benefit of removing bloat with the I/O cost of doing so.

The question really is- what other things might we want as grantable
> rights in the future?  Once these 16 bits are gone, it's a whole bunch
> of work to get more.
>

If I am reading parsenodes.h correctly we presently use only 12 of 16 bits
and those that are present all seem ancient.  With no other existing need
to add a single additional grantable option, let alone 4, I'm not see this
as being particularly concerning.

Let someone else argue for inclusion of VACUUM before considering adding it
- all I believe that we need is ANALYZE.  I want programs doing ETL to be
able to get the system into "good-enough" shape to be functional;
maintenance processes can deal with the rest.

David J.

[GENERAL] Foreign key referencing a VIEW

[Laurent Martelli]

Hi all,

I have a feature request for our dear fellow developpers : I would like to
be able to create a foreign key constraint that references a view (or
anything that looks like a table, as a function returning a table for
instance) instead of a table.

Does that look doable ? The trickiest part is probably to ensure the
constraint when the tables the view is built on are modified...

Cheers,
Laurent

-- 
http://www.laurentmartelli.com//http://www.imprimart.fr

Re: [GENERAL] Partitioning and ORM tools

[CS DBA]

On 03/23/2016 02:48 AM, Chris Travers wrote:



On Wed, Mar 23, 2016 at 9:39 AM, Chris Travers 
> wrote:


Use a view with a DO INSTEAD trigger. That will allow you to
return the tuple properly.

On Tue, Mar 22, 2016 at 7:40 PM, CS DBA
>
wrote:

Hi All;

we setup partitioning for a large table but had to back off
because the return status (i.e: "INSERT 0 1") returns "INSERT
0 0" when inserting into the partitioned table which causes
the ORM tool to assume the insert inserted 0 rows.  Is there a
standard / best practices work around for this?


Apologies for the top post above.

Just noting additionally that the view with DO INSTEAD approach was 
suggested to me by Matt Trout (major contributor to the DBIx::Class 
ORM in Perl.


I have used it.  It works well.  I think it is the best practice there.


Thanks in advance




-- 
Sent via pgsql-general mailing list

(pgsql-general@postgresql.org
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general




-- 
Best Wishes,

Chris Travers

Efficito:  Hosted Accounting and ERP. Robust and Flexible.  No
vendor lock-in.
http://www.efficito.com/learn_more




--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor 
lock-in.

http://www.efficito.com/learn_more


All;

Thanks for the great Ideas, I'll let you know where we end up.

Re: [GENERAL] Multixacts wraparound monitoring

[Adrian Klaver]

On 03/24/2016 12:54 AM, Pavlov, Vladimir wrote:

Hello,

How can we determine when an error of approximation multixacts wraparound?

According to the information from pg_class:

select datname,datminmxid from pg_database;

 datname | datminmxid

+

template1  |  347462426

template0  |  347462426

postgres  |  347462426

zabbix |  467261307

db_3|  291141939

db_1   |  388282963

db|  388282963

But when the vacuum/autovacuum starts up, an error occurs:

WARNING:  oldest multixact is far in the past

HINT:  Close open transactions with multixacts soon to avoid wraparound
problems.


The above would seem to be the key. Take a look at what is in:

select * from pg_stat_activity;

You are looking for long running queries and/or 'idle in transaction' 
queries'.


For more information see:

http://www.postgresql.org/docs/9.3/static/monitoring-stats.html#PG-STAT-ACTIVITY-VIEW



If I understand correctly, approaching Multixact member wraparound.

But how to understand when it comes exactly and what to do?

PostgreSQL version – 9.3.10, OS Debian 7.8.

Thank you.

Sorry, if I chose the wrong mailing list.

Kind regards,

*Vladimir Pavlov*




--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Only owners can ANALYZE tables...seems overly restrictive

[Stephen Frost]

David,

* David G. Johnston (david.g.johns...@gmail.com) wrote:
> Which means that, aside from effort, the main blocking factors here are
> code complexity (which I understand) and limited grant "bits" as Stephen
> puts it.  So I pose the question: do any of the committers consider a grant
> bit too valuable to consume on an ANALYZE grant?

I wasn't referring to "bits" as "things" to do but rather as actual
zeros and ones- AclMode is a 32bit integer, of which the bottom half are
'regular' grantable rights and the top half are "with grant option"
indications, meanly we've only got 16 to work with, and every object
uses AclMode, so we have to support *all* kinds of GRANTs with those 16
bits.

See src/include/nodes/parsenodes.h, around line 63.

> If that and/or general code complexity means this will not be added even if
> a patch was proposed for 9.7 then I'll move on and institute one of the
> hacks that has been proffered.  Otherwise I have (more than) half a mind to
> find some way to get a patch written.

I don't see any reason why the patch itself would be terribly difficult,
but are we sure we'd want just ANALYZE and not VACUUM also?  Which would
have to be another bit, since those are pretty different actions.

The question really is- what other things might we want as grantable
rights in the future?  Once these 16 bits are gone, it's a whole bunch
of work to get more.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [GENERAL] PostgreSQL crash with PANIC message

[Moreno Andreo]

Il 24/03/2016 05:12, Michael Paquier ha scritto:

On Thu, Mar 24, 2016 at 5:57 AM, Adrian Klaver
 wrote:

On 03/23/2016 12:02 PM, Moreno Andreo wrote:

Il 23/03/2016 19:57, Adrian Klaver ha scritto:


Might help to look in:

Control Panel --> Administrative Tools --> Event Viewer


No help there. Nothing strange or pointing to critical resource usage.


The only thing I have left is the generic answer for when things act funny
on Windows:

Do you have AntiVirus software running against the Postgres data directory?

That's likely the reason, something creeping behind is forcing
disconnections from the server.
They have Kaspersky, but I don't know if an upgrade can have done this 
mess. I'll have a check in Kaspersky Log
I requested a machine reboot to admins (to flush memory... since 4,5 GB 
allocated was wit Postgresql service stopped, and in Event log there's 
no trace of a reboot since Nov '15).

We'll see.

Thanks!
Moreno



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Multixacts wraparound monitoring

[Pavlov, Vladimir]

Hello,
How can we determine when an error of approximation multixacts wraparound?
According to the information from pg_class:
select datname,datminmxid from pg_database;
datname | datminmxid
+
template1  |  347462426
template0  |  347462426
postgres  |  347462426
zabbix |  467261307
db_3|  291141939
db_1   |  388282963
db|  388282963
But when the vacuum/autovacuum starts up, an error occurs:
WARNING:  oldest multixact is far in the past
HINT:  Close open transactions with multixacts soon to avoid wraparound 
problems.
If I understand correctly, approaching Multixact member wraparound.
But how to understand when it comes exactly and what to do?
PostgreSQL version - 9.3.10, OS Debian 7.8.
Thank you.
Sorry, if I chose the wrong mailing list.

Kind regards,

Vladimir Pavlov