Re: [HACKERS] [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
On Fri, Sep 7, 2012 at 11:40 AM, Gezeala M. Bacuño II geze...@gmail.com wrote:
adding pgsql-bugs list in case OP posts back.
On Fri, Sep 7, 2012 at 11:29 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
(Adding -hackers. Did not realize it got dropped)
On Fri, Sep 7, 2012 at 11:25 PM, Gezeala M. Bacuño II geze...@gmail.com
wrote:
On Fri, Sep 7, 2012 at 7:17 AM, Pavan Deolasee pavan.deola...@gmail.com
wrote:
On Fri, Sep 7, 2012 at 7:00 PM, Marie Bacuno II geze...@gmail.com
wrote:
On Sep 7, 2012, at 2:19, Pavan Deolasee pavan.deola...@gmail.com
wrote:
or have long running transactions ?
Yes but I don't think there are when the snapshot was taken. Does the
pg_xlog_location_diff() result from latest and prior checkpoint upon
start-up indicates the size of replayed changes?
Thats the amount of additional WAL generated after you started the
server.
BTW, the following query returns ~60GB. Thats the amount of WAL
written after the server was started and at the end of pg_dump (I
don't think pg_xlog_location_diff() is available in the older
releases).
postgres=# select pg_xlog_location_diff('4450/7A14F280',
'4441/5E681F38')/(2^30);
?column?
--
60.1980484202504
It'll be great to know what the wals modified..?
You would need something like xlogdump to decipher them. I quickly tried
this and it seems to work against 8.4 version that you are running.
https://github.com/snaga/xlogdump
Download the source code, compile and run it against one of the most
recent
WAL files in the cluster against which you ran pg_dump. You would need
to
set PATH to contain the pg_config of the server you are running. Please
post
the output.
Thanks,
Pavan
Here you go:
## last WAL
$ xlogdump -S /dbpool/data/pg_xlog/00014450007A
/dbpool/data/pg_xlog/00014450007A:
Unexpected page info flags 0003 at offset 0
Skipping unexpected continuation record at offset 0
ReadRecord: record with zero len at 17488/7A14F310
Unexpected page info flags 0001 at offset 15
Skipping unexpected continuation record at offset 15
Unable to read continuation page?
** maybe continues to next segment **
---
TimeLineId: 1, LogId: 17488, LogSegment: 122
Resource manager stats:
[0]XLOG : 3 records, 120 bytes (avg 40.0 bytes)
checkpoint: 3, switch: 0, backup end: 0
[1]Transaction: 0 record, 0 byte (avg 0.0 byte)
commit: 0, abort: 0
[2]Storage : 0 record, 0 byte (avg 0.0 byte)
[3]CLOG : 0 record, 0 byte (avg 0.0 byte)
[4]Database : 0 record, 0 byte (avg 0.0 byte)
[5]Tablespace: 0 record, 0 byte (avg 0.0 byte)
[6]MultiXact : 0 record, 0 byte (avg 0.0 byte)
[7]Reserved 7: 0 record, 0 byte (avg 0.0 byte)
[8]Reserved 8: 0 record, 0 byte (avg 0.0 byte)
[9]Heap2 : 2169 records, 43380 bytes (avg 20.0 bytes)
[10]Heap : 0 record, 0 byte (avg 0.0 byte)
ins: 0, upd/hot_upd: 0/0, del: 0
[11]Btree : 0 record, 0 byte (avg 0.0 byte)
[12]Hash : 0 record, 0 byte (avg 0.0 byte)
[13]Gin : 0 record, 0 byte (avg 0.0 byte)
[14]Gist : 0 record, 0 byte (avg 0.0 byte)
[15]Sequence : 0 record, 0 byte (avg 0.0 byte)
Backup block stats: 2169 blocks, 16551816 bytes (avg 7631.1 bytes)
I think both my theories seem to be holding up. Heap2 resource manager is
used only for vacuum freeze, lazy vacuum or HOT prune. Given your access
pattern, I bet its the third activity that kicking in on your database. You
got many pages with dead tuples and they are getting cleaned at the first
opportunity, which happens to be the pg_dump thats run immediately after the
server restart. This is seen by all 2169 WAL records in the file being
attributed to the Heap2 RM above.
Whats additionally happening is each of these records are on different heap
pages. The cleanup activity dirties those pages. Since each of these pages
is being dirtied for the first time after a recent checkpoint and
full_page_writes is turned ON, entire page is backed up in the WAL record.
You can see the exact number of backup blocks in the stats above.
I don't think we have any mechanism to control or stop HOT from doing what
it wants to do, unless you are willing to run a modified server for this
reason. But you can at least bring down the WAL volume by turning
full_page_writes OFF.
Thanks,
Pavan
Great. Finally got some light on this. I'll disable full_page_writes
on my next backup and will post back results tomorrow. Thanks.
Results with full_page_writes disabled:
pg_controldata right after cluster start:
Latest checkpoint location: 4469/B8352EB8
Prior checkpoint location:4469/B5EAE428
Latest checkpoint's REDO location:4469/B8352EB8
Latest checkpoint's TimeLineID: 1
Latest checkpoint's NextXID
Re: [HACKERS] [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
You may disable full_page_writes, but as you can see from my previous post, disabling it did not do the trick. My zfs' USED property continues to increase. On Wed, Oct 17, 2012 at 3:55 PM, ichbinrene rene.romer...@gmail.com wrote: I'm experiencing the exact same issue: PostgreSQL 9.1.6 on i686-pc-linux-gnu, compiled by gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4), 32-bit CentOS release 6.3 (Final) I might also turn full_page_writes off but I fear for data integrity in case of a crash . -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-7521-Cannot-disable-WAL-log-while-using-pg-dump-tp5722846p5728727.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- Sent via pgsql-bugs mailing list (pgsql-b...@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Calling Matlab function from Postgres
I'm trying to call MATLAB functions from PostgreSQL. I was trying to use Joshua Kaplan's java MATLAB control. I install my jar file which in turn calls MATLAB to run my algorithm, but get the error message ERROR: java.lang.NoClassDefFoundError: matlabcontrol/RemoteMatlabProxyFactory when I call the java function. I saw where DerTech LLC developed a MATLAB interface for PostgreSQL, but their web site seems to be gone. Does anyone either have an idea of how to solve my error or have a copy of the code that DerTech developed for the interface? Thank you, Susan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Insert query hangs
Hi all, We have a table in a database DB1 with name Test. We imported this database from another machine. When I fire insert statement it is going in the hang state. Then I created another table with same structure and with same data within it as in table Test. Then I fired the insert statement. It is working fine. I am not able find the reason for this. Can you please help me out on this. This scenario easily reproducible. I have a standalone system and postgresql 9.1 installed on it. Regards Tarkeshwar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] FW: [postgres-discuss] Insert query hangs
I have the hang issue in Postgres, When I am going to insert into record in a table. Table structure is enclosed in the discussion. Also we found the issue with unique indexes. When I removed the unique index insert operation is working fine. I need help from this core group that weather this is the bug in the Postgres code or we are using unique index wrongly. Regards Tarkeshwar From: Niklas Andersson Sent: 09 July 2014 18:21 To: M Tarkeshwar Rao; Leo Zhou; postgres-disc...@mailman.lmera.ericsson.se Subject: RE: [postgres-discuss] Insert query hangs I wouldn't advice you to drop the indexes in a production environment, as they are usually very important to get fast queries. Your index doesn't seem to be of much use though, as it looks like you are only indexing one single column that is an integer. It seems as it is not needed. Usually you use indexes with two or more columns to speed up queries, or you join on those columns. If you want to make sure that that column is unique, I would advice you to define it as a primary key. You could also use the keyword unique, but in this case I would prefer to define it as a primary key. Then in order to always get a new, unique integer as a primary key, I would suggest you have a look at CREATE SEQUENCE. The syntax comes from how Oracle does it and it works very nice [1] But, this doesn't explain why your current index is causing problems, becuase it _shouldnt_ ;-/ I think you would need some tools to have a check on the server load. Or have a look at how EXPLAIN works, Unfortunately I don't have that deep competence :-( [1] http://www.postgresql.org/docs/8.1/static/sql-createsequence.html Regards, Niklas From: M Tarkeshwar Rao Sent: Wednesday, 09 July 2014 2:29 PM To: Niklas Andersson; Leo Zhou; postgres-disc...@mailman.lmera.ericsson.semailto:postgres-disc...@mailman.lmera.ericsson.se Subject: RE: [postgres-discuss] Insert query hangs What should I do resolve this issue? Change the structure of Table or I should not create the index. From: Niklas Andersson Sent: 09 July 2014 17:58 To: M Tarkeshwar Rao; Leo Zhou; postgres-disc...@mailman.lmera.ericsson.semailto:postgres-disc...@mailman.lmera.ericsson.se Subject: RE: [postgres-discuss] Insert query hangs Yes, and the more data, the longer it takes to rebuild the index. This is why you drop the indexes during certain copy operations, if you have indexes enabled the copy would take forever. Regards, Niklas From: M Tarkeshwar Rao Sent: Wednesday, 09 July 2014 2:22 PM To: Niklas Andersson; Leo Zhou; postgres-disc...@mailman.lmera.ericsson.semailto:postgres-disc...@mailman.lmera.ericsson.se Subject: RE: [postgres-discuss] Insert query hangs Fine now I understand why it is taking time. Is it possible that insert operation will take time when unique index is already created on the table and table has some data within it? From: Niklas Andersson Sent: 09 July 2014 17:20 To: M Tarkeshwar Rao; Leo Zhou; postgres-disc...@mailman.lmera.ericsson.semailto:postgres-disc...@mailman.lmera.ericsson.se Subject: RE: [postgres-discuss] Insert query hangs Can this be of help [1]? [1] http://www.postgresql.org/docs/9.2/static/sql-createindex.html#SQL-CREATEINDEX-CONCURRENTLY Regards, Niklas From: M Tarkeshwar Rao Sent: Wednesday, 09 July 2014 1:41 PM To: Niklas Andersson; Leo Zhou; postgres-disc...@mailman.lmera.ericsson.semailto:postgres-disc...@mailman.lmera.ericsson.se Subject: RE: [postgres-discuss] Insert query hangs CREATE TABLE eventlogentry ( tableindex integer, object character varying(80), method character varying(80), bgwuser character varying(80), time character(23), realuser character varying(80), host character varying(80), application character varying(80) ) WITH ( OIDS=FALSE ) TABLESPACE mmdata; ALTER TABLE eventlogentry OWNER TO mmsuper; GRANT ALL ON TABLE eventlogentry TO mmsuper; GRANT SELECT ON TABLE eventlogentry TO report; CREATE UNIQUE INDEX ind1_eventlogentry ON eventlogentry USING btree (tableindex ) TABLESPACE mmindex; I am sharing the table structure. When we removed the unique index it is working fine. And when created normal index(not unique) it is working fine. After removing unique index we tried to recreate it but it is giving following infinite logs : concurrent insert in progress within table eventlogentry caveat when building a unique index concurrently is that the uniqueness constraint is already being enforced against other transactions when the second table scan begins Regards Tarkeshwar From: Niklas Andersson Sent: 09 July 2014 16:10 To: M Tarkeshwar Rao; Leo Zhou; postgres-disc...@mailman.lmera.ericsson.semailto:postgres-disc...@mailman.lmera.ericsson.se Subject: RE: [postgres-discuss] Insert query hangs Hi, You have some info on checking on corrupt tables here [1
[HACKERS] issue in postgresql 9.1.3 in using arrow key in Solaris platform
Hi all, We are facing following issue in postgresql 9.1.3 in using arrow key in Solaris platform. Can you please help us to resolve it or any new release has fix for this or any workaround for this? issue: psql client generates a core when up arrow is used twice. Platfrom: Solaris X86 Steps to reproduce: = 1. Login to any postgres database 2. execute any quer say \list 3. press up arrow twice. 4. segmentation fault occurs and core is generated. Also session is terminated. PLease find example below # ./psql -U super -d mgrdb Password for user super: psql (9.1.3) Type help for help. mgrdb=# \l List of databases Name| Owner | Encoding | Collate |Ctype| Access privileg es ---+--+--+-+-+-- - mgrdb | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres + | | | | | postgres=CTc/post gres template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres + | | | | | postgres=CTc/post gres (4 rows) mgrdb=# mgrdb=# select count(1) from operator_msm;Segmentation Fault (core dumped) Regards Tarkeshwar
Re: [HACKERS] Postgres TR for missing chunk
Hello Friends, Can you please tell me the how can I track the which bugs are fixed in which release and when they will be fixed, If I want to track the analysis and status of the bug raised on Postgres. Can I get this information. From last few days we are struggling with following issue: 1. Additionally we found that few operations on this table is getting failed like select or truncate and a more specific error is thrown as per below:- ERROR: missing chunk number 0 for toast value 54787 in pg_toast_2619 ** Error ** We done all the suggested things on Google but not able to resolve it. I want to know how to avoid this issue? Can you please suggest upto when following bugs will be resolved? There are the known Bug on Postgres. Bugs detail are mentioned below. BUG #9187: corrupt toast tables http://www.postgresql.org/message-id/30154.1392153...@sss.pgh.pa.us http://www.postgresql.org/message-id/cafj8praufpttn5+ohfqpbcd1jzkersck51uakhcwd8nt4os...@mail.gmail.com http://www.postgresql.org/message-id/20140211162408.2713.81...@wrigleys.postgresql.org BUG #7819: missing chunk number 0 for toast value 1235919 in pg_toast_35328 http://www.postgresql.org/message-id/C62EC84B2D3CF847899CCF4B589CCF70B20AA08F@BBMBX.backbone.local Thanks !! Tarkeshwar
Re: [HACKERS] Postgres TR for missing chunk
Hello friends, Thanks for your useful inputs. We are facing this issue and want to analyse this through logging. can you please share a sample Postgres config file to enable max logging with syslog support? What should be the debug level so that I can capture the failure information? Regards Tarkeshwar -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: 16 December 2014 22:25 To: Jaime Casanova Cc: M Tarkeshwar Rao; PostgreSQL-development Subject: Re: [HACKERS] Postgres TR for missing chunk Jaime Casanova ja...@2ndquadrant.com writes: You know, that toast table name ringed a bell. Look at this thread maybe this is your problem, and if it is then is already fixed and you should update. http://www.postgresql.org/message-id/12138.1336019...@sss.pgh.pa.us That was about transient failures though, not persistent ones, which is what the OP seems to be claiming he's getting. Btw, when giving a bug report you should start but saying your PostgreSQL's version and explain what you did based on Google's wisdom Yeah. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] can you have any idea about toast missing chunk issu resolution
Hi all, We are getting following error message on doing any action on the table like(Select or open from pgadmin). Please suggest. ERROR: missing chunk number 0 for toast value 54787 in pg_toast_2619 ** Error ** ERROR: missing chunk number 0 for toast value 54787 in pg_toast_2619 SQL state: XX000 CREATE TABLE mm_activealarm ( alarm_id integer NOT NULL, source_address character varying(255) NOT NULL, alarm_instance_id integer NOT NULL, alarm_raise_time bigint, alarm_update_time bigint, alarm_cease_time bigint, alarm_count integer, alarm_severity integer NOT NULL, source_type character varying(40) NOT NULL, alarm_state integer NOT NULL, event_type integer, notification_id integer NOT NULL, probable_cause integer NOT NULL, specific_problem integer NOT NULL, alarm_additional_text character varying(10240), alarm_ack_time bigint, alarm_ack_user character varying(100) NOT NULL, alarm_ack_system character varying(100) NOT NULL, alarm_proposed_repair_action character varying(10240) NOT NULL, CONSTRAINT mm_activealarm_pk PRIMARY KEY (alarm_id, source_address) USING INDEX TABLESPACE mgrdata ) WITH ( OIDS=FALSE ) TABLESPACE mgrdata; ALTER TABLE ss_activealarm OWNER TO ss_super; Regards Tarkeshwar
Re: [HACKERS] [Pgbuildfarm] buildfarm olinguito vs python
On Mon, May 25, 2015 at 04:37:11PM -0400, Tom Lane wrote: Davin M. Potts da...@discontinuity.net writes: At Alvaro's suggestion, I'm forwarding my questions (see email thread further below) to this list. In short, building of PL/Python has been disabled on OpenBSD since 2005. The errors seen at the time (on OpenBSD and FreeBSD, both) may or may not still be an issue with modern builds of Python. Can someone point me to examples of how these errors manifested themselves? Has Peter Eisentraut or others poked at this recently enough to tell me this is not worth chasing down? I'm fairly sure that the errors were blatantly obvious, ie failure to build or failure to pass even basic regression tests. If you can tell us that that configure check is inappropriate on modern openbsd, I'd be happy to see it go. With Tom's bit of encouragement, I removed these four lines from the config/python.m4 file: case $host_os in openbsd*) AC_MSG_ERROR([threaded Python not supported on this platform]) ;; esac Though in truth, I did take the shortcut of not actually regenerating the configure file from it and instead I simply commented out those same exact four lines from the configure and did a proper clean build of HEAD. The net result is that everything passed from configure through check and the contrib checks too -- to the extent that we have tests for PL/Python, all of those tests pass with Python 2.7.10 on OpenBSD (olinguito in the buildfarm). To verify that I hadn't done something boneheaded, I manually connected with psql and did a couple of CREATE FUNCTION ... LANGUAGE plpythonu; and exercised those new functions successfully. PL/Python appears happy and healthy on OpenBSD, as best as I can tell from the test suites passing and my own manual poking. I suggest those four lines specific to OpenBSD can be removed from the configure check. Though I have only verified this against HEAD, if this change is made across all the active branches, we will see its impact on olinguito's buildfarm-builds of those branches too. Or, I can walk through and manually test each branch if that's preferred? Davin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm] buildfarm olinguito vs python
On Mon, May 25, 2015 at 04:35:11PM -0300, Alvaro Herrera wrote: Davin M. Potts wrote: At Alvaro's suggestion, I'm forwarding my questions (see email thread further below) to this list. In short, building of PL/Python has been disabled on OpenBSD since 2005. The errors seen at the time (on OpenBSD and FreeBSD, both) may or may not still be an issue with modern builds of Python. Can someone point me to examples of how these errors manifested themselves? Has Peter Eisentraut or others poked at this recently enough to tell me this is not worth chasing down? http://www.postgresql.org/message-id/flat/20061015211642.gf...@nasby.net#20061015211642.gf...@nasby.net http://www.postgresql.org/message-id/flat/42f0d5b1.2060...@dunslane.net#42f0d5b1.2060...@dunslane.net Slightly ironic is that at the moment I received this email from Álvaro, I was sitting across from Jim Nasby (see first link) in a coffeeshop. Davin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm] buildfarm olinguito vs python
On Mon, May 25, 2015 at 04:26:02PM -0400, Andrew Dunstan wrote: On 05/25/2015 03:35 PM, Andrew Dunstan wrote: On 05/25/2015 12:38 PM, Davin M. Potts wrote: At Alvaro's suggestion, I'm forwarding my questions (see email thread further below) to this list. In short, building of PL/Python has been disabled on OpenBSD since 2005. The errors seen at the time (on OpenBSD and FreeBSD, both) may or may not still be an issue with modern builds of Python. Can someone point me to examples of how these errors manifested themselves? Has Peter Eisentraut or others poked at this recently enough to tell me this is not worth chasing down? Thanks for any and all pointers. I'm inclined just to remove this in config/python.m4 and see what happens: case $host_os in openbsd*) AC_MSG_ERROR([threaded Python not supported on this platform]) ;; esac Oh, I see see what's happening, kinda. Is your threaded python linked against libc or libc_r? It's built against libc -- I don't think we have libc_r on OpenBSD or if it used to be there, it looks to be gone now. Davin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Pgbuildfarm] buildfarm olinguito vs python
At Alvaro's suggestion, I'm forwarding my questions (see email thread
further below) to this list.
In short, building of PL/Python has been disabled on OpenBSD since 2005.
The errors seen at the time (on OpenBSD and FreeBSD, both) may or may
not still be an issue with modern builds of Python. Can someone point
me to examples of how these errors manifested themselves? Has Peter
Eisentraut or others poked at this recently enough to tell me this is
not worth chasing down?
Thanks for any and all pointers.
Davin
- Forwarded message from Davin M. Potts da...@discontinuity.net -
Date: Mon, 25 May 2015 11:12:53 -0500
From: Davin M. Potts da...@discontinuity.net
To: Alvaro Herrera alvhe...@2ndquadrant.com
Cc: Andrew Dunstan and...@dunslane.net, pgbuildf...@lists.commandprompt.com
pgbuildf...@lists.commandprompt.com
Subject: Re: [Pgbuildfarm] buildfarm olinguito vs python
I have rebuilt python to ensure that the relatively new dependency on
the shared-lib is satisfied. This addresses the previous error that
terminated the configure step with the complaint that the shared-lib was
not found.
However, a new complaint is now encountered, complaining that
threaded Python not supported on this platform despite the configure
successfully verifying that Python was indeed compiled with thread
support. Looking in python.m4, I see specifically:
---
# threaded python is not supported on OpenBSD
AC_MSG_CHECKING(whether Python is compiled with thread support)
pythreads=`${PYTHON} -c import sys; print(int('thread' in
sys.builtin_module_na
mes))`
if test $pythreads = 1; then
AC_MSG_RESULT(yes)
case $host_os in
openbsd*)
AC_MSG_ERROR([threaded Python not supported on this platform])
---
Looking at the history on python.m4, this has been present for quite a
while, originating back to Bruce Momjian's commits from 2005.
I was convinced that I was able to successfully use the PL/Python
interface on OpenBSD in the past though admittedly I've exclusively
been doing so on other platforms in recent years.
The nature of the errors that were seen back in 2005/2006 are not easily
found. Can somebody point me in the right direction? Or have folks
like Peter Eisentraut tested this recently to verify that the problem
persists with modern builds of Python on OpenBSD? (I can always disable
this test in the configure to see it build but it might not prove much
if I don't try to provoke the previously seen issues.)
Davin
On Tue, May 19, 2015 at 10:55:40AM -0300, Alvaro Herrera wrote:
Davin M. Potts wrote:
It may help to understand that olinguito uses the same build of python
(same directory) for happily building all the REL9_X branches and only
HEAD seems to have this problem. I have tried cleaning everything (not
just cache but blowing away the directories and doing a clean git pull
with new, fresh directories) but HEAD's problems persist. If you look
back in the history, HEAD used to build happily on this system with this
python build. This seems to support the idea that we are looking at a
regression.
It's a deliberate change, not a regression. See here:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=d664a10f9623fd2198b257e513bce849d439a773
--
Álvaro Herrerahttp://www.twitter.com/alvherre
- End forwarded message -
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Float output formatting options
HI All, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I am confused about this patch. I don't see extra_float_digits defined anywhere. Am I missing a patch ? Probably! :) The definition of extra_float_digits was made in float.c and the diff was sent to the list and Tom before. I think its the one Tom refers below. There were diff's to four files: src/backend/utils/adt/float.c src/backend/utils/misc/guc.c src/bin/psql/tab-complete.c src/backend/utils/misc/postgresql.conf.sample Evidently. I have the patch and was planning to apply it myself as soon as Pedro does something with the geometry types... Lots of mail in the list! ;) Its done. The diff file to src/backend/utils/adt/geo_ops.c (to handle the gemetry types) was sent some days ago. Its the one in the message where Bruce says that extra_float_digits is not defined anywhere. If you want I can send in the diff's again. Best regards, Pedro regards, tom lane -- -- Pedro Miguel Frazao Fernandes Ferreira Universidade do Algarve Faculdade de Ciencias e Tecnologia Campus de Gambelas 8000-117 Faro Portugal Tel./Fax: (+351) 289 800950 / 289 819403 http://w3.ualg.pt/~pfrazao ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Geometry regression tests (was Re: [HACKERS] Float output formatting
Tom Lane wrote: Pedro M. Ferreira [EMAIL PROTECTED] writes: [ patch for extra_float_digits ] I've applied this patch along with followup changes to pg_dump (it sets extra_float_digits to 2 to allow accurate dump/reload) and the geometry regression test (it sets extra_float_digits to -3). I find that two geometry 'expected' files are now sufficient to cover all the platforms I have available to test. (We'd only need one, if everyone displayed minus zero as '-0', but some platforms print '0'.) I tested on HPUX 10.20 (HPPA), Red Hat Linux 8.0 (Intel), Mac OS X 10.2.1 and LinuxPPC (PPC). I'd be interested to hear results of testing CVS tip (now 7.4devel) on other platforms. Does geometry pass cleanly for you? Yes! :) All tests passed on a dual AMD Athlon MP with Debian GNU/Linux 3.0 (Woody), kernel 2.4.18-5. Tested with a snapshot downloaded yesterday. Best regards, Pedro M. Ferreira regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
