On Wed, Jan 9, 2013 at 1:47 PM, Andres Freund wrote:
> On 2013-01-09 13:34:12 +0100, Magnus Hagander wrote:
>> Am I the only one who finds this way of posting patches really annoying?
>
> Well, I unsurprisingly don't ;)
Yeah, that's not surprising :)
>> Here is a patch with no description other
On 2013-01-09 13:34:12 +0100, Magnus Hagander wrote:
> Am I the only one who finds this way of posting patches really annoying?
Well, I unsurprisingly don't ;)
> Here is a patch with no description other than a list of changed
> files. And discussion happens in a completely different email.
They
I've set up commifest topics for CFJan15.
This will allow people to move across any patches from earlier commitfests.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
Am I the only one who finds this way of posting patches really annoying?
Here is a patch with no description other than a list of changed
files. And discussion happens in a completely different email.
What's wrong with just posting the patch as a regular attachment(s) to
a regular thread, like ot
On 2013-01-09 15:06:04 +0530, Amit Kapila wrote:
> On Wednesday, January 09, 2013 2:28 PM Andres Freund wrote:
> > On 2013-01-09 14:04:32 +0530, Amit Kapila wrote:
> > > On Tuesday, January 08, 2013 8:57 PM Andres Freund wrote:
> > > > On 2013-01-08 20:33:28 +0530, Amit Kapila wrote:
> > > > > On T
On 9 January 2013 12:06, Amit Kapila wrote:
> On Wednesday, January 09, 2013 4:52 PM Simon Riggs wrote:
>> On 24 December 2012 16:57, Amit Kapila wrote:
>>
>> > Performance: Average of 3 runs of pgbench in tps
>> > 9.3devel | with trailing null patch
>> > --+--
>
On Wednesday, January 09, 2013 4:57 PM Simon Riggs wrote:
> On 9 January 2013 08:05, Amit kapila wrote:
>
> > Update patch contains handling of below Comments
>
> Thanks
>
>
> > Test results with modified pgbench (1800 record size) on the latest
> patch:
> >
> > -Patch- -tps@-c1-
On Wednesday, January 09, 2013 4:52 PM Simon Riggs wrote:
> On 24 December 2012 16:57, Amit Kapila wrote:
>
> > Performance: Average of 3 runs of pgbench in tps
> > 9.3devel | with trailing null patch
> > --+--
> > 578.9872 | 573.4980
>
> On balance, it would
On 9 November 2012 18:50, Jeff Janes wrote:
> quadratic behavior in the resource owner/lock table
I didn't want to let that particular phrase go by without saying
"exactly what behaviour is that?", so we can discuss fixing that also.
This maybe something I already know about, but its worth aski
On 2013-01-09 13:46:53 +0200, Heikki Linnakangas wrote:
> On 09.01.2013 13:27, Andres Freund wrote:
> >- makes palloc() into a real function so CurrentMemoryContext doesn't
> > need to be provided
>
> I don't understand the need for this change. Can't you just:
>
> #define palloc(s) pg_malloc(s)
On 23 November 2012 22:34, Jeff Janes wrote:
> I got rid of need_eoxact_work entirely and replaced it with a short
> list that fulfills the functions of indicating that work is needed,
> and suggesting which rels might need that work. There is no attempt
> to prevent duplicates, nor to remove in
On 09.01.2013 13:27, Andres Freund wrote:
- makes palloc() into a real function so CurrentMemoryContext doesn't
need to be provided
I don't understand the need for this change. Can't you just:
#define palloc(s) pg_malloc(s)
in the frontend context?
- Heikki
--
Sent via pgsql-hackers mai
---
contrib/oid2name/oid2name.c| 52 +
contrib/pg_upgrade/pg_upgrade.h| 5 +-
contrib/pg_upgrade/util.c | 49 -
contrib/pgbench/pgbench.c | 54 +-
src/backend/utils/mmgr/mcxt.c | 78 +++
Here is an implementation of the
information_schema.parameters.parameter_default column.
I ended up writing a C function to decode the whole thing from the
system catalogs, because it was too complicated in SQL, so I abandoned
the approach discussed in [0].
[0]:
http://archives.postgresql.org/m
Hi,
As promised here's a patch to provide palloc emulation for frontend-ish
environments.
The patch:
- makes palloc() into a real function so CurrentMemoryContext doesn't
need to be provided
- provides common pg_(malloc,malloc0, realloc, strdup, free) wrappers
and removes various versions of
---
src/bin/pg_resetxlog/pg_resetxlog.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/bin/pg_resetxlog/pg_resetxlog.c b/src/bin/pg_resetxlog/pg_resetxlog.c
index 8734f2c..60fb30c 100644
--- a/src/bin/pg_resetxlog/pg_resetxlog.c
+++ b/src/bin/pg_resetxlog/pg_resetxlog
On 9 January 2013 08:05, Amit kapila wrote:
> Update patch contains handling of below Comments
Thanks
> Test results with modified pgbench (1800 record size) on the latest patch:
>
> -Patch- -tps@-c1- -WAL@-c1- -tps@-c2- -WAL@-c2-
> Head831 4
On 24 December 2012 16:57, Amit Kapila wrote:
> Performance: Average of 3 runs of pgbench in tps
> 9.3devel | with trailing null patch
> --+--
> 578.9872 | 573.4980
On balance, it would seem optimizing for this special case would
affect everybody negatively;
One thing i'd really like to be in this common object info catalog is DDL which
created or altered the referenced object.
If we additionally could make it possible to have ordinary triggers on this
catalog it would solve most logical DDL replication problems
Hannu
Sent from Samsung Galaxy N
Re: Tom Lane 2013-01-09 <9802.1357702...@sss.pgh.pa.us>
> Item: there is not a test for perl.h, as such, in configure. There
> probably should be, just because we have comparable tests for tcl.h
> and Python.h. However, adding one won't fix your problem on
> Debian-based distros, because for some
On Wednesday, January 09, 2013 2:28 PM Andres Freund wrote:
> On 2013-01-09 14:04:32 +0530, Amit Kapila wrote:
> > On Tuesday, January 08, 2013 8:57 PM Andres Freund wrote:
> > > On 2013-01-08 20:33:28 +0530, Amit Kapila wrote:
> > > > On Tuesday, January 08, 2013 8:01 PM Andres Freund wrote:
> > >
On 9 January 2013 01:51, Josh Berkus wrote:
> Anyway, I'm not saying we solve this now. I'm saying, "put it on the
> TODO list in case someone has time/an itch to scratch".
I think its reasonable to ask whether a usability feature needs to
exist whenever a problem is encountered. That shouldn't
On 2013-01-09 14:04:32 +0530, Amit Kapila wrote:
> On Tuesday, January 08, 2013 8:57 PM Andres Freund wrote:
> > On 2013-01-08 20:33:28 +0530, Amit Kapila wrote:
> > > On Tuesday, January 08, 2013 8:01 PM Andres Freund wrote:
> > > > On 2013-01-08 19:51:39 +0530, Amit Kapila wrote:
> > > > > On Mon
Hello
On Czech pg mailing list was reported issue about problems with
boolean based domains and XML functions.
There are maybe more issues, but probably there is little bit strange
and unexpected result
postgres=# CREATE DOMAIN booldomain as bool;
CREATE DOMAIN
-- fully expected behave
postgres
On Wed, Jan 9, 2013 at 2:01 AM, Josh Berkus wrote:
> All,
>
> >> Well, the problem of "find out the box's physical RAM" is doubtless
> >> solvable if we're willing to put enough sweat and tears into it, but
> >> I'm dubious that it's worth the trouble. The harder part is how to know
> >> if the
On Tuesday, January 08, 2013 8:57 PM Andres Freund wrote:
> On 2013-01-08 20:33:28 +0530, Amit Kapila wrote:
> > On Tuesday, January 08, 2013 8:01 PM Andres Freund wrote:
> > > On 2013-01-08 19:51:39 +0530, Amit Kapila wrote:
> > > > On Monday, January 07, 2013 7:15 PM Andres Freund wrote:
> > > >
On 01/08/2013 10:37 PM, Tom Lane wrote:
We could try adding an AC_TRY_LINK test using perl_embed_ldflags,
but given the weird stuff happening to redefine that value on Windows
in plperl/GNUmakefile I think there's a serious risk of breaking Cygwin
builds. Since I lack access to either Cygwin o
101 - 127 of 127 matches
Mail list logo
