Re: [HACKERS] Add min and max execute statement time in pg_stat_statement

Hi Rajeev, (2014/01/29 17:31), Rajeev rastogi wrote: No Issue, you can share me the test cases, I will take the performance report. Attached patch is supported to latest pg_stat_statements. It includes min, max, and stdev statistics. Could you run compiling test on your windows enviroments? I

Re: [HACKERS] narwhal and PGDLLIMPORT

(2014/02/12 3:03), Tom Lane wrote: > Hiroshi Inoue writes: >> (2014/02/09 8:06), Andrew Dunstan wrote: >>> Yeah. Incidentally, we didn't quite get rid of dlltool for Cygwin. We >>> did get rid of dllwrap. But I agree this is worth trying for Mingw. > >> I tried MINGW port with the attached change

Re: contrib/cache_scan (Re: [HACKERS] What's needed for cache-only table scan?)

On Sat, Feb 8, 2014 at 1:09 PM, Kohei KaiGai wrote: > Hello, > > Because of time pressure in the commit-fest:Jan, I tried to simplifies the > patch > for cache-only scan into three portions; (1) add a hook on heap_page_prune > for cache invalidation on vacuuming a particular page. (2) add a check

Re: [HACKERS] narwhal and PGDLLIMPORT

On Feb 12, 2014 4:09 AM, "Craig Ringer" wrote: > > On 02/12/2014 09:45 AM, Tom Lane wrote: > > Andrew Dunstan writes: > >> On 02/11/2014 08:04 PM, Craig Ringer wrote: > >>> Looks like currawong doesn't build postgres_fdw. > > > >> It sure used to: > >> < http://www.pgbuildfarm.org/cgi-bin/show_st

Re: [HACKERS] narwhal and PGDLLIMPORT

On Wed, Feb 12, 2014 at 5:30 AM, Craig Ringer wrote: > On 02/11/2014 11:04 PM, Amit Kapila wrote: >> On Tue, Feb 11, 2014 at 11:01 AM, Craig Ringer wrote: >>> On 02/11/2014 01:28 PM, Tom Lane wrote: If there are no objections, I'll push this patch into HEAD tomorrow, along with the upth

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Tue, Feb 11, 2014 at 10:07 PM, Bruce Momjian wrote: > On Wed, Feb 5, 2014 at 10:57:57AM -0800, Peter Geoghegan wrote: >> On Wed, Feb 5, 2014 at 12:50 AM, Heikki Linnakangas >> wrote: >> >> I think there's zero overlap. They're completely complimentary features. >> >> It's not like normal WAL

Re: [HACKERS] narwhal and PGDLLIMPORT

(2014/02/12 8:30), Tom Lane wrote: > I wrote: >> Hiroshi Inoue writes: >>> I tried MINGW port with the attached change and successfully built >>> src and contrib and all pararell regression tests were OK. > >> I cleaned this up a bit (the if-nesting in Makefile.shlib was making >> my head hurt, n

Re: [HACKERS] narwhal and PGDLLIMPORT

On 02/12/2014 09:45 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 02/11/2014 08:04 PM, Craig Ringer wrote: >>> Looks like currawong doesn't build postgres_fdw. > >> It sure used to: >>

Re: [HACKERS] improve the help message about psql -F

If you are going to change the help string for -F, you should also update the help string for -R, and possibly for -z and -0. > > -- 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] Unhappy with error handling in psql's handleCopyOut()

* Tom Lane (t...@sss.pgh.pa.us) wrote: > I was able to reproduce this misbehavior by setting a gdb breakpoint > at pqReadData and then killing the connected server process while psql's > COPY IN was stopped there. Resetting outCount to zero in the > socket-already-gone case in pqSendSome is enough

Re: [HACKERS] truncating pg_multixact/members

On Tue, Feb 11, 2014 at 5:16 PM, Alvaro Herrera wrote: > Robert Haas escribió: >> On Mon, Jan 20, 2014 at 1:39 PM, Alvaro Herrera >> wrote: >> > * I haven't introduced settings to tweak this per table for >> > autovacuum. I don't think those are needed. It's not hard to do, >> > however; if peo

Re: [HACKERS] narwhal and PGDLLIMPORT

Andrew Dunstan writes: > On 02/11/2014 08:04 PM, Craig Ringer wrote: >> Looks like currawong doesn't build postgres_fdw. > It sure used to: > Hm, does the MSVC build system do parallel buil

Re: [HACKERS] Unhappy with error handling in psql's handleCopyOut()

I wrote: >> Stephen Frost writes: >>> I've not gotten back to it yet, but I ran into a related-seeming issue >>> where psql would happily chew up 2G of memory trying to send "COPY >>> failed" notices when it gets disconnected from a server that it's trying >>> to send data to mid-COPY. conn->sock

Re: [HACKERS] narwhal and PGDLLIMPORT

On 02/11/2014 08:04 PM, Craig Ringer wrote: On 02/12/2014 08:30 AM, Tom Lane wrote: Craig Ringer writes: On 02/12/2014 07:22 AM, Tom Lane wrote: So the early returns from currawong are interesting: Great, that's what I was hoping to see - proper errors where we've omitted things, not silent

Re: [HACKERS] narwhal and PGDLLIMPORT

On 02/12/2014 08:30 AM, Tom Lane wrote: > Craig Ringer writes: >> On 02/12/2014 07:22 AM, Tom Lane wrote: >>> So the early returns from currawong are interesting: > >> Great, that's what I was hoping to see - proper errors where we've >> omitted things, not silent miscompilation. > > Well, befor

Re: [HACKERS] narwhal and PGDLLIMPORT

Craig Ringer writes: > On 02/12/2014 07:22 AM, Tom Lane wrote: >> So the early returns from currawong are interesting: > Great, that's what I was hoping to see - proper errors where we've > omitted things, not silent miscompilation. Well, before you get too optimistic about that benighted platfo

Re: [HACKERS] narwhal and PGDLLIMPORT

Craig Ringer writes: > On 02/12/2014 07:30 AM, Tom Lane wrote: >> BTW, now that I look at this ... why are we bothering to build static >> libraries (.a files) for DLLs? They have no possible use AFAICS. > I don't see any use for that with plperl, but it might be a valid thing > to be doing for

Re: [HACKERS] narwhal and PGDLLIMPORT

On 02/12/2014 07:30 AM, Tom Lane wrote: > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute > -Wformat-security -fno-strict-aliasing -fwrapv -g -Wno-comment -shared -o > plperl.dll plperl.o SPI.o Util.o -L../../../src

Re: [HACKERS] narwhal and PGDLLIMPORT

On 02/11/2014 11:04 PM, Amit Kapila wrote: > On Tue, Feb 11, 2014 at 11:01 AM, Craig Ringer wrote: >> On 02/11/2014 01:28 PM, Tom Lane wrote: >>> If there are no objections, I'll push this patch into HEAD tomorrow, >>> along with the upthread patches from Craig Ringer and Marco Atzeri. >>> We migh

Re: [HACKERS] narwhal and PGDLLIMPORT

On 02/12/2014 07:22 AM, Tom Lane wrote: > So the early returns from currawong are interesting: > > "d:\bf\root\HEAD\pgsql.920\pgsql.sln" (default target) (1) -> > (contrib\pg_buffercache target) -> > pg_buffercache_pages.obj : error LNK2001: unresolved external symbol > _MainLWLockArray > .\

Re: [HACKERS] narwhal and PGDLLIMPORT

I wrote: > Hiroshi Inoue writes: >> I tried MINGW port with the attached change and successfully built >> src and contrib and all pararell regression tests were OK. > I cleaned this up a bit (the if-nesting in Makefile.shlib was making > my head hurt, not to mention that it left a bunch of dead c

Re: [HACKERS] Small GIN optimizations (after 9.4)

On Wed, Feb 12, 2014 at 2:58 AM, Bruce Momjian wrote: > On Sun, Feb 9, 2014 at 02:17:12PM +0400, Alexander Korotkov wrote: > > On Thu, Feb 6, 2014 at 8:31 PM, PostgreSQL - Hans-J rgen Sch nig < > > postg...@cybertec.at> wrote: > > > > i think there is one more thing which would be really goo

Re: [HACKERS] narwhal and PGDLLIMPORT

Craig Ringer writes: > On 02/11/2014 01:28 PM, Tom Lane wrote: >> If there are no objections, I'll push this patch into HEAD tomorrow, >> along with the upthread patches from Craig Ringer and Marco Atzeri. >> We might as well see if this stuff is going to work ... > I'd love to test my patch prop

Re: [HACKERS] Unhappy with error handling in psql's handleCopyOut()

I wrote: > Stephen Frost writes: >> I've not gotten back to it yet, but I ran into a related-seeming issue >> where psql would happily chew up 2G of memory trying to send "COPY >> failed" notices when it gets disconnected from a server that it's trying >> to send data to mid-COPY. conn->sock was

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

On Sun, Feb 02, 2014 at 02:52:42PM -0800, David Fetter wrote: > On Wed, Aug 21, 2013 at 08:52:25PM +0200, Karol Trzcionka wrote: > > W dniu 21.08.2013 19:17, Boszormenyi Zoltan pisze: > > > With this fixed, a more complete review: > > Thanks. > > I've done some syntactic and white space cleanup, h

Re: [HACKERS] Small GIN optimizations (after 9.4)

On Sun, Feb 9, 2014 at 02:17:12PM +0400, Alexander Korotkov wrote: > On Thu, Feb 6, 2014 at 8:31 PM, PostgreSQL - Hans-J rgen Sch nig < > postg...@cybertec.at> wrote: > > i think there is one more thing which would be really good in GIN and > which > would solve a ton of issues. > at

Re: [HACKERS] [PERFORM] encouraging index-only scans

On Tue, Feb 11, 2014 at 05:51:36PM -0200, Claudio Freire wrote: > > We track relpages and relallvisible, which seems like a more direct measure. > > Once analyze is done (which is already triggered by inserts) and sets those, > > it could fire a vacuum based on the ratio of those values, or the aut

Re: [HACKERS] Unhappy with error handling in psql's handleCopyOut()

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > I've not gotten back to it yet, but I ran into a related-seeming issue > > where psql would happily chew up 2G of memory trying to send "COPY > > failed" notices when it gets disconnected from a server that it's trying > > to send

Re: [HACKERS] Unhappy with error handling in psql's handleCopyOut()

Stephen Frost writes: > I've not gotten back to it yet, but I ran into a related-seeming issue > where psql would happily chew up 2G of memory trying to send "COPY > failed" notices when it gets disconnected from a server that it's trying > to send data to mid-COPY. conn->sock was -1, connection

Re: [HACKERS] Patch: compiling the docs under Gentoo

On 1/30/14, 2:42 AM, Christian Kruse wrote: > +Since Gentoo often supports different versions of a package to be > +installed you have to tell the PostgreSQL build environment where the > +Docbook DTD is located: > + > +cd /path/to/postgresql/sources/doc > +make DOCBOOKSTYLE=/usr/share/

Re: [HACKERS] Unhappy with error handling in psql's handleCopyOut()

* Tom Lane (t...@sss.pgh.pa.us) wrote: > While looking at the pending patch to make psql report a line count > after COPY, I came across this business in handleCopyOut(): > > * Check command status and return to normal libpq state. After a > * client-side error, the server will remain r

[HACKERS] Unhappy with error handling in psql's handleCopyOut()

While looking at the pending patch to make psql report a line count after COPY, I came across this business in handleCopyOut(): * Check command status and return to normal libpq state. After a * client-side error, the server will remain ready to deliver data. The * cleanest thing

Re: [HACKERS] narwhal and PGDLLIMPORT

On 11/02/2014 18:15, Tom Lane wrote: Marco Atzeri writes: On 09/02/2014 14:10, Andrew Dunstan wrote: On 02/09/2014 01:12 AM, Marco Atzeri wrote: we should have get rid of dlltool on cygwin. At least it is not used on my build The send in a patch. The patch you sent in previously did not

Re: [HACKERS] [PERFORM] encouraging index-only scans

On Tue, Feb 11, 2014 at 4:13 PM, Jeff Janes wrote: >> >> Do we want to track the number of inserts in statistics and trigger an >> auto-vacuum after a specified number of inserts? > > > We track relpages and relallvisible, which seems like a more direct measure. > Once analyze is done (which is al

Re: [HACKERS] PostgreSQL Failback without rebuild

On Fri, Feb 7, 2014 at 03:57:31PM +1100, James Sewell wrote: > I've just noticed that on PostgreSQL 9.3 I can do the following with a master > node A and a slave node B (as long as I have set recovery_target_timeline = > 'latest'): > > 1. Stop Node A > 2. Promote Node B > 3. Attach Node A as s

Re: [HACKERS] [PERFORM] encouraging index-only scans

On Tue, Feb 11, 2014 at 9:12 AM, Bruce Momjian wrote: > On Tue, Feb 11, 2014 at 11:28:36AM -0500, Robert Haas wrote: > > A sequential scan will set hint bits and will prune the page, but > > pruning the page doesn't ever mark it all-visible; that logic is > > entirely in vacuum. If that could be

Re: [HACKERS] [PERFORM] encouraging index-only scans

On Tue, Feb 11, 2014 at 01:54:48PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > On Tue, Feb 11, 2014 at 07:31:03PM +0100, Andres Freund wrote: > >> I am not saying it shouldn't be improved, I just don't see the point of > >> bringing it up while everyone is busy with the last CF and claiming

Re: [HACKERS] [PERFORM] encouraging index-only scans

On 2014-02-11 13:41:46 -0500, Bruce Momjian wrote: > Wait longer for what? Anti-xid-wraparound vacuum? Yes. > Is using VACUUM for these cases documented? Should it be? No idea, it seems to be part of at least part of the folkloric knowledge, from what I see at clients. > > I am not saying it

Re: [HACKERS] [PERFORM] encouraging index-only scans

Bruce Momjian writes: > On Tue, Feb 11, 2014 at 07:31:03PM +0100, Andres Freund wrote: >> I am not saying it shouldn't be improved, I just don't see the point of >> bringing it up while everyone is busy with the last CF and claiming it >> is unusable and that stating that it is surprisising that n

Re: [HACKERS] narwhal and PGDLLIMPORT

Craig Ringer writes: > For MSVC, here's a patch that makes gendef.pl emit DATA annotations for > global var exports. Committed. > Also attached is a patch to make vcregress.pl produce a better error > message when there's no build output, instead of just reporting that > ".. is not a recognized

Re: [HACKERS] [PERFORM] encouraging index-only scans

On Tue, Feb 11, 2014 at 07:31:03PM +0100, Andres Freund wrote: > On 2014-02-11 13:23:19 -0500, Bruce Momjian wrote: > > On Tue, Feb 11, 2014 at 06:54:10PM +0100, Andres Freund wrote: > > > On 2014-02-11 12:12:13 -0500, Bruce Momjian wrote: > > > > Yes, that pretty much sums it up. We introduced in

[HACKERS] unitialized data in populate_record_worker

Hi, while testing a patch I ran valgrind over a recent checkout, and it spit out the following: ==14792== Conditional jump or move depends on uninitialised value(s) ==14792==at 0x7F8A30: populate_record_worker (jsonfuncs.c:1459) ==14792==by 0x7F8451: json_to_record (jsonfuncs.c:1280) ==147

Re: [HACKERS] [PERFORM] encouraging index-only scans

On 2014-02-11 13:23:19 -0500, Bruce Momjian wrote: > On Tue, Feb 11, 2014 at 06:54:10PM +0100, Andres Freund wrote: > > On 2014-02-11 12:12:13 -0500, Bruce Momjian wrote: > > > Yes, that pretty much sums it up. We introduced index-only scans in 9.2 > > > (2012) but they still seem to be not usable

Re: [HACKERS] [PERFORM] encouraging index-only scans

On Tue, Feb 11, 2014 at 06:54:10PM +0100, Andres Freund wrote: > On 2014-02-11 12:12:13 -0500, Bruce Momjian wrote: > > Yes, that pretty much sums it up. We introduced index-only scans in 9.2 > > (2012) but they still seem to be not usable for insert-only workloads > > two years later. Based on c

Re: [HACKERS] narwhal and PGDLLIMPORT

Hiroshi Inoue writes: > (2014/02/09 8:06), Andrew Dunstan wrote: >> Yeah. Incidentally, we didn't quite get rid of dlltool for Cygwin. We >> did get rid of dllwrap. But I agree this is worth trying for Mingw. > I tried MINGW port with the attached change and successfully built > src and contrib a

Re: [HACKERS] jsonb and nested hstore

On Tue, Feb 11, 2014 at 3:35 AM, Hannu Krosing wrote: > On 02/11/2014 01:16 AM, Merlin Moncure wrote: >> On Mon, Feb 10, 2014 at 5:52 PM, Andres Freund >> wrote: >>> It works in enough cases atm that it's worthwile trying to keep it >>> working. Sure, it could be better, but it's what we have ri

Re: [HACKERS] Changeset Extraction v7.5

Hi! On 2014-02-11 11:22:24 -0500, Robert Haas wrote: > + * contents of records in here xexcept turning them into a more usable > > Typo. > > + /* > +* XXX: There doesn't seem to be a usecase for > decoding > +* HEAP_NEWP

Re: [HACKERS] [PERFORM] encouraging index-only scans

On 2014-02-11 12:12:13 -0500, Bruce Momjian wrote: > Yes, that pretty much sums it up. We introduced index-only scans in 9.2 > (2012) but they still seem to be not usable for insert-only workloads > two years later. Based on current progress, it doesn't look like this > will be corrected until 9.

Re: [HACKERS] narwhal and PGDLLIMPORT

Marco Atzeri writes: > On 09/02/2014 14:10, Andrew Dunstan wrote: >> On 02/09/2014 01:12 AM, Marco Atzeri wrote: >>> we should have get rid of dlltool on cygwin. >>> At least it is not used on my build >> The send in a patch. The patch you sent in previously did not totally >> remove it IIRC. >

Re: [HACKERS] [PERFORM] encouraging index-only scans

On Tue, Feb 11, 2014 at 11:28:36AM -0500, Robert Haas wrote: > A sequential scan will set hint bits and will prune the page, but > pruning the page doesn't ever mark it all-visible; that logic is > entirely in vacuum. If that could be made cheap enough to be > negligible, it might well be worth do

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Wed, Feb 5, 2014 at 10:57:57AM -0800, Peter Geoghegan wrote: > On Wed, Feb 5, 2014 at 12:50 AM, Heikki Linnakangas > wrote: > >> I think there's zero overlap. They're completely complimentary features. > >> It's not like normal WAL records have an irrelevant volume. > > > > > > Correct. Compre

Re: [HACKERS] Review: tests for client programs

On Sat, Feb 8, 2014 at 10:16 PM, Peter Eisentraut wrote: > Clearly, we will need to figure out something about how to require this > module, and possibly others in the future, as we expand the tests. > Having configure check for it is not necessarily the best solution -- > What is configure suppos

Re: [HACKERS] [PERFORM] encouraging index-only scans

On Tue, Feb 11, 2014 at 10:56 AM, Bruce Momjian wrote: > Right now, as I remember, only vacuum sets the visibility bits. If we > don't want to make vacuum trigger for insert-only workloads, can we set > pages all-visible more often? > > Is there a reason that a sequential scan, which does do page

Re: [HACKERS] Recovery inconsistencies, standby much larger than primary

On Sun, Feb 9, 2014 at 2:54 PM, Greg Stark wrote: > Bad block's page header -- this is in the 56'th relation segment: > > =# select > (page_header(E'\\x2005583b05aa050028001805002004201098e00f2090e00f088d24061885e00f')).*; > lsn | tli | flags | lower | u

Re: [HACKERS] Changeset Extraction v7.5

On Fri, Feb 7, 2014 at 2:35 PM, Andres Freund wrote: > attached you can find the next version of the patchset. As usual, I'm going to be reviewing patch 1. The definition of "patch 1" has changed quite a few times over the past year, but that's usually the one I'm reviewing. + * contents o

Re: [HACKERS] [PERFORM] encouraging index-only scans

On Mon, Feb 3, 2014 at 11:55:34AM -0500, Robert Haas wrote: > > Robert, where are we on this? Should I post a patch? > > I started working on this at one point but didn't finish the > implementation, let alone the no-doubt-onerous performance testing > that will be needed to validate whatever we

Re: [HACKERS] narwhal and PGDLLIMPORT

On Tue, Feb 11, 2014 at 11:01 AM, Craig Ringer wrote: > On 02/11/2014 01:28 PM, Tom Lane wrote: >> If there are no objections, I'll push this patch into HEAD tomorrow, >> along with the upthread patches from Craig Ringer and Marco Atzeri. >> We might as well see if this stuff is going to work ...

Re: [HACKERS] Patch: show xid and xmin in pg_stat_activity and pg_stat_replication

On Fri, Feb 7, 2014 at 4:34 AM, Christian Kruse wrote: > attached you will find a new version with the following issues > resolved: > > - use backend ID once again for getting the xid and xmin > - use instead of in documentation > - rename fields to backend_xid and backend_xmin This looks mostl

Re: [HACKERS] Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease

On 2014-02-11 21:46:04 +0900, MauMau wrote: > From: "Andres Freund" > >which means they manipulate the lwWaitLink queue without > >protection. That's done intentionally. The code tries to protect against > >corruption of the list to do a woken up backend acquiring a lock (this > >or an independent

Re: [HACKERS] Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease

From: "Andres Freund" which means they manipulate the lwWaitLink queue without protection. That's done intentionally. The code tries to protect against corruption of the list to do a woken up backend acquiring a lock (this or an independent one) by only continuing when the lwWaiting flag is set

Re: [HACKERS] Row-security on updatable s.b. views

On 02/11/2014 08:19 PM, Yeb Havinga wrote: > On 2014-02-11 12:09, Craig Ringer wrote: >> rls-9.4-upd-sb-views-v7 >> > Hi Craig, > > I compared output of psql -ef of the minirim.sql script posted earlier > in http://www.postgresql.org/message-id/52f54927.1040...@gmail.com > between v4 and v7. > >

Re: [HACKERS] Row-security on updatable s.b. views

On 2014-02-11 12:09, Craig Ringer wrote: On 02/11/2014 06:05 PM, Yeb Havinga wrote: On 2014-02-11 09:36, Craig Ringer wrote: On 02/06/2014 10:19 PM, Craig Ringer wrote: On 02/06/2014 12:43 PM, Craig Ringer wrote: 1. Try (again) to do row-security in the rewriter. This was previously impossibl

Re: [HACKERS] Row-security on updatable s.b. views

On 02/11/2014 06:05 PM, Yeb Havinga wrote: > On 2014-02-11 09:36, Craig Ringer wrote: >> On 02/06/2014 10:19 PM, Craig Ringer wrote: >>> On 02/06/2014 12:43 PM, Craig Ringer wrote: 1. Try (again) to do row-security in the rewriter. This was previously impossible because of the definition

Re: [HACKERS] Row-security on updatable s.b. views

On 2014-02-11 09:36, Craig Ringer wrote: On 02/06/2014 10:19 PM, Craig Ringer wrote: On 02/06/2014 12:43 PM, Craig Ringer wrote: 1. Try (again) to do row-security in the rewriter. This was previously impossible because of the definition of row-security behaviour around inheritance, but with the

Re: [HACKERS] jsonb and nested hstore

On 02/11/2014 01:16 AM, Merlin Moncure wrote: > On Mon, Feb 10, 2014 at 5:52 PM, Andres Freund wrote: >> It works in enough cases atm that it's worthwile trying to keep it >> working. Sure, it could be better, but it's what we have right now. Atm >> it's e.g. the only realistic way to copy larger

Re: [HACKERS] Row-security on updatable s.b. views

On 02/06/2014 10:19 PM, Craig Ringer wrote: > On 02/06/2014 12:43 PM, Craig Ringer wrote: >> 1. Try (again) to do row-security in the rewriter. This was previously >> impossible because of the definition of row-security behaviour around >> inheritance, but with the simplified inheritance model now