Re: [GENERAL] pg_multixact issues

[Achilleas Mantzios]

Καλημέρα Κυριάκο

We have been running 9.3.4 as our test system for quite some years, and 9.3.10 on production for a month or so (little less than 1T size, WAL changes worth of 2-5GB/day, about 250K xations/day) we 
never experienced any problems with data/pg_multixact.


In our 9.3.4 :
% pg_controldata data | grep -i multi
Latest checkpoint's NextMultiXactId:  69
Latest checkpoint's NextMultiOffset:  135
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 0
% du -h data/pg_multixact/
 10Kdata/pg_multixact/members
 10Kdata/pg_multixact/offsets
 22Kdata/pg_multixact/

In our prod 9.3.10:
~> pg_controldata data | grep -i multi
Latest checkpoint's NextMultiXactId:  12404
Latest checkpoint's NextMultiOffset:  356
Latest checkpoint's oldestMultiXid:   12232
Latest checkpoint's oldestMulti's DB: 16426
~> du -h data/pg_multixact/
12K data/pg_multixact/members
24K data/pg_multixact/offsets
40K data/pg_multixact/

Our system comprises of a JEE installation with ~ 500 uesrs, and at least 2 
other applications hitting the same tables at the same time, we have about one 
case of deadlocks per week.

What could be different on yours?

On 10/02/2016 20:52, Kiriakos Georgiou wrote:

Hello,

Our pg_multixact directory keeps growing.  I did a "vacuum freeze” which didn’t 
help.  I also did a "vacuum full” which didn’t help either.
We had this condition with 9.3.4 as well.  When I upgraded our cluster to 9.4.5 (via plain sql dump and load) as expected the issue was resolved but now it’s happening again.  Luckily it has no ill 
effect other than consuming 4G of space for an otherwise 1G database.


Can you offer any hints as to how I can cure this?

thanks,
Kiriakos Georgiou


pg_controldata output:

pg_control version number:942
Catalog version number:   201409291
Database system identifier:   6211781659140720513
Database cluster state:   in production
pg_control last modified: Wed Feb 10 13:45:02 2016
Latest checkpoint location:   D/FB5FE630
Prior checkpoint location:D/FB5FE558
Latest checkpoint's REDO location:D/FB5FE5F8
Latest checkpoint's REDO WAL file:0001000D00FB
Latest checkpoint's TimeLineID:   1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:  0/3556219
Latest checkpoint's NextOID:  2227252
Latest checkpoint's NextMultiXactId:  2316566
Latest checkpoint's NextMultiOffset:  823062151
Latest checkpoint's oldestXID:668
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  3556219
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 1
Time of latest checkpoint:Wed Feb 10 13:45:02 2016
Fake LSN counter for unlogged rels:   0/1
Minimum recovery ending location: 0/0
Min recovery ending loc's timeline:   0
Backup start location:0/0
Backup end location:  0/0
End-of-backup record required:no
Current wal_level setting:  hot_standby
Current wal_log_hints setting:off
Current max_connections setting:  100
Current max_worker_processes setting: 8
Current max_prepared_xacts setting:   0
Current max_locks_per_xact setting:   1024
Maximum data alignment:   8
Database block size:  8192
Blocks per segment of large relation: 131072
WAL block size:   8192
Bytes per WAL segment:16777216
Maximum length of identifiers:64
Maximum columns in an index:  32
Maximum size of a TOAST chunk:1996
Size of a large-object chunk: 2048
Date/time type storage:   64-bit integers
Float4 argument passing:  by value
Float8 argument passing:  by value
Data page checksum version:   0

the offsets directory:

-rw---   1 postgres dba   262144 Nov  3 15:22 
-rw---   1 postgres dba   262144 Nov  5 12:45 0001
-rw---   1 postgres dba   262144 Nov  9 14:25 0002
-rw---   1 postgres dba   262144 Nov 13 10:10 0003
-rw---   1 postgres dba   262144 Nov 16 15:40 0004
-rw---   1 postgres dba   262144 Nov 20 09:55 0005
-rw---   1 postgres dba   262144 Dec  1 08:00 0006
-rw---   1 postgres dba   262144 Dec  9 11:50 0007
-rw---   1 postgres dba   262144 Dec 16 08:14 0008
-rw---   1 postgres dba   262144 Dec 21 09:40 0009
-rw---   1 postgres dba   262144 Dec 31 09:55 000A
-rw---   1 postgres dba   262144 Jan  4 21:17 000B
-rw---   1 postgres dba   262144 Jan  6 10:50 000C
-rw---   1 postgres dba   262144 Jan  7 18:20 000D
-rw---   1 postgres dba   262144 Jan 13 13:55 000E
-rw---   1 postgres dba   262144 Jan 15 11:55 000F
-rw---   1 postgres dba   262144 Jan 22 07:50 0010
-rw---   1 postgres dba   262144 Jan 26 16:35 0011
-rw---   1 postgres 

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

Tom Lane wrote:

Really?  That sure seems misleading as can be, and not something we'd
want to be part of a new user's very first impression of Postgres.



In configure we have similar messages:
checking for int8... no
checking for uint8... no
checking for int64... no
checking for uint64... no


--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
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] Test CMake build

[Tom Lane]

Yury Zhuravlev  writes:
> Tom Lane wrote:
>> Really?  That sure seems misleading as can be, and not something we'd
>> want to be part of a new user's very first impression of Postgres.

> In configure we have similar messages:
> checking for int8... no
> checking for uint8... no
> checking for int64... no
> checking for uint64... no

Hm, well, configure does not use the word "failed" to describe expected
cases.

regards, tom lane


-- 
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] fast refresh materialized view

[Oleg Bartunov]

Похоже на то, что вы понимаете по-русски !

Сообщество примет вашу работу только под лицензией BSD. Если что непонятно,
пишите мне.

