Re: [HACKERS] Processing database query-results piecemeal

At 2008-06-30 13:17:42 +0200, [EMAIL PROTECTED] wrote: > > It seems that the most efficient way to communicate with the > DB would be through PQexecParams(), which avoids the whole > bytea-encoding issues. Yes. > Does it become $10 or ${10} or $(10) or is it simply not possible > te reference

Re: [HACKERS] Limits of backwards compatibility for psql's \d commands

At 2008-07-02 09:16:30 +0200, [EMAIL PROTECTED] wrote: > > I don't think we should add support for pre-7.4 releases. I agree. It's not worth the effort. -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/m

Re: [HACKERS] Git Repository for WITH RECURSIVE and others

At 2008-07-03 11:16:49 +0900, [EMAIL PROTECTED] wrote: > > # WITH RECURSIVE repository > % git-clone git://git.postgresql.org/git/~davidfetter/postgresql/.git > Initialized empty Git repository in /home/y-asaba/x/postgresql/.git/ > fatal: The remote end hung up unexpectedly Run git-clone h

[HACKERS] SSL configure patch: review

These are my review comments on Mark Woodward's "SSL configure patch": http://archives.postgresql.org/message-id/[EMAIL PROTECTED] (The patch is whitespace-damaged and the one fe-secure.c hunk doesn't apply cleanly to the latest source, but I'm ignoring both problems for the moment.) 1. To begin

Re: [HACKERS] SSL configure patch: review

At 2008-07-08 08:27:29 +0530, [EMAIL PROTECTED] wrote: > > (The patch is whitespace-damaged and the one fe-secure.c hunk doesn't > apply cleanly to the latest source, but I'm ignoring both problems for > the moment.) It wasn't hard to fix those, so I've attached an updated patch here. > Finally,

Re: [HACKERS] Adding variables for segment_size, wal_segment_size and block sizes

At 2008-07-03 16:36:02 +0200, [EMAIL PROTECTED] wrote: > > Here's a patch for this. I reviewed the patch, it basically looks fine. A few quibbles with the provided documentation: > + Reports the number of pages which can be stored within a file > segment. > + The total physical

Re: [HACKERS] Extending grant insert on tables to sequences

At 2008-07-08 09:32:44 -0400, [EMAIL PROTECTED] wrote: > > > > The idea of this patch is to avoid the need to make explicit > > > grants on sequences owned by tables. [...] > > I had a look at this patch and it looks good. The only thing that's > not clear to me is whether we have agreed we want t

Re: [HACKERS] Extending grant insert on tables to sequences

At 2008-07-09 15:11:25 -0400, [EMAIL PROTECTED] wrote: > > No, actually I meant having a lone "list = lappend(list, newseq);" in > the loop, so that ExecGrantStmt_oids is called only once. Yes, I understand what you meant. I just phrased my agreement poorly. Here's a more precise phrasing. ;-) (I

Re: [HACKERS] WITH RECURSIVE updated to CVS TIP

At 2008-07-09 17:06:19 -0700, [EMAIL PROTECTED] wrote: > > I'm really new to this git thing, but I now have access to create > git-shell accounts, etc. on git.postgresql.org. Any ideas you can > offer on how better to handle this would really help me. :) The question is: what is your objective in

Re: [HACKERS] Protocol 3, Execute, maxrows to return, impact?

(I don't really have much to add to the discussion here; I'm just posting for the record on the question of client behaviour, since I also wrote and maintain a client library in C++.) At 2008-07-10 18:40:03 +0200, [EMAIL PROTECTED] wrote: > > I start returning rows as they arrive, and pause readin

Re: [HACKERS] WITH RECURSIVE updated to CVS TIP

At 2008-07-10 07:18:28 -0700, [EMAIL PROTECTED] wrote: > > Here are my objectives: > > 1. Make a repository that keeps up with CVS HEAD. > > 2. Allow people who are not currently committers on CVS HEAD to > make needed changes. OK. Then, to begin with, I think it is very important to make the

Re: [HACKERS] posix advises ...

