Re: [BUGS] BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram
On Wed, Aug 22, 2012 at 10:24 PM, Tom Lane wrote: > It looks sane to me in a quick once-over (bearing in mind I can't test > it). Well, bad news. Dave built an installer off the 9.1 tip, we provided it to the customer, and they can still reproduce the problem. It's not clear whether we've narrowed the scope of the problem without eliminating it, or whether that fix just didn't help at all. But they still can't reproduce it on 9.2. This suggests that there's some other difference between 9.1 and 9.2 that is relevant here, but I'm not sure what. Any ideas? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [ADMIN] Repeatable crash in pg_dump (with -d2 info)
On Mon, Aug 27, 2012 at 9:58 AM, Bruce Momjian wrote: > On Tue, Jan 17, 2012 at 04:46:50PM -0500, David Schnur wrote: >> I finally had time to test this further on a variety of systems, and was >> unable >> to reproduce on any non-Windows platform. The dump even works fine on >> Windows >> XP; just not Windows 7. >> >> This prompted me to do a little more research, and this time I found this >> thread from Sept. 2011: >> >> http://postgresql.1045698.n5.nabble.com/ >> BUG-6233-pg-dump-hangs-with-Access-Violation-C005-td4851598.html >> >> From Tom Lane in the above thread: >> >> >> Hmm. I can see how that would happen if you're using one of the Windows >> environments wherein malloc's done inside libpq have to be free'd inside >> libpq. (The PQExpBuffer support code is in libpq...) >> >> >> >> However, the flaw in that explanation is that it would basically mean >> pg_dump doesn't work at all on Windows, at least not if you have any >> user-defined functions, and probably some other cases too because there >> seem to be multiple instances of the dubious coding. It's a bit hard to >> believe that nobody's noticed that before. >> >> >> This appears to describe exactly the issue I'm encountering, and my build is >> in >> fact linked against the static runtime. I guess the reason this hasn't come >> up >> sooner is because most Windows users either use the 'official' binaries >> rather >> than compiling from source, or link against the dynamic runtime. >> >> Is this something I could expect to be fixed in the near future, or is it >> enough of an edge case that I should come up with some solution or >> work-around >> on my own? Thanks, > > Late reply, but I don't see any way we could fix this easily. To me it seems like mostly a case of chasing down all the places where this happens. It's not impossible to do; it's just a bunch of work that nobody's gotten excited about doing yet. We've fixed similar issues in many other cases, IIUC. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6412: psql & fe-connect truncate passwords
On Mon, Aug 27, 2012 at 12:33 PM, Alvaro Herrera wrote: > Excerpts from Bruce Momjian's message of lun ago 27 12:12:25 -0400 2012: >> >> Did we want this patch applied? Not enough demand? > > I think it should be in the next commitfest for discussion. I don't see > any reason to reject it. I think it needs some fixes, though, so a > formal review process is called for. +1. I added it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Minor inheritance/check bug: Inconsistent behavior
On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila wrote: > AFAICT during Update also, it doesn't contain useful. The only chance it > would have contain something useful is when it goes for EvalPlanQual and > then again comes to check for constraints. However these attributes get > filled in heap_update much later. > > So now should the fix be that it returns an error for system column > reference except for OID case? +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7514: postgres -k no longer works with spaces in the path
On Wed, Sep 5, 2012 at 8:55 PM, Tom Lane wrote: > Peter Eisentraut writes: >> Maybe it would be easier if multiple -k options accumulated. > > After further thought I'm not very enamored of that concept. We've made > considerable compromises to ensure that every postmaster command-line > option corresponds exactly to some GUC parameter; it does not seem to me > that -k is important enough to deserve an exception. > > However, it occurs to me that Murray's original complaint about spaces > in -k pathnames could be dealt with via very narrow changes in > SplitDirectoriesString. That function was modeled on > SplitIdentifierString, with perhaps not enough thought about the > differences between identifiers and pathnames. In particular, I suggest > that there's no need to reject embedded spaces in pathnames, and plenty > of systems on which it's important not to. (Think "Program Files" on > Windows, for instance.) It probably still makes sense to trim leading > and trailing whitespace, but let's allow embedded spaces. > > If we did that, the new code would be incompatible with the old only for > paths including commas, leading double quotes, or leading/trailing > whitespace. I submit that all of those cases are pretty uncommon, > especially compared to embedded space. That seems reasonable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
On Wed, Sep 5, 2012 at 9:57 AM, wrote: > The following bug has been logged on the website: > > Bug reference: 7521 > Logged by: Boy de Laat > Email address: b...@atsc.nl > PostgreSQL version: 9.1.4 > Operating system: CentOS 6.2 x86_64 > Description: > > I've setup some slave replication and just to be sure i use pg_dump as a > backup mechanism besides replication. But when the pg_dump command is issued > much WAL logs will be generated and this is causing my slave to stop > replicating because it is to far behind. > > So it would be nice if there is an option to disable WAL logging while > running pg_dump. pg_dump doesn't modify any data, so I don't see how it could be causing WAL logs to get generated. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
Robert Haas writes: > On Wed, Sep 5, 2012 at 9:57 AM, wrote: >> So it would be nice if there is an option to disable WAL logging while >> running pg_dump. > pg_dump doesn't modify any data, so I don't see how it could be > causing WAL logs to get generated. Doesn't hint-bit setting cause WAL traffic these days? Mind you, I think this request is entirely ill-considered. Not writing out the hint bits is not going to be a win in the long run. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [ADMIN] Repeatable crash in pg_dump (with -d2 info)
Robert Haas writes: > On Mon, Aug 27, 2012 at 9:58 AM, Bruce Momjian wrote: >> From Tom Lane in the above thread: >>> Hmm. I can see how that would happen if you're using one of the Windows >>> environments wherein malloc's done inside libpq have to be free'd inside >>> libpq. (The PQExpBuffer support code is in libpq...) >> Late reply, but I don't see any way we could fix this easily. > To me it seems like mostly a case of chasing down all the places where > this happens. It's not impossible to do; it's just a bunch of work > that nobody's gotten excited about doing yet. We've fixed similar > issues in many other cases, IIUC. Well, the problem with what I suspect you're thinking of is that even after we fixed all the existing trouble spots, it would keep on breaking. Unless we found some mechanical way to warn about unsafe coding; which in itself would be more work than I want to put into this. However, a plan B occurs to me: what about preventing pg_dump from using libpq's copy of PQExpBuffer? IIUC, a copy of the PQExpBuffer code statically linked into pg_dump would be free of this problem. There's not so much code there that this would be an intolerable price to pay. (Besides, we could probably arrange for the extra copy to happen only on Windows.) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
On Thu, Sep 6, 2012 at 3:55 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Sep 5, 2012 at 9:57 AM, wrote: >>> So it would be nice if there is an option to disable WAL logging while >>> running pg_dump. > >> pg_dump doesn't modify any data, so I don't see how it could be >> causing WAL logs to get generated. > > Doesn't hint-bit setting cause WAL traffic these days? I sure as heck don't think so. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
On 06.09.2012 13:07, Robert Haas wrote: On Thu, Sep 6, 2012 at 3:55 PM, Tom Lane wrote: Robert Haas writes: On Wed, Sep 5, 2012 at 9:57 AM, wrote: So it would be nice if there is an option to disable WAL logging while running pg_dump. pg_dump doesn't modify any data, so I don't see how it could be causing WAL logs to get generated. Doesn't hint-bit setting cause WAL traffic these days? I sure as heck don't think so. It does not. HOT page pruning does, however. It could be that.. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
On Thu, Sep 6, 2012 at 4:08 PM, Heikki Linnakangas wrote: > On 06.09.2012 13:07, Robert Haas wrote: pg_dump doesn't modify any data, so I don't see how it could be causing WAL logs to get generated. >>> >>> Doesn't hint-bit setting cause WAL traffic these days? >> >> I sure as heck don't think so. > > It does not. HOT page pruning does, however. It could be that.. True, but wouldn't you have to be fantastically unlucky for that to amount to anything material? I mean, what are the chances of that happening on more than a very small percentage of blocks? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
Heikki Linnakangas writes: > On 06.09.2012 13:07, Robert Haas wrote: >> On Thu, Sep 6, 2012 at 3:55 PM, Tom Lane wrote: >>> Doesn't hint-bit setting cause WAL traffic these days? >> I sure as heck don't think so. > It does not. HOT page pruning does, however. It could be that.. Sorry, I was thinking of the freeze case, which is also somewhat unlikely --- but if it were happening, it could easily happen on most/all pages of a table. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
At the time my backup starts i see much WAL logs being generated? Met vriendelijke groet, Boy de Laat Verzonden via iPhone Op 6 sep. 2012 om 21:44 heeft "Robert Haas" het volgende geschreven: > On Wed, Sep 5, 2012 at 9:57 AM, wrote: > > The following bug has been logged on the website: > > > > Bug reference: 7521 > > Logged by: Boy de Laat > > Email address: b...@atsc.nl > > PostgreSQL version: 9.1.4 > > Operating system: CentOS 6.2 x86_64 > > Description: > > > > I've setup some slave replication and just to be sure i use pg_dump as a > > backup mechanism besides replication. But when the pg_dump command is issued > > much WAL logs will be generated and this is causing my slave to stop > > replicating because it is to far behind. > > > > So it would be nice if there is an option to disable WAL logging while > > running pg_dump. > > pg_dump doesn't modify any data, so I don't see how it could be > causing WAL logs to get generated. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram
Robert Haas writes: > Well, bad news. Dave built an installer off the 9.1 tip, we provided > it to the customer, and they can still reproduce the problem. It's > not clear whether we've narrowed the scope of the problem without > eliminating it, or whether that fix just didn't help at all. But they > still can't reproduce it on 9.2. This suggests that there's some > other difference between 9.1 and 9.2 that is relevant here, but I'm > not sure what. Any ideas? I guess that's reassuring, in a way: it means that all the thrashing about we did to get the latch-ified stats collector logic to work on Windows actually brought us to a better place. However, for the purposes of fixing the older branches, it's not so nice. I think it means that we'd have to back-port some or all of the latch-related changes in pgstat.c: commit 966970ed636586b80739c0d21aec7561f0fafedd commit f1ca51549e9e7045a2db95a61744334f1dbb4d64 commit d461d0502b6e20c6d4ec326ba2faec8212fd5dee commit 9b63e9869ffaa4d6d3e8bf45086a765d8f310f1c and maybe even some of these fixes in win32_latch.c: commit e42a21b9e6c9b9e6346a34b62628d48ff2fc6ddf commit f40022f1adaeff85b01d98fea38cf5aa16814aa7 commit 8ebc908c575b3378c9d4096412d16d91d107311c At least, that's where I'd go looking if I were responsible for fixing this, which is a responsibility I disclaim. Looking through this history reminds me how much time I've already wasted on that miserable excuse for an operating system. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
On Thu, Sep 6, 2012 at 4:23 PM, Tom Lane wrote: > Heikki Linnakangas writes: >> On 06.09.2012 13:07, Robert Haas wrote: >>> On Thu, Sep 6, 2012 at 3:55 PM, Tom Lane wrote: Doesn't hint-bit setting cause WAL traffic these days? > >>> I sure as heck don't think so. > >> It does not. HOT page pruning does, however. It could be that.. > > Sorry, I was thinking of the freeze case, which is also somewhat > unlikely --- but if it were happening, it could easily happen on > most/all pages of a table. But that only happens in vacuum, which pg_dump does not do. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
Excerpts from Tom Lane's message of jue sep 06 17:23:07 -0300 2012: > Heikki Linnakangas writes: > > On 06.09.2012 13:07, Robert Haas wrote: > >> On Thu, Sep 6, 2012 at 3:55 PM, Tom Lane wrote: > >>> Doesn't hint-bit setting cause WAL traffic these days? > > >> I sure as heck don't think so. > > > It does not. HOT page pruning does, however. It could be that.. > > Sorry, I was thinking of the freeze case, which is also somewhat > unlikely --- but if it were happening, it could easily happen on > most/all pages of a table. How about secondary effects -- say pg_dump reads a lot of data into buffers that were previously dirty and those get evicted. Could page eviction cause lots of WAL to be emitted? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
On Thu, Sep 6, 2012 at 5:07 PM, Alvaro Herrera wrote: > How about secondary effects -- say pg_dump reads a lot of data into > buffers that were previously dirty and those get evicted. Could page > eviction cause lots of WAL to be emitted? No. Simon's proposed checksum patch would have that effect, but currently no. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
Excerpts from Boy de Laat's message of jue sep 06 17:24:35 -0300 2012: > > At the time my backup starts i see much WAL logs being generated? I guess we'd need to see what the generated WAL logs are, either with xlogdump or XLOG_DEBUG turned on ... -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7516: PL/Perl crash
Marko Tiikkaja writes: > On 03/09/2012 18:06, Tom Lane wrote: >> This might be the wrong theory. You seem to have debug symbols for that >> core dump --- can you tell which of the dereferences in line 3373 >> caused the crash? > The current_call_data->prodesc->fn_readonly one. > Please let me know if I can be of more assistance. Hm, can you show us the contents of the *current_call_data struct? Another thing that seems a bit risky is that plperl_func_handler sets up current_call_data as a pointer to a mostly-zeroed struct and then does assorted things that could throw error. That would leave a dangling value of current_call_data ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7516: PL/Perl crash
I wrote: > Another thing that seems a bit risky is that plperl_func_handler sets up > current_call_data as a pointer to a mostly-zeroed struct and then does > assorted things that could throw error. That would leave a dangling > value of current_call_data ... Meh, scratch that --- I missed that the caller of plperl_func_handler is where there's a PG_TRY block that's responsible for restoring the old value of current_call_data. It would still be interesting to nose around and see what's in *current_call_data, as well as any of the pointed-to data structures that exist. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
On Fri, Sep 7, 2012 at 2:43 AM, Alvaro Herrera wrote: > Excerpts from Boy de Laat's message of jue sep 06 17:24:35 -0300 2012: > > > > At the time my backup starts i see much WAL logs being generated? > > I guess we'd need to see what the generated WAL logs are, either with > xlogdump or XLOG_DEBUG turned on ... > > Can a long running pg_dump transaction have some ill effect on the amount of WAL generation ? It can definitely cause unusual additional bloat if the database is being continuously updated during that period, but not sure it can cause additional WAL. OP probably needs to tell us whats the size of the database, how's the access pattern, how long does it take to dump the entire database and how many more WAL files generated during this process compared to average rate. Thanks, Pavan
[BUGS] BUG #7522: ecpg build error
The following bug has been logged on the website: Bug reference: 7522 Logged by: Radu Ovidiu Email address: ir...@unix-world.org PostgreSQL version: 9.0.9 Operating system: NetBSD Description: Hi, I am trying to build the PostgreSQL 9.0.9 over NetBSD 5.1.2 (64-bit). I got the following error. I tried to compile the 9.1.5 and still the same error. The 8.3.17 and 8.4.11 (are OK) they are compiling with no errors (under the same build script). Cand be this because I am using one of this flags: -O2 -fPIC -m64 ? It should not be because under the same build system I am compiling successfully all other software (includding PostgreSQL 8.x) but the 9.x throws this error. Perhaps you forgot to mention (define) somewhere these variables (ECPGt_string and ECPGt_sqlda) ? The compile error (PostgreSQL 9.x): ... rm -f thread.c && ln -s ../../../src/port/thread.c . gcc -O2 -fPIC -m64 -I/opt/unixw/include -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic -DPIC -DFRONTEND -DUNSAFE_STAT_OK -I. -I../../../src/include -O2 -fPIC -m64 -I/opt/unixw/include -I/opt/unixw/include/libxml2 -I/opt/unixw -I../../../src/port -I../../../src/port -DSO_MAJOR_VERSION=5 -c -o thread.o thread.c -MMD -MP -MF .deps/thread.Po gcc -O2 -fPIC -m64 -I/opt/unixw/include -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic -DPIC -shared -Wl,-x,-soname,libpq.so.5 -o libpq.so.5.3 fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o pqsignal.o fe-secure.o libpq-events.o md5.o ip.o wchar.o encnames.o noblock.o pgstrcasecmp.o thread.o -L../../../src/port -O2 -fPIC -m64 -R/opt/unixw/lib -L/opt/unixw/lib -L/opt/unixw/lib -L/opt/unixw -Wl,--as-needed -Wl,-R'/opt/unixw/lib' -lssl -lcrypto -lcrypt -lpthread rm -f libpq.so.5 ln -s libpq.so.5.3 libpq.so.5 rm -f libpq.so ln -s libpq.so.5.3 libpq.so ar cr libpq.a fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o pqsignal.o fe-secure.o libpq-events.o md5.o ip.o wchar.o encnames.o noblock.o pgstrcasecmp.o thread.o ranlib libpq.a gmake[3]: Leaving directory `/_SRC/pgsql/postgresql-9.0.9/src/interfaces/libpq' gmake[3]: Entering directory `/_SRC/pgsql/postgresql-9.0.9/src/interfaces/ecpg' /opt/unixw/bin/gmake -C include all gmake[4]: Entering directory `/_SRC/pgsql/postgresql-9.0.9/src/interfaces/ecpg/include' gmake[4]: Nothing to be done for `all'. gmake[4]: Leaving directory `/_SRC/pgsql/postgresql-9.0.9/src/interfaces/ecpg/include' /opt/unixw/bin/gmake -C pgtypeslib all gmake[4]: Entering directory `/_SRC/pgsql/postgresql-9.0.9/src/interfaces/ecpg/pgtypeslib' gcc -O2 -fPIC -m64 -I/opt/unixw/include -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic -DPIC -I../include -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/interfaces/libpq -I../../../../src/include -O2 -fPIC -m64 -I/opt/unixw/include -I/opt/unixw/include/libxml2 -I/opt/unixw -DSO_MAJOR_VERSION=3 -c -o numeric.o numeric.c -MMD -MP -MF .deps/numeric.Po gcc -O2 -fPIC -m64 -I/opt/unixw/include -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic -DPIC -I../include -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/interfaces/libpq -I../../../../src/include -O2 -fPIC -m64 -I/opt/unixw/include -I/opt/unixw/include/libxml2 -I/opt/unixw -DSO_MAJOR_VERSION=3 -c -o datetime.o datetime.c -MMD -MP -MF .deps/datetime.Po gcc -O2 -fPIC -m64 -I/opt/unixw/include -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic -DPIC -I../include -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/interfaces/libpq -I../../../../src/include -O2 -fPIC -m64 -I/opt/unixw/include -I/opt/unixw/include/libxml2 -I/opt/unixw -DSO_MAJOR_VERSION=3 -c -o common.o common.c -MMD -MP -MF .deps/common.Po gcc -O2 -fPIC -m64 -I/opt/unixw/include -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic -DPIC -I../include -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/interfaces/libpq -I../../../../src/include -O2 -fPIC -m64 -I/opt/unixw/include -I/opt/unixw/include/libxml2 -I/opt
Re: [BUGS] BUG #7522: ecpg build error
ir...@unix-world.org writes: > I am trying to build the PostgreSQL 9.0.9 over NetBSD 5.1.2 (64-bit). > I got the following error. > I tried to compile the 9.1.5 and still the same error. > The 8.3.17 and 8.4.11 (are OK) they are compiling with no errors (under the > same build script). ECPGt_string is defined in ecpgtype.h in 9.0 and later. I am betting that you have a pre-9.0 copy of that file somewhere where it's being found in preference to the intended version. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Minor inheritance/check bug: Inconsistent behavior
On Friday, September 07, 2012 12:20 AM Amit Kapila wrote: On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila wrote: >> AFAICT during Update also, it doesn't contain useful. The only chance it >> would have contain something useful is when it goes for EvalPlanQual and >> then again comes to check for constraints. However these attributes get >> filled in heap_update much later. > >> So now should the fix be that it returns an error for system column >> reference except for OID case? > +1. I will start working on preparing a patch for the fix, if any problems, I will discuss. With Regards, Amit Kapila. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7522: ecpg build error
Yes, you are right. After I checked the sha1 of file I found was modified. It was downloaded from other location than postgresql and was named postgresql-9.0.9.tar.bz2, but was not the final. After I downloaded the original from postgresql.org everything works smooth. Thanks, Radu On Sep 7, 2012, at 7:59, Tom Lane wrote: > ir...@unix-world.org writes: >> I am trying to build the PostgreSQL 9.0.9 over NetBSD 5.1.2 (64-bit). >> I got the following error. >> I tried to compile the 9.1.5 and still the same error. >> The 8.3.17 and 8.4.11 (are OK) they are compiling with no errors (under the >> same build script). > > ECPGt_string is defined in ecpgtype.h in 9.0 and later. I am betting > that you have a pre-9.0 copy of that file somewhere where it's being > found in preference to the intended version. > >regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
On Thu, Sep 6, 2012 at 8:48 PM, Pavan Deolasee wrote: > > > On Fri, Sep 7, 2012 at 2:43 AM, Alvaro Herrera > wrote: >> >> Excerpts from Boy de Laat's message of jue sep 06 17:24:35 -0300 2012: >> > >> > At the time my backup starts i see much WAL logs being generated? >> >> I guess we'd need to see what the generated WAL logs are, either with >> xlogdump or XLOG_DEBUG turned on ... >> > > Can a long running pg_dump transaction have some ill effect on the amount of > WAL generation ? It can definitely cause unusual additional bloat if the > database is being continuously updated during that period, but not sure it > can cause additional WAL. > > OP probably needs to tell us whats the size of the database, how's the > access pattern, how long does it take to dump the entire database and how > many more WAL files generated during this process compared to average rate. > > Thanks, > Pavan > DB size: 3400509331216 (3.09TB) Full db pg_dump takes around 20 to 21hrs with options "-Fc -Z 1" pg_dump size: 391161548000 (364.3GB) checkpoint_segments = 80 #checkpoint_timeout = 5min (default) #checkpoint_completion_target = 0.5 (default) version: PostgreSQL 8.4.12 >From pg_controldata right after starting the instance: Latest checkpoint location: 4441/5E681F38 Prior checkpoint location:4441/5E67D140 Latest checkpoint's REDO location:4441/5E681F38 Latest checkpoint's TimeLineID: 1 Latest checkpoint's NextXID: 0/419543166 Latest checkpoint's NextOID: 653512568 Latest checkpoint's NextMultiXactId: 107873 Latest checkpoint's NextMultiOffset: 219841 >From pg_controldata after pg_dump: Latest checkpoint location: 4450/7A14F280 Prior checkpoint location:4450/7A14E018 Latest checkpoint's REDO location:4450/7A14F280 Latest checkpoint's TimeLineID: 1 Latest checkpoint's NextXID: 0/419543166 Latest checkpoint's NextOID: 653512568 Latest checkpoint's NextMultiXactId: 107873 Latest checkpoint's NextMultiOffset: 219841 Background: The cluster used for the backup was cloned from a zfs snapshot (taken while the db is running without issuing pg_start/stop_backup). WALs are replayed and cluster starts up usually in a minute or so. After pg_dump, the clone's zfs USED property value is 285G -- that's how huge block changes have grown for the entirety of the pg_dump process. Yesterday's backup clone was 280G. Aside from pg_dump, a cron job issues a 'select * from pg_stat_activity' every 9mins. The instance is cloned solely for backup purposes with zero modifications and autovacuum disabled. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