С Уважением,
Олег

On Thu, Feb 11, 2016 at 7:56 PM, Nguyễn Trần Quốc Vinh  wrote:

> We would like to contribute to the PostgreSQL community. What can you
> recommend us?
>
> Thank you.
>
> TS. Nguyễn Trần Quốc Vinh
> ---
> Chủ nhiệm khoa Tin học
> Trường ĐH Sư phạm - ĐH Đà Nẵng
> Website: http://it.ued.vn ; http://www.ued.vn
> ; http://www.ued.udn.vn
> LLKH: http://scv.ued.vn/~ntquocvinh 
> ĐT: 0511.6-512-586
> DĐ: 0914.78-08-98
> 
> Nguyen Tran Quoc Vinh, PhD
> Dean
> Faculty of Information Technology
> Danang University of Education
> Website: http://it.ued.udn.vn; http://www.ued.vn 
> ; http://www.ued.udn.vn
> SCV: http://scv.ued.vn/~ntquocvinh 
> Phone: (+84) 511.6-512-586
> Mobile: (+84) 914.78-08-98
>
> On Tue, Feb 9, 2016 at 7:51 PM, Michael Paquier  > wrote:
>
>> On Tue, Feb 9, 2016 at 12:32 AM, Nguyễn Trần Quốc Vinh
>>  wrote:
>> >
>> > Thank you very much. We did n't think about that. We would like to
>> choose
>> > APACHE LICENSE. We apologize for late reply.
>>
>> And that would be incompatible with the PostgreSQL license I guess,
>> per concerns with patents and similar stuff.
>> --
>> Michael
>>
>
>

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

Alban Hertroys wrote:

I was under the impression that the FreeBSD port already uses cmake?


I tested on a 32-bit FreeBSD. All tests passed.

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
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] ERROR: missing FROM-clause entry for table

[bigkev]

The call_schedule table looks like this
 id| integer | not null default
nextval('call_schedule_id_seq'::regclass)
 account_id| integer | not null
 user_id   | integer | not null
 call_type_id  | integer | not null
 call_frequency_id | integer | not null
 start_time| timestamp without time zone | not null
 duration  | integer | not null
 end_time  | timestamp without time zone | not null
Indexes:
"call_schedule_pkey" PRIMARY KEY, btree (id)
Foreign-key constraints:
"call_schedule_account_id_fkey" FOREIGN KEY (account_id) REFERENCES
accounts(id)
"call_schedule_call_frequency_id_fkey" FOREIGN KEY (call_frequency_id)
REFERENCES call_frequency(id)
"call_schedule_call_type_id_fkey" FOREIGN KEY (call_type_id) REFERENCES
call_types(id)
"call_schedule_user_id_fkey" FOREIGN KEY (user_id) REFERENCES users(id)

This stores the start_time, which is the date and time a series of calls
begins. The duration defines how long this event(call) will go for, and the
end_time defines when the schedule will stop. 
I need to generate a calendar eg: 1 year with intervals of 1 day, and
include fortnightly calls at the appropriate dates. 
the call_frequency_id would be 5 for a fortnightly call.

I an post schema if you need.




--
View this message in context: 
http://postgresql.nabble.com/ERROR-missing-FROM-clause-entry-for-table-tp5886750p5886990.html
Sent from the PostgreSQL - general mailing list archive at Nabble.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] Transaction ID not logged if no explicit transaction used

[Martín Marqués]

El 10/02/16 a las 20:11, Adrian Klaver escribió:
>>
>> So, my question is: Is this a bug, or a feature? I recall being able to
>> log xids on DDLs but can't find the correct settings now.
> 
> Maybe?:
> 
> %v Virtual transaction ID (backendID/localXID)

AFAICS that value won't help if I need the xid to do a PITR up to that
xid not included.

Regards,

-- 
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, 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] Unrecognized configuration parameter in bdr 0.9.3

[Kaushal Shriyan]

Hi,

I am following http://bdr-project.org/docs/stable/index.html for setting up
multimaster replication.

*First Master box*

*cat postgresql.conf*
# Allow two other peer nodes, plus one for init_replica
max_replication_slots = 3

# Two peer nodes, plus two slots for pg_basebackup
max_wal_senders = 4

# Record data for logical replication
wal_level = 'logical'
track_commit_timestamp = on

# Load BDR
shared_preload_libraries = 'bdr'

# Make sure there are enough background worker slots for BDR to run
max_worker_processes = 10

# These aren't required, but are useful for diagnosing problems
#log_error_verbosity = verbose
#log_min_messages = debug1
#log_line_prefix = 'd=%d p=%p a=%a%q '

# Useful options for playing with conflicts
#bdr.default_apply_delay=2000   # milliseconds
#bdr.log_conflicts_to_table=on

# (BEGIN) BDR connection settings for node 1, port 5600
bdr.connections = 'secondarymasterport5601'
bdr.secondarymasterport5601_dsn = 'dbname=bdrdemo user=postgres port=5601'
# (END) BDR connection settings for node 1, port 5600

# (BEGIN) BDR connection settings for node 2, port 5601
#bdr.connections = '{DevEnvName}node01port5600'
#bdr.{DevEnvName}node01port5600_dsn = 'dbname={DevDBName} user=postgres
port=5600'
#bdr.{DevEnvName}node01port5600_init_replica = on
#bdr.{DevEnvName}node01port5600_replica_local_dsn = 'dbname={DevDBName}
user=postgres port=5601'
# (END) BDR connection settings for node 2, port 5601