Hi Zoltán. I was reading through your posix_fadvise patch, and I wanted to ask about this change in particular: > --- a/src/backend/executor/nodeIndexscan.c > +++ b/src/backend/executor/nodeIndexscan.c > @@ -290,7 +290,7 @@ ExecIndexEvalArrayKeys(ExprContext *econtext, > /* We want to kee

[HACKERS] [PATCH] Implement (and document, and test) has_sequence_privilege()

That this family of functions did not exist earlier was merely an oversight. Signed-off-by: Abhijit Menon-Sen --- doc/src/sgml/func.sgml | 28 src/backend/utils/adt/acl.c | 210 ++ src/include/catalog/pg_proc.h

[HACKERS] Allow COMMENT ON to accept an expression rather than just a string

Hi. There's a TODO item about making COMMENT ON accept an expression. The grammar change is simple (SConst|NULL_P->a_expr), but as far as I can see, there are no similar utility commands that take expressions, and I'm not very familiar with the planner and executor, so I could use some advice abou

Re: [HACKERS] Allow COMMENT ON to accept an expression rather than just a string

At 2009-04-11 14:08:21 -0400, t...@sss.pgh.pa.us wrote: > > So there's a use-case at least for allowing parameter symbols in place > of string literals, if not fully general expressions. But again, I > think we'd want such a thing across all utility statements that can > take string literals, not o

[HACKERS] [PATCH] Add a test for pg_get_functiondef()

From: Abhijit Menon-Sen Thanks to Andrew Gierth for writing the function used in the test. --- src/test/regress/expected/defs.out | 43 src/test/regress/parallel_schedule |2 +- src/test/regress/serial_schedule |1 + src/test/regress/sql/defs.sql

Re: [HACKERS] [PATCH] Add a test for pg_get_functiondef()

Sorry, I screwed up a little in sending that patch. Here it is again as an attachment. -- ams diff --git a/src/test/regress/sql/defs.sql b/src/test/regress/sql/defs.sql new file mode 100644 index 000..cf8fff3 --- /dev/null +++ b/src/test/regress/sql/defs.sql @@ -0,0 +1,24 @@ +-- Test pg_get_fu

Re: [HACKERS] [PATCH] Add a test for pg_get_functiondef()

At 2009-04-13 10:40:41 -0400, t...@sss.pgh.pa.us wrote: > > Abhijit Menon-Sen writes: > > [ a test whose purpose he didn't bother to describe ] I'm sorry about that. > What is the value of this? It seems far more likely to cause > maintenance pain than to catch an

[HACKERS] passing constant parameters to functional indices

I'd like to add support for specifying constant parameters when creating a functional index, e.g. create index foo on bar (substr(baz, 1, 32)); Is this a good idea? If so, I'd like to ask for some suggestions before I proceed any further towards implementing it. The arguments to the index functi

[HACKERS] +1400 is a valid time zone offset

In 1995, Kiribati decided to move the international date line, so that all of the constituent islands lie on the same side. As a consequence, the Easternmost islands are now at GMT+1400. (There's some controvery about whether they had the right to move the IDL, but they have the right to decide wh

Re: [HACKERS] Ding-dong, contrib is dead ...

At 2006-09-05 10:23:19 -0400, [EMAIL PROTECTED] wrote: > > Something like it ought to go into core, but personally I'd opt for > taking the opportunity to redesign the API, which was a bit crufty to > begin with. I'm happy to do the work right away (not that there's much) if someone suggests a bet

Re: [HACKERS] Ding-dong, contrib is dead ...

At 2006-09-05 16:35:49 -0400, [EMAIL PROTECTED] wrote: > > The biggest part of the work needed is to write the documentation --- > but we'd have to do that for Abhijit's patch too, since the userlocks > docs presumably fall under GPL along with the code. I'll write the documentation, either for th

Re: [HACKERS] Problems with extended-Query logging code

At 2006-09-06 18:01:38 -0400, [EMAIL PROTECTED] wrote: > > That is, we'd log a Parse or Bind operation if it individually > exceeded the duration threshold, and not otherwise. Ok. > If we've got support for logging the statement text and the parameter > values at Execute time, isn't logging the p

Re: [HACKERS] Ding-dong, contrib is dead ...

At 2006-09-07 00:16:38 -0400, [EMAIL PROTECTED] wrote: > > > - Where would the code live, if it were in core? > > - Shall I hack up the API you suggested in your earlier message? > > are we still moving forward with this? I would love to see this go in > for 8.2. I don't know about its going into

Re: [HACKERS] Ding-dong, contrib is dead ...

At 2006-09-05 05:47:58 -, [EMAIL PROTECTED] wrote: > > that difficulty no longer exists now that Abhijit has posted his > clean-room rewrite (look for "otherlock" in -patches). Perhaps he > would be prepared to turn that into a patch against the core... Absolutely. Just tell me where it should

Re: [HACKERS] help wanted (fmgr.c)

At 2006-09-11 10:25:22 +0200, [EMAIL PROTECTED] wrote: > > What are we testing to be NULL here? > Do we expect str to changed at line 1715 No. (Read the comment just above the function.) The code is like this, starting from line 1703: if (str == NULL && flinfo->fn_strict) return (Da

Re: [HACKERS] signed short fd

At 2005-03-14 16:25:22 -0500, [EMAIL PROTECTED] wrote: > > > "The file descriptor returned by open is the lowest numbered unused > > descriptor. [...] > > What is meant by "unused?" Perhaps you should actually look at the standard. "The open( ) function shall return a file descriptor for the n

Re: [HACKERS] PHP stuff

[EMAIL PROTECTED] wrote: > > As the copyright owner, "The PostgreSQL Global Development Group," has > the right to license the documentation any way they see fit. The PGDG has never asked for copyright assignments from contributors (as I gather the PHP folks do), so the copyright to Postgres is co

Re: [HACKERS] prepared statements don't log arguments?

At 2005-04-07 12:14:19 +1000, [EMAIL PROTECTED] wrote: > > % tail /usr/local/pgsql/postmaster.log > LOG: statement: prepare foo(int, int) as select $1 + $2; > LOG: statement: execute foo(5, 10); > LOG: statement: execute foo(15, 20); If you send a v3 protocol execute message instead of an SQL E

[HACKERS] linuxtag 2005

Are any PostgreSQL hackers planning to be at Linuxtag in Karlsruhe? -- ams ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

[HACKERS] creating WITH HOLD cursors using SPI

Hi. I've been working on making it possible for PL/Perl users to fetch large result sets one row at a time (the current spi_exec_query interface just returns a big hash). The idea is to have spi_query call SPI_prepare/SPI_open_cursor, and have an spi_fetchrow that calls SPI_cursor_fetch. It works

Re: [HACKERS] creating WITH HOLD cursors using SPI

At 2005-06-12 14:54:47 +0530, [EMAIL PROTECTED] wrote: > > The idea is to have spi_query call SPI_prepare/SPI_open_cursor, and have > an spi_fetchrow that calls SPI_cursor_fetch. It works well enough, but I > don't know how to reproduce spi_exec_query's error handling (it runs the > SPI_execute in

Re: [HACKERS] #ifdef NOT_USED

(Sorry for the delayed response. I just got home from Germany after my visit to Linuxtag, and I'm catching up with my -hackers email now.) At 2005-06-25 09:30:17 -0400, pgman@candle.pha.pa.us wrote: > > > Hi, i have found several #ifdef NOT_USED marked code... > > We keep such blocks of code aroun

Re: [HACKERS] Occupied port warning

At 2005-06-28 15:14:29 +0200, [EMAIL PROTECTED] wrote: > > I recall that it had something to do with IPv6, but I'm not sure. Under Linux, if you bind to AF_INET6/::0, a subsequent bind to AF_INET/0 will fail, but the IPv4 address is also bound by the first call, and the program will accept IPv4 co

Re: [HACKERS] prepared queries in plperl

At 2005-07-15 17:17:01 +0200, [EMAIL PROTECTED] wrote: > > I needed prepared queries in plperl, but there's none, so I baked > a patch that defines two extra perl functions, spi_prepare and > spi_exec_prepared Oh. I've been working on the same functionality this week following a conversation with

[HACKERS] specifying multiple result format codes with libpq

The documentation for PQexecPrepared says: (There is not currently a provision to obtain different result columns in different formats, although that is possible in the underlying protocol.) Would anyone be interested in a patch to allow this? I could, for example, change PQsendQuery

Re: [HACKERS] specifying multiple result format codes with libpq

At 2004-06-18 13:11:19 -0400, [EMAIL PROTECTED] wrote: > > > Would anyone be interested in a patch to allow this? > > Yes, but not the way you suggest. The ... approach forces calling > code to know *when it is written* how many result columns there will > be, because you'd have to actually write

[HACKERS] placeholder syntax

PostgreSQL currently uses $1/$2 for placeholders in prepared statements. I'm writing something that may potentially submit queries to both Oracle and Postgres, and it seems Oracle doesn't accept this syntax. Someone on IRC said I could use ? for both Oracle and Postgres. It isn't entirely clear to

Re: [HACKERS] compile errors in new PL/Pler

At 2004-07-02 08:55:56 -0400, [EMAIL PROTECTED] wrote: > > In the meantime, does this solve your problem?: > > #ifndef eval_pv > #define eval_pv perl_eval_pv > #endif The right way to do this is to #include "ppport.h" from Devel::PPPort. -- ams ---(end of broadcast)-

Re: [HACKERS] PREPARE and transactions

At 2004-06-24 13:13:42 -0400, [EMAIL PROTECTED] wrote: > > > This is why I proposed originally to keep the non-transactional > > behavior for Parse messages, but transactional for SQL PREPARE. > > The latter can be said to be inside the transaction and should > > behave like so. I think this lower

Re: [HACKERS] PREPARE and transactions

At 2004-07-03 08:20:17 +0530, [EMAIL PROTECTED] wrote: > > I would not object to changing PREPARE to be transactional while > leaving Parse messages alone. That is to say, it wouldn't cause any problems for me. But since it does seem to be a nuisance for Oliver and Merlin (among others), I agree w

Re: [HACKERS] What do you want me to do?

> http://www.atlassian.com/software/jira/pricing.jsp I have no particular opinion on whether to use a free or non-free system to track bugs, but I'd like to recommend RT as being a very capable and useful program. It has been used to track Perl 5 and CPAN bugs for some time now, and it happens to

Re: [HACKERS] Double linked list with one pointer

At 2003-12-07 18:19:26 +0100, [EMAIL PROTECTED] wrote: > > There is a new type in C99 for "integer that can hold a pointer > value". I think it's called intptr_t resp. uintptr_t, but I don't have > the standard around. Yes, they're called intptr_t and uintptr_t (§7.18.1.4), but they're both option

Re: [HACKERS] PostgreSQL overall design

At 2005-09-27 15:20:05 +0530, [EMAIL PROTECTED] wrote: > > Can anyone please tell/point me where I can get the postgresql system > layout (I've an interest to contribute). http://www.postgresql.org/developer/coding And, in particular: http://www.postgresql.org/docs/faqs.FAQ_DEV.html -- ams ---

Re: [HACKERS] libpq and prepared statements progress for 8.0

At 2004-09-17 14:28:36 -0700, [EMAIL PROTECTED] wrote: > > > Assuming that anyone steps up and does the work, that is. > > So...any volunteers? OK, how about adding a PQprepare (PQcreatePrepared?) function like this? PGresult * PQprepare(PGconn *conn, const char *stmtName,

Re: [HACKERS] libpq and prepared statements progress for 8.0

At 2004-09-20 01:25:56 -0400, [EMAIL PROTECTED] wrote: > > That means you also need to add a new Execute method that takes a > portalName instead of a command. Yes, thanks. How about these functions, then? PGresult * PQprepare(PGconn *conn, const char *stmtName,

Re: [HACKERS] libpq and prepared statements progress for 8.0

(I apologise in advance if anyone receives multiple copies of this post. I posted from the wrong address earlier.) At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote: > > I assumed we would want a separate Bind and execute call. Do we? Yes, we do. (See below.) > Personally I find it annoying

Re: [HACKERS] libpq and prepared statements progress for 8.0

At 2004-09-20 10:20:03 -0400, [EMAIL PROTECTED] wrote: > > What you should be concerned with right now is providing an API for > Parse + Describe Statement, to substitute for the existing approach > of setting up statement objects via PQexec("PREPARE foo ..."). Fair enough. That's why my original

Re: [HACKERS] libpq and prepared statements progress for 8.0

At 2004-09-20 11:02:50 -0400, [EMAIL PROTECTED] wrote: > > (1) What about preparing an unnamed statement ... stmtName == "" will work. > (2) What about discovering the actually resolved parameter types? I'm not sure what to do about that. I could extend PGresult to hold ParameterDescription inf

Re: [HACKERS] libpq and prepared statements progress for 8.0

At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote: > > Personally I find it annoying that you can't call describe on a > statement, only a portal, but that's the way it is now. No, it isn't. Describe accepts both prepared statement and portal names. In the former case, it returns ParameterDesc

Re: [HACKERS] libpq and prepared statements progress for 8.0

(I apologise for the delayed response.) At 2004-10-07 01:23:56 -0400, [EMAIL PROTECTED] wrote: > > So why is this part of the patch ok? Isn't it going to make libpq get > confused every time a PQExecPrepared sends a v3.0 prepare message? I thought about that for a while, but I couldn't find anyth

Re: [HACKERS] Nearing final release?

At 2004-10-16 18:41:05 -0400, [EMAIL PROTECTED] wrote: > > I think the cleanest solution is probably to add a state flag indicating > whether ParseComplete should generate a PGresult or not. Like the appended (incremental) patch? (I didn't think this would work, because I thought libpq would allo

Re: [HACKERS] libpq and prepared statements progress for 8.0

At 2004-10-05 17:48:27 -0400, [EMAIL PROTECTED] wrote: > > Searching for all references to one of the existing entry points such > as PQexecPrepared will probably help you identify what you need to do. OK. I've attached two additional patches below. I don't really understand how the *.def files w

Re: [HACKERS] libpq and prepared statements progress for 8.0

;: /* Bind Complete */ case '3': /* Close Complete */ /* Nothing to do for these message types */ /* * Test program for PQprepare/PQdescribe. * Abhijit Menon-Sen <[EMAIL PROTECTED]>

[HACKERS] postgres protocol dissector plugin for ethereal

This weekend, I decided to teach Ethereal to decode the FE/BE protocol properly: until now, it could only extract likely-looking strings from the conversation, which I found woefully inadequate for debugging. I'm hoping the result will be useful to other people too:

Re: [HACKERS] postgres protocol dissector plugin for ethereal

At 2004-12-19 17:56:00 +0530, [EMAIL PROTECTED] wrote: > > I've asked the Ethereal people if they want to distribute this with > Ethereal. It's in Ethereal CVS now. -- ams ---(end of broadcast)--- TIP 2: you can get off all lists at once with the u

Re: [HACKERS] Copyright update

At 2004-12-31 23:49:35 -0500, pgman@candle.pha.pa.us wrote: > > With 8.0 coming out in 2005, I think I should update the copyrights on > the files. I don't think it actually makes any difference. -- ams ---(end of broadcast)--- TIP 3: if posting/re

Re: [HACKERS] Allow GRANT/REVOKE permissions to be applied to all

At 2005-02-01 11:02:52 +0100, [EMAIL PROTECTED] wrote: > > We really should reimplement our query language in Scheme and > implement SQL on top of that. It will make many things much > easier. :-) Speaking of which, see -- ams ---(end

Re: [HACKERS] Allow GRANT/REVOKE permissions to be applied to all

At 2005-02-01 16:31:32 +0530, [EMAIL PROTECTED] wrote: > > Speaking of which, see Actually, -- ams ---(end of broadcast)--- TIP 3: if posting/reading through Usen

Re: [HACKERS] Patent issues and 8.1

At 2005-02-07 12:28:34 -0500, [EMAIL PROTECTED] wrote: > > > There was some mention of an upgrade tool which would avoid the need > > for a dump/restore - did that idea die? > > No, but I don't see anyone volunteering to work on it now I like the idea of having a working pg_upgrade (independent o

Re: [HACKERS] UTF8 or Unicode

At 2005-02-14 21:14:54 -0500, pgman@candle.pha.pa.us wrote: > > Should our multi-byte encoding be referred to as UTF8 or Unicode? The *encoding* should certainly be referred to as UTF-8. Unicode is a character set, not an encoding; Unicode characters may be encoded with UTF-8, among other things.

[HACKERS] postgres crashing on a seemingly good query

Summary: I can crash 7.4-CVS and 8.0/HEAD by sending what appears to be a valid query. I'm trying to insert a unique entry into this table: create table bodyparts ( id serial primary key, bytes integer not null, lines integer not null, has

Re: [HACKERS] postgres crashing on a seemingly good query

At 2005-02-19 21:38:56 +0530, [EMAIL PROTECTED] wrote: > > Summary: I can crash 7.4-CVS and 8.0/HEAD by sending what appears to be > a valid query. A couple of things I forgot to mention: 1. I turned the logging all the way up and I've uploaded the messages from the crashing backend to

Re: [HACKERS] postgres crashing on a seemingly good query

At 2005-02-19 21:38:56 +0530, [EMAIL PROTECTED] wrote: > > I couldn't reproduce this with SQL PREPARE/EXECUTE statements in psql, > so I conjectured that it may have something to do with the parameter > types being unspecified. I added a statement-describe message between > the parse and the bind,

Re: [HACKERS] postgres crashing on a seemingly good query

At 2005-02-19 23:18:01 +0530, [EMAIL PROTECTED] wrote: > > If I change my code (by means of an unspeakably vile hack, but never > mind that) to specify each parameter types in the parse message, the > server no longer crashes. In fact, it works if I specify only the two integer types, and leave th

[HACKERS] a fast bloat measurement tool (was Re: Measuring relation free space)

which have no visibility map). (Just drop the attached files into contrib/fastbloat, and "make install" should just work. Then just "create extension fastbloat".) Questions and suggestions welcome. -- Abhijit /* * contrib/fastbloat/fastbloat.c * * Abhijit Menon-Sen * Portion

Re: [HACKERS] a fast bloat measurement tool

At 2014-04-02 20:10:54 -0400, robertmh...@gmail.com wrote: > > I think it might underestimate free space relative to tuples because > the free space map isn't guaranteed to be completely correct. But I > guess you knew that already... Yes, and tuple_len is already a slight overestimate (because i

[HACKERS] allowing VACUUM to be cancelled for conflicting locks

Hi. In the past, we've had situations where "everything is hung" turned out to be because of a script that ran manual VACUUM that was holding some lock. It's admittedly not a huge problem, but it might be useful if a manual VACUUM could be cancelled the way autovacuum can be. One way to do this w

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

At 2014-05-02 14:04:27 -0400, sfr...@snowman.net wrote: > > I'd really like to see us be able to, say, log to a table and have > more fine-grained control over what is logged, without needing an > extension. There were several factors we considered in our work: 1. We did the minimum possible to p

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

At 2014-05-02 14:22:23 -0400, sfr...@snowman.net wrote: > > I'm aware and I really am not convinced that pushing all of this to > contrib modules using the hooks is the right approach- for one thing, > it certainly doesn't seem to me that we've actually gotten a lot of > traction from people to act

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

At 2014-05-04 08:52:42 -0400, sfr...@snowman.net wrote: > > This also addresses things like anonymous DO blocks and functions > then..? With enough information to be useful for forensics? For DML, it addresses anything that goes through InitPlan (which, via ExecCheckRTPerms, calls the ExecutorChe

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

At 2014-05-04 11:03:56 -0400, sfr...@snowman.net wrote: > > Another reloption is one option, or an extension on the ACL system > (for that piece of it), or we could make a new catalog for it (ala > pg_seclabel), or perhaps add it on to one (pg_seclabel but rename > it to pg_security..?). I'll look

Re: [HACKERS] 9.5 commit fest schedule

At 2014-05-22 07:22:42 -0400, pete...@gmx.net wrote: > > We need a volunteer to manage the first commit fest. I volunteer. -- Abhijit -- 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] idle_in_transaction_timeout

At 2014-06-03 15:06:11 +0200, vik.fear...@dalibo.com wrote: > > This patch implements a timeout for broken clients that idle in > transaction. I think this is a nice feature, but I suggest that (at the very least) the GUC should be named "idle_transaction_timeout". > + > + Termina

[HACKERS] pg_xlogdump --stats

dd it to the CF. -- Abhijit commit 1d687aeea278e0313071c238e6c3dc04e3e8b798 Author: Abhijit Menon-Sen Date: Wed Jun 4 14:22:33 2014 +0530 Make 'pg_xlogdump --stats[=record]' display summary statistics diff --git a/contrib/pg_xlogdump/pg_xlogdump.c b/contrib/pg_xlogdump/pg_xlogdump.c index 824b

<    1   2   3   4   5