cat postgresql.log
< 2016-02-11 07:03:09.431 EST >LOG:  registering background worker "bdr
supervisor"
*< 2016-02-11 07:03:09.431 EST >WARNING:  unrecognized configuration
parameter "bdr.connections"*
*< 2016-02-11 07:03:09.431 EST >WARNING:  unrecognized configuration
parameter "bdr.secondarymasterport5601_dsn"*
< 2016-02-11 07:03:09.446 EST >LOG:  redirecting log output to logging
collector process
< 2016-02-11 07:03:09.446 EST >HINT:  Future log output will appear in
directory "pg_log".


*Second Master Box.*

*cat postgresql.conf*
# Allow two other peer nodes, plus one for init_replica
max_replication_slots = 3

# Two peer nodes, plus two slots for pg_basebackup
max_wal_senders = 4

# Record data for logical replication
wal_level = 'logical'
track_commit_timestamp = on

# Load BDR
shared_preload_libraries = 'bdr'

# Make sure there are enough background worker slots for BDR to run
max_worker_processes = 10

# These aren't required, but are useful for diagnosing problems
#log_error_verbosity = verbose
#log_min_messages = debug1
#log_line_prefix = 'd=%d p=%p a=%a%q '

# Useful options for playing with conflicts
#bdr.default_apply_delay=2000   # milliseconds
#bdr.log_conflicts_to_table=on

# (BEGIN) BDR connection settings for node 1, port 5600
#bdr.connections = 'primarymasterport5600'
#bdr.primarymasterport5600_dsn = 'dbname=bdrdemo user=postgres port=5600'
#bdr.primarymasterport5600_init_replica = on
#bdr.primarymasterport5600_replica_local_dsn = 'dbname=bdrdemo
user=postgres port=5601'
# (END) BDR connection settings for node 1, port 5600

# (BEGIN) BDR connection settings for node 2, port 5601
bdr.connections = 'primarymasterport5600'
bdr.primarymasterport5600_dsn = 'dbname=bdrdemo user=postgres port=5600'
bdr.primarymasterport5600_init_replica = on
bdr.primarymasterport5600_replica_local_dsn = 'dbname=bdrdemo user=postgres
port=5601'
#bdr.{DevEnvName}node01port5600_init_replica = on
#bdr.{DevEnvName}node01port5600_replica_local_dsn = 'dbname={DevDBName}
user=postgres port=5601'
# (END) BDR connection settings for node 2, port 5601


-bash-4.1$ cat postgresql.log
< 2016-02-11 07:03:17.231 EST >LOG:  registering background worker "bdr
supervisor"
*< 2016-02-11 07:03:17.231 EST >WARNING:  unrecognized configuration
parameter "bdr.connections"*
*< 2016-02-11 07:03:17.231 EST >WARNING:  unrecognized configuration
parameter "bdr.primarymasterport5600_dsn"*
*< 2016-02-11 07:03:17.231 EST >WARNING:  unrecognized configuration
parameter "bdr.primarymasterport5600_init_replica"*
*< 2016-02-11 07:03:17.231 EST >WARNING:  unrecognized configuration
parameter "bdr.primarymasterport5600_replica_local_dsn"*
< 2016-02-11 07:03:17.247 EST >LOG:  redirecting log output to logging
collector process
< 2016-02-11 07:03:17.247 EST >HINT:  Future log output will appear in
directory "pg_log".
-bash-4.1$

On both the master postgresql box i have the below versions.

$rpm -qa | grep bdr
postgresql-bdr94-2ndquadrant-redhat-1.0-2.noarch
postgresql-bdr94-contrib-9.4.5_bdr1-1_2ndQuadrant.el6.x86_64
libdrm-2.4.52-4.el6.x86_64
postgresql-bdr94-libs-9.4.5_bdr1-1_2ndQuadrant.el6.x86_64
postgresql-bdr94-server-9.4.5_bdr1-1_2ndQuadrant.el6.x86_64
postgresql-bdr94-bdr-0.9.3-1_2ndQuadrant.el6.x86_64
postgresql-bdr94-9.4.5_bdr1-1_2ndQuadrant.el6.x86_64
-bash-4.1$ rpm -qil postgresql-bdr94-bdr-0.9.3-1_2ndQuadrant.el6.x86_64
Name: postgresql-bdr94-bdr Relocations: (not relocatable)
Version : 0.9.3 Vendor: (none)
Release : 1_2ndQuadrant.el6 Build Date: Wed 21 Oct 2015

[GENERAL] memory problem with refresh materialized view

[Enrico Pirozzi]

Hi
I have a new postgresql 9.5.0 installation on a new virtual server debian
8.3 x64 with 4gb RAM, I have compiled postgresql from source.

When I import a dump with materialized views I see that postgres process
takes about all 4 Gb and then I have this error

 fork: Cannot allocate memory


Can anyone help me?

Thanks in advantage :)

Enrico

-- 
PostgreSQL openday Rimini 27-02-2016


Enrico Pirozzi
Tel.  +39 0861 1855771 - Mob.+39 328 4164437 - Fax  +39 0861 1850310
http://www.pgtraining.com  -
i...@pgtraining.com
www.enricopirozzi.info - i...@enricopirozzi.info
Skype sscotty71 - Gtalk sscott...@gmail.com

Re: [GENERAL] PostgreSQL vs Firebird SQL

[Pierre Chevalier Géologue]

Le 10/02/2016 18:08, John R Pierce a écrit :

On 2/10/2016 8:51 AM, Pierre Chevalier Géologue wrote:

PPS: how should I behave on this list: should I systematically "reply
to all", or just "reply" to the list?  I'm used to a number of mailing
lists where a simple "reply" automatically replies to the list, and
the rule obliges you to *only* use "reply".


Thunderbird offers me both 'reply' and 'reply list' buttons for the
messages on this list.


Same for me, except that I dislike buttons so they are hidden: Ctrl-R 
and Shift-Ctrl-R do the same trick...




most of the lists I'm on, a simple reply IS a reply list,


Yes, same for me, I only know less than 3 exceptions, among a few dozen 
lists.




as they wish to encourage discussions rather than
private responses.


+1.




I personally dislike 'reply all'


Yes, I totally agree with you, I prefer much 'reply'ing to the list, I'm 
doing that 90% of my time spent on lists.


Would there be a chance to change the default behaviour of the postgres 
lists?  This is to be setup on the list's server side. But it requires 
some "political" decision first, and of course a consensus.




as I'm ON the list so why send me another CC ?


No point, as your reply arrives on the list, you can see it in the thread.


À+
Pierre
--

Pierre Chevalier
PChGEI: Pierre Chevalier Géologue Et Informaticien
Mesté Duran
32100 Condom
  Tél+fax  :09 75 27 45 62
06 37 80 33 64
  Émail  :   pierrechevaliergeolCHEZfree.fr
  icq#   :   10432285
  jabber: pierre.chevalier1...@jabber.fr
  http://pierremariechevalier.free.fr/pierre_chevalier_geologue



--
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 vs Firebird SQL

[Pierre Chevalier Géologue]

Le 10/02/2016 19:49, Adrian Klaver a écrit :

Go here:
https://mail.postgresql.org/mj/mj_wwwusr/domain=postgresql.org?func=lists-long-full=pgsql-general



And in settings check:
eliminatecc
 Select this if you do not want two copies when someone sends a
message both to you and to the list.



Thanks for the trick, I just followed your advice (before I started 
writing this mail, though...).


I am trying to figure out from the help documentation 
(https://mail.postgresql.org/mj/mj_wwwusr/domain=postgresql.org?user=pierrechevaliergeol%40free.fr=0F21-276B-3588=GLOBAL=help=set) 
how to set the default "reply-to" to the list.


The 'replyto' option seems to be what I wish:

Add a Reply-to header
These control Reply-To: header generation. If the list owner has defined
a Reply-To: header, you can specify whether or not you want to see it.
replyto - always add the Reply-To: header
noreplyto - never add the header (but if the poster has provided one,
you will see it)
Usually, turning this setting on will cause your replies to be addressed
to the mailing list; turning this setting off will cause your replies to
be addressed to the person who wrote the message to which you are
replying.


=> do you confirm?



It lets me distinguish between the list threads that I haven't responded
to and those that I have.​


?  In the other lists where I am, even though I always 'reply' and it 
goes automatically to the list, I can see my own replies, displayed 
within the appropriate conversation thread.

Or did I miss a point?

À+
Pierre
--

Pierre Chevalier
PChGEI: Pierre Chevalier Géologue Et Informaticien
Mesté Duran
32100 Condom
  Tél+fax  :09 75 27 45 62
06 37 80 33 64
  Émail  :   pierrechevaliergeolCHEZfree.fr
  icq#   :   10432285
  jabber: pierre.chevalier1...@jabber.fr
  http://pierremariechevalier.free.fr/pierre_chevalier_geologue



--
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 vs Firebird SQL

[Merlin Moncure]

On Tue, Feb 9, 2016 at 10:10 PM, ioan ghip  wrote:
> I have a Firebird SQL database running on one of my servers which has about
> 50k inserts, about 100k updates and about 30k deletes every day. There are
> about 4 million records in 24 tables. I have a bunch of stored procedures,
> triggers, events and views that I'm using.
> Firebird works fairly well, but from time to time the database gets
> corrupted and I couldn't figure out yet (after many years of running) what's
> the reason. When this happens I run "gfix -mend -full -ignore", backup and
> restore the db and everything is fine until next problem in a week, or a
> month.
>
> I never used PostgreSQL. Yesterday I installed it on my development machine
> and after few tests I saw that it's fairly easy to use.

> Does anyone have experience with both, Firebird and PostgreSQL?
yes

> Is PostgreSQL way better performing than Firebird?
yes

> Is it worth the effort moving away from Firebird?
yes

> Would I gain stability and increased performance?
yes

Firebird was and is a pretty neat database. I still remember when I
first fired up Delphi and whipped out an application in about 10
minutes.  Well, it's time to move on...you're with us now.

merlin


-- 
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 vs Firebird SQL

[Adrian Klaver]

On 02/11/2016 05:42 AM, Pierre Chevalier Géologue wrote:

Le 10/02/2016 19:49, Adrian Klaver a écrit :

Go here:
https://mail.postgresql.org/mj/mj_wwwusr/domain=postgresql.org?func=lists-long-full=pgsql-general




And in settings check:
eliminatecc
 Select this if you do not want two copies when someone sends a
message both to you and to the list.



Thanks for the trick, I just followed your advice (before I started
writing this mail, though...).

I am trying to figure out from the help documentation
(https://mail.postgresql.org/mj/mj_wwwusr/domain=postgresql.org?user=pierrechevaliergeol%40free.fr=0F21-276B-3588=GLOBAL=help=set)
how to set the default "reply-to" to the list.

The 'replyto' option seems to be what I wish:

Add a Reply-to header
These control Reply-To: header generation. If the list owner has defined
a Reply-To: header, you can specify whether or not you want to see it.
replyto - always add the Reply-To: header
noreplyto - never add the header (but if the poster has provided one,
you will see it)
Usually, turning this setting on will cause your replies to be addressed
to the mailing list; turning this setting off will cause your replies to
be addressed to the person who wrote the message to which you are
replying.


=> do you confirm?


I have not used this, so I cannot confirm, though it seems to do what 
you want. The only setting I have ever actually changed was to unset 
selfcopy. I use Thunderbird and it seems to know what to do with Reply 
All on both ends, sending/receiving.






It lets me distinguish between the list threads that I haven't responded
to and those that I have.​


?  In the other lists where I am, even though I always 'reply' and it
goes automatically to the list, I can see my own replies, displayed
within the appropriate conversation thread.
Or did I miss a point?

À+
Pierre



--
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] Test CMake build

[Yury Zhuravlev]

Yury Zhuravlev wrote:

I will try to fix soon.
I write as a corrected.


You can try again. Thanks!

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


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

[GENERAL] XMLEXISTS on legacy XML with malformed xmlns

[Edson Richter]

Hi!

I've some (about 1M records) containing legacy XML I would like to parse 
and apply XMLEXISTS.


This is the query:

select * from xmllog
 where xpath_exists(('//MyDocument[@DocNum = ''000411828'']'::text), 
xmlparse(document cdataout));


This is the error:

ERRO: could not parse XML document
SQL state: 2200M
Detail: line 2: xmlns:leg: 'LEGACYAPP - SEND MSG EVENTS ABOUT' is not a 
valid URI


^

This is the sample XML with malformed xmlns (I've shortenet the data, 
but the important thing here is the malformed xmlns):


"

  

  0
  I can easly read this XML in Notepad++, and also in Java - but 
PostgreSQL always throw error.


Can you plase tell me how can make PostgreSQL ignore this malformed 
xmlns and proceed processing the XML?


Thanks,

--
Atenciosamente,

Edson Carlos Ericksson Richter



--
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] Transaction ID not logged if no explicit transaction used

[Tom Lane]

Alvaro Herrera  writes:
> Martín Marqués wrote:
>> This really gives little use for recovery_target_xid. :(

> Hmm, you can still use pg_xlogdump to figure it out from the actual WAL,
> which has the correct XIDs.  It's obviously a worse solution though from
> the user's POV, because it's hard to figure out what WAL record
> corresponds to the change you care about ...

To what extent does the commit_ts infrastructure fix this?

regards, tom lane


-- 
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] Transaction ID not logged if no explicit transaction used

[Alvaro Herrera]

Martín Marqués wrote:
> El 10/02/16 a las 21:46, Tom Lane escribió:

> > We could maybe fix this by redefining %x as "the current or most recent
> > xid", so that it'd still be valid for messages issued post-commit.
> > But I'm afraid that would add about as many bad behaviors as it would
> > remove.  In your example above, that would result in a pretty misleading
> > xid attached to the "begin" statement, since at that point we have
> > started a new transaction but not assigned it any xid.
> 
> This really gives little use for recovery_target_xid. :(

Hmm, you can still use pg_xlogdump to figure it out from the actual WAL,
which has the correct XIDs.  It's obviously a worse solution though from
the user's POV, because it's hard to figure out what WAL record
corresponds to the change you care about ...

-- 
Á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] ERROR: missing FROM-clause entry for table

[Roxanne Reid-Bennett]

On 2/11/2016 2:15 AM, bigkev wrote:

...
This stores the start_time, which is the date and time a series of calls
begins. The duration defines how long this event(call) will go for, and the
end_time defines when the schedule will stop.
I need to generate a calendar eg: 1 year with intervals of 1 day, and
include fortnightly calls at the appropriate dates.
the call_frequency_id would be 5 for a fortnightly call.

I an post schema if you need.
If I've read your original query correctly.. Based on this ... I think 
you were just off a little bit on your idea.


Consider moving the fortnight generation into a sub-query join with the 
call_schedule... e.g.


SELECT g.*, *c.meeting*, a.name AS account_name, u.name AS user_name, 
c.start_time,
 c.start_time::timestamp+c.duration * '1s'::interval AS 
end_time,

 ct.name, extract(dow from c.start_time) AS start_day
FROM generate_series('2016-01-22', '2017-12-31', '1 day'::interval) g(day)
LEFT JOIN (
select *, generate_series(c.start_time, c.end_time, *'2 
week'::interval*) *meeting*

from call_schedule c
where call_frequency_id *= 5*
) c on ((g.day, '1 day'::interval) OVERLAPS (meeting, c.duration * 
'1s'::interval))

LEFT JOIN users u ON c.user_id=u.id
LEFT JOIN accounts a ON c.account_id=a.id
LEFT JOIN call_types ct ON c.call_type_id=ct.id
ORDER BY g.day

The generate_series in the sub-query could be genericized to deal with 
any frequency
through the use of a user defined function or a join on  your 
call_frequency table if it stores "interval" data.


Tuning wise, you may need to move the 3 dependent joins into the 
sub-query for better performance.
I'm not exactly sure what the sub-query does to the planner for index 
usage for joins...


I am also not sure what the performance difference might be between 
using OVERLAPS and BETWEEN.


Roxanne

--
[At other schools] I think the most common fault in general is to teach 
students how to pass exams instead of teaching them the science.
Donald Knuth

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

On четверг, 11 февраля 2016 г. 22:37:12 MSK, Tom Lane wrote:

Hm, well, configure does not use the word "failed" to describe expected
cases.


Well, it does not confuse CMake users. (MySQL, KDE)
Just the other tradition, I do not see the problem here. :)

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
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] Transaction ID not logged if no explicit transaction used

[Martín Marqués]

El 10/02/16 a las 21:46, Tom Lane escribió:
> 
> Think you're outta luck on that.  If we logged the duration before
> commit, it would be entirely misleading for short commands, because
> the time needed to commit wouldn't be included.  So we log it after,
> when there's no longer any active transaction.

Any other way to log the DDL and DML statements (maybe delay writing the
log until the xid is available)?

Yes, I know the complexity of this, but I'm surprised this hasn't come
up in the list before (maybe it did and i missed the mail).

> We could maybe fix this by redefining %x as "the current or most recent
> xid", so that it'd still be valid for messages issued post-commit.
> But I'm afraid that would add about as many bad behaviors as it would
> remove.  In your example above, that would result in a pretty misleading
> xid attached to the "begin" statement, since at that point we have
> started a new transaction but not assigned it any xid.

This really gives little use for recovery_target_xid. :(

Regards,

-- 
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, 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] fast refresh materialized view

[Michael Paquier]

On Fri, Feb 12, 2016 at 4:29 AM, Oleg Bartunov  wrote:
> Похоже на то, что вы понимаете по-русски !

I don't. My bad.
-- 
Michael

-- 
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] fast refresh materialized view

[Michael Paquier]

On Fri, Feb 12, 2016 at 1:56 AM, Nguyễn Trần Quốc Vinh
 wrote:
> We would like to contribute to the PostgreSQL community. What can you
> recommend us?

If you are planning to send patches for integration into core
Postgres, this code needs to be available under a license that is
compatible with the PostgreSQL license. If you plan to maintain that
as an independent project that would never be integrated with Postgres
directly, the license does not really matter, but it would prevent
other people to do the integration legwork into core if having your
feature makes sense.
-- 
Michael


-- 
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] Unrecognized configuration parameter in bdr 0.9.3

[Craig Ringer]

On 11 February 2016 at 20:16, Kaushal Shriyan 
wrote:

> Hi,
>
> I am following http://bdr-project.org/docs/stable/index.html for setting
> up multimaster replication.
>

Are you sure that's the documentation you were using?

You seem to have settings that only applied to the older 0.7.x versions:


> # (BEGIN) BDR connection settings for node 1, port 5600
> bdr.connections = 'secondarymasterport5601'
> bdr.secondarymasterport5601_dsn = 'dbname=bdrdemo user=postgres port=5601'
> # (END) BDR connection settings for node 1, port 5600
>
> # (BEGIN) BDR connection settings for node 2, port 5601
> #bdr.connections = '{DevEnvName}node01port5600'
> #bdr.{DevEnvName}node01port5600_dsn = 'dbname={DevDBName} user=postgres
> port=5600'
> #bdr.{DevEnvName}node01port5600_init_replica = on
> #bdr.{DevEnvName}node01port5600_replica_local_dsn = 'dbname={DevDBName}
> user=postgres port=5601'
> # (END) BDR connection settings for node 2, port 5601
>

The above is not used in BDR 0.9.x. Configuration is done at the SQL level.

-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

[GENERAL] 9.4 -> 9.5 dump size reduction

[Seb]

Hello,

I recently upgraded a server from 9.4 to 9.5 (Debian) via
pg_upgradecluster.  The upgrade finished well, and so far the databases
in the upgraded cluster seem in good form.  However, I noticed a
dramatic reduction in the size of the dump created by the new server.
One of the databases was 34G when dumped by the 9.4 server is now dumped
at 1.1G in the new 9.5 version (using pg_dump -Fc in both cases).  What
has caused such remarkable improvement?!

Thanks,

-- 
Seb



-- 
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] 9.4 -> 9.5 dump size reduction

[Tom Lane]

Seb  writes:
> I recently upgraded a server from 9.4 to 9.5 (Debian) via
> pg_upgradecluster.  The upgrade finished well, and so far the databases
> in the upgraded cluster seem in good form.  However, I noticed a
> dramatic reduction in the size of the dump created by the new server.
> One of the databases was 34G when dumped by the 9.4 server is now dumped
> at 1.1G in the new 9.5 version (using pg_dump -Fc in both cases).  What
> has caused such remarkable improvement?!

That seems really fishy.  Better check to see if all your data
is still there :-(

regards, tom lane


-- 
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] XMLEXISTS on legacy XML with malformed xmlns

[Pavel Stehule]

2016-02-12 1:53 GMT+01:00 Edson Richter :

> Hi!
>
> I've some (about 1M records) containing legacy XML I would like to parse
> and apply XMLEXISTS.
>
> This is the query:
>
> select * from xmllog
>  where xpath_exists(('//MyDocument[@DocNum = ''000411828'']'::text),
> xmlparse(document cdataout));
>
> This is the error:
>
> ERRO: could not parse XML document
> SQL state: 2200M
> Detail: line 2: xmlns:leg: 'LEGACYAPP - SEND MSG EVENTS ABOUT' is not a
> valid URI
> 
> ^
>
> This is the sample XML with malformed xmlns (I've shortenet the data, but
> the important thing here is the malformed xmlns):
>
> "
> 
>   
> 
>   0
>   
>
> I can easly read this XML in Notepad++, and also in Java - but PostgreSQL
> always throw error.
>
> Can you plase tell me how can make PostgreSQL ignore this malformed xmlns
> and proceed processing the XML?
>

PostgreSQL uses libxml2, but the usage isn't too configurable. So my advice
is using defensive strategy and clean/fix wrong namespace with string tools
- replace function.

Regards

Pavel


>
> Thanks,
>
> --
> Atenciosamente,
>
> Edson Carlos Ericksson Richter
>
>
>
> --
> 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] PosgreSQL Security Architecture

[Adrian Klaver]

On 02/11/2016 08:30 AM, Lesley Kimmel wrote:

All;

I'm working to secure a PosgreSQL database according to a DoD security
guide. It has many very generic requirements that get more toward the
internal architecture of the system that wouldn't be apparent to the
average admin. I was hoping someone might have some insight to the
following requirements:

a) The DBMS must maintain the authenticity of communications sessions by
guarding against man-in-the-middle attacks that guess at Session ID values.

b) Check DBMS settings and vendor documentation to verify the DBMS
properly handles transactions in the event of a system failure. The
consistent state must include a security configuration that is at least
as restrictive as before the system failure. This must be guaranteed.


Might want to take a look at these threads:

http://www.postgresql.org/message-id/CAKd4e_EXeMp2+DLqeZc=ffctz74vl4wvuvavyem2_-hju63...@mail.gmail.com

http://www.postgresql.org/message-
id/CAKd4e_G6xA22C+Sc0QnrLLs03kM1fOPgUNLjymtyRxK64e=v...@mail.gmail.com




Thanks in advance,
-LJK



--
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] Test CMake build

[Andy Colson]

On 2/11/2016 10:44 AM, Andy Colson wrote:

On 2/11/2016 9:49 AM, Yury Zhuravlev wrote:

Yury Zhuravlev wrote:

I will try to fix soon.
I write as a corrected.


You can try again. Thanks!



That seems better:

-- Found Readline: /usr/include
-- Found Curses: /usr/lib64/libcurses.so

Is this bad?
-- Check size of int64
-- Check size of int64 - failed
-- Check size of uint64
-- Check size of uint64 - failed
-- Check size of int8
-- Check size of int8 - failed

make -j2
running now...

-Andy





make finished ok.

I build slackware packages, so it needs to install into a temp spot, 
which kinda works:


andy@mapper:~/projects/postgres_cmake/build$ mkdir /tmp/pg999

I used to use "make install-strip", is that not a thing anymore?

andy@mapper:~/projects/postgres_cmake/build$ make install-strip 
DESTDIR=/tmp/pg999

make: *** No rule to make target `install-strip'.  Stop.

Ok, we'll install, but into a tmp folder:

andy@mapper:~/projects/postgres_cmake/build$ make install DESTDIR=/tmp/pg999
[  0%] Built target gen_errorcodes
[  3%] Built target port
[  5%] Built target port_srv


[100%] Built target refint
[100%] Built target timetravel
Install the project...
-- Install configuration: ""
-- Installing: /tmp/pg999/usr/local/pg99/lib/libpq.so
-- Installing: /tmp/pg999/usr/local/pg99/bin/initdb

-- Removed runtime path from "/tmp/pg999/usr/local/pg99/bin/initdb"



-- Installing: /tmp/pg999/usr/local/pg99/share/timezonesets/Default
-- Installing: /tmp/pg999/usr/local/pg99/share/timezonesets/Australia
-- Installing: /tmp/pg999/usr/local/pg99/share/timezonesets/India
/home/andy/projects/postgres_cmake/build/src/timezone//zic: Cannot 
create directory /usr/local/pg99: Permission denied

-- Installing: /tmp/pg999/usr/local/pg99/lib/plpgsql.so
-- Installing: /tmp/pg999/usr/local/pg99/share/extension/plpgsql.control
-- Installing: /tmp/pg999/usr/local/pg99/share/extension/plpgsql--1.0.sql
-- Installing: 
/tmp/pg999/usr/local/pg99/share/extension/plpgsql--unpackaged--1.0.sql





I start with:
cmake .. -DCMAKE_INSTALL_PREFIX="/usr/local/pg99"

I'm not building/installing as root, so cannot actually write to 
/usr/local/pg99


I dunno what version we are building, and dont want to replace anything 
currently installed, so I went for pg99.




andy@mapper:~/projects/postgres_cmake/build$ make installcheck
Scanning dependencies of target tablespace-setup
[  0%] Built target tablespace-setup
[  0%] Built target gen_errorcodes
[ 42%] Built target port
[ 85%] Built target pq
[100%] Built target pgcommon
[100%] Built target pg_regress
Scanning dependencies of target installcheck
== creating temporary instance==
== initializing database system   ==

pg_regress: initdb failed
Examine 
/home/andy/projects/postgres_cmake/src/test/regress/log/initdb.log for 
the reason.
Command was: "/usr/local/pg99/bin/initdb" -D 
"/home/andy/projects/postgres_cmake/src/test/regress/tmp_check/data" 
--noclean --nosync --no-locale > 
"/home/andy/projects/postgres_cmake/src/test/regress/log/initdb.log" 2>&1

make[3]: *** [src/test/regress/CMakeFiles/installcheck] Error 2
make[2]: *** [src/test/regress/CMakeFiles/installcheck.dir/all] Error 2
make[1]: *** [src/test/regress/CMakeFiles/installcheck.dir/rule] Error 2
make: *** [installcheck] Error 2


andy@mapper:~/projects/postgres_cmake/build$ cat 
/home/andy/projects/postgres_cmake/src/test/regress/log/initdb.log

sh: /usr/local/pg99/bin/initdb: No such file or directory


Yeah, that makes sense, its not actually there yet.  Is the installcheck 
important to you?  I can do the install if you like.


-Andy





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

[GENERAL] PosgreSQL Security Architecture

[Lesley Kimmel]

All;

I'm working to secure a PosgreSQL database according to a DoD security
guide. It has many very generic requirements that get more toward the
internal architecture of the system that wouldn't be apparent to the
average admin. I was hoping someone might have some insight to the
following requirements:

a) The DBMS must maintain the authenticity of communications sessions by
guarding against man-in-the-middle attacks that guess at Session ID values.

b) Check DBMS settings and vendor documentation to verify the DBMS properly
handles transactions in the event of a system failure. The consistent state
must include a security configuration that is at least as restrictive as
before the system failure. This must be guaranteed.

Thanks in advance,
-LJK

Re: [GENERAL] Test CMake build

[Andy Colson]

On 2/11/2016 9:49 AM, Yury Zhuravlev wrote:

Yury Zhuravlev wrote:

I will try to fix soon.
I write as a corrected.


You can try again. Thanks!



That seems better:

-- Found Readline: /usr/include
-- Found Curses: /usr/lib64/libcurses.so

Is this bad?
-- Check size of int64
-- Check size of int64 - failed
-- Check size of uint64
-- Check size of uint64 - failed
-- Check size of int8
-- Check size of int8 - failed

make -j2
running now...

-Andy



--
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] fast refresh materialized view

[Nguyễn Trần Quốc Vinh]

We would like to contribute to the PostgreSQL community. What can you
recommend us?

Thank you.

TS. Nguyễn Trần Quốc Vinh
---
Chủ nhiệm khoa Tin học
Trường ĐH Sư phạm - ĐH Đà Nẵng
Website: http://it.ued.vn ; http://www.ued.vn
; http://www.ued.udn.vn
LLKH: http://scv.ued.vn/~ntquocvinh 
ĐT: 0511.6-512-586
DĐ: 0914.78-08-98

Nguyen Tran Quoc Vinh, PhD
Dean
Faculty of Information Technology
Danang University of Education
Website: http://it.ued.udn.vn; http://www.ued.vn ;
http://www.ued.udn.vn
SCV: http://scv.ued.vn/~ntquocvinh 
Phone: (+84) 511.6-512-586
Mobile: (+84) 914.78-08-98

On Tue, Feb 9, 2016 at 7:51 PM, Michael Paquier 
wrote:

> On Tue, Feb 9, 2016 at 12:32 AM, Nguyễn Trần Quốc Vinh
>  wrote:
> >
> > Thank you very much. We did n't think about that. We would like to choose
> > APACHE LICENSE. We apologize for late reply.
>
> And that would be incompatible with the PostgreSQL license I guess,
> per concerns with patents and similar stuff.
> --
> Michael
>

Re: [GENERAL] Test CMake build

[Yury Zhuravlev]

Andy Colson wrote:

Is this bad?
-- Check size of int64
-- Check size of int64 - failed
-- Check size of uint64
-- Check size of uint64 - failed
-- Check size of int8
-- Check size of int8 - failed


This is normal behavior for linux. 


--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
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] Test CMake build

[Tom Lane]

Yury Zhuravlev  writes:
> Andy Colson wrote:
>> Is this bad?
>> -- Check size of int64
>> -- Check size of int64 - failed
>> -- Check size of uint64
>> -- Check size of uint64 - failed
>> -- Check size of int8
>> -- Check size of int8 - failed

> This is normal behavior for linux. 

Really?  That sure seems misleading as can be, and not something we'd
want to be part of a new user's very first impression of Postgres.

regards, tom lane


-- 
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] Test CMake build

[Yury Zhuravlev]

I used to use "make install-strip", is that not a thing anymore?

I think it's plans for the near future. Please create issue in GitHub.


/home/andy/projects/postgres_cmake/build/src/timezone//zic: Cannot create
directory /usr/local/pg99: Permission denied
I will fix it. 


sh: /usr/local/pg99/bin/initdb: No such file or directory


I have not tested yet with DESTDIR. I think tomorrow will correct it.


Yeah, that makes sense, its not actually there yet.  Is the installcheck
important to you?  I can do the install if you like.


installcheck is replace "make check" now. Or I did not understand your 
question.


--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--
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] Test CMake build

[Yury Zhuravlev]

Andy Colson wrote:

the end of CMakeFiles/CMakeError.log shows:


Many thanks! I think I understand what the problem is. I will try to fix 
soon.

I write as a corrected.
--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



--
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] Test CMake build

[Andy Colson]

On 2/10/2016 12:09 PM, Yury Zhuravlev wrote:

Hello all.
Please test build Postgres using cmake. If you are of course interested.
Still not everything is ready but most of the work. Assembly
instructions as does the repository is on github:
https://github.com/stalkerg/postgres_cmake

The compilation will be enough (tests even better). I need feedbacks so
that create issues on github.
Very interesting NetBSD, OpenBSD, Solaris.
Thanks!


On a side note, how hard would it be to print a small summary of options 
after the cmake step?


Its not important, but is pretty nice.  mapserver, for example, shows this:


-- * Summary of configured options for this build
--  * Mandatory components
--   * png: /usr/lib64/libpng.so
--   * jpeg: /usr/lib64/libjpeg.so
--   * freetype: /usr/lib64/libfreetype.so
--  * Optional components
--   * GDAL: /usr/local/lib/libgdal.so
--   * OGR: /usr/local/lib/libgdal.so
--   * GD: disabled
--   * GIF: /usr/lib64/libgif.so
--   * MYSQL: disabled
--   * FRIBIDI: /usr/lib64/libfribidi.so
--   * GIF: /usr/lib64/libgif.so
--   * CAIRO: /usr/lib64/libcairo.so
--   * SVGCAIRO: disabled
--   * RSVG: disabled
--   * CURL: disabled
--   * PROJ: /usr/lib64/libproj.so
--   * LIBXML2: /usr/lib64/libxml2.so
--   * POSTGIS: /usr/local/pg93/lib/libpq.so
--   * GEOS: /usr/lib64/libgeos_c.so
--   * FastCGI: /usr/lib64/libfcgi.so
--   * Oracle Spatial: disabled
--   * SDE: disabled
--   * Exempi XMP: disabled
--  * Optional features
--   * WMS SERVER: ENABLED
--   * WFS SERVER: ENABLED
--   * WCS SERVER: ENABLED
--   * SOS SERVER: disabled
--   * WMS CLIENT: disabled
--   * WFS CLIENT: disabled
--   * ICONV: ENABLED
--   * Thread-safety support: disabled
--   * KML output: disabled
--   * Z+M point coordinate support: disabled
--   * XML Mapfile support: disabled
--  * Mapscripts
--   * Python: disabled
--   * PHP: disabled
--   * PERL: ENABLED
--   * RUBY: disabled
--   * JAVA: disabled
--   * C#: disabled
--   * Apache Module (Experimental): disabled
--
-- Will install files to /usr/local
-- Will install libraries to /usr/local/lib64


We would not care about the libs, but things like integer dates, and 
perl, python, etc, ssl version.  Looks like you calc TABLE_BLOCKSIZE and 
WAL_BLOCKSIZE, those might be nice to see.



Anyway, thanks for all your work on this.  Looking good.

-Andy



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