Hi,
I'm sending small patch for textsend. It reduces unnecessary copies, and
memory usage for duplication of varlena data. May you look?
Kind regards,
Radosław Smogura
diff --git a/src/backend/utils/adt/varlena.c b/src/backend/utils/adt/varlena.c
index e111d26..f24bbcd 100644
--- a/src/backend/u
Robert Haas wrote:
With the fsync queue compaction patch applied, I think most of this is
now not needed. Attached please find an attempt to isolate the
portion that looks like it might still be useful. The basic idea of
what remains here is to make the background writer still do its normal
stu
On Fri, 4 Feb 2011 10:10:56 -0500
Robert Haas wrote:
> Was there supposed to be a patch attached here? Or where is it? We
> are past out of time to get this committed, and there hasn't been a
> new version in more than two weeks.
Sorry for late to post patches.
Attached are revised version of fi
On Mon, 31 Jan 2011 22:00:55 +0900
Shigeru HANADA wrote:
> I'll post FDW API patches which reflect comments first, and then I'll
> rebase postgresql_fdw against them.
Sorry for late, attached are revised version of FDW API patches which
reflect Heikki's comments except removing catalog lookup via
On Sun, Feb 6, 2011 at 2:12 PM, Jaime Casanova wrote:
> On Tue, Feb 1, 2011 at 11:32 PM, Joachim Wieland wrote:
>> On Sun, Jan 30, 2011 at 5:26 PM, Robert Haas wrote:
>>> The parallel pg_dump portion of this patch (i.e. the still-uncommitted
>>> part) no longer applies. Please rebase.
>>
>> Her
On Mon, Feb 07, 2011 at 12:04:02AM -0500, Robert Haas wrote:
> On Sun, Feb 6, 2011 at 8:18 PM, Noah Misch wrote:
> >> Or how about passing an ObjectType? ?Then we could specify
> >> OBJECT_TABLE, OBJECT_FOREIGN_TABLE, or OBJECT_TYPE.
> >
> > Could this be done without a several-line blob of code a
On Sun, Feb 6, 2011 at 5:03 PM, Andrew Dunstan wrote:
> Yeah, this bit of the Makefile looks bogus:
>
> sepgsql-regtest.pp: sepgsql-regtest.te
> $(MAKE) -f $(DESTDIR)/usr/share/selinux/devel/Makefile $@
>
I agree. That looks bogus. KaiGai?
--
Robert Haas
EnterpriseDB: http://www.ente
On Sun, Feb 6, 2011 at 6:44 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Thu, Jul 22, 2010 at 1:41 AM, Fujii Masao wrote:
>> > We should enclose -1 with tag.
>>
>> A quick survey of the documentation as a whole suggests that we
>> enclose -1 with in a few places but more commonly we don'
2011/2/7 Jan Urbański :
> On 04/02/11 16:26, Hitoshi Harada wrote:
>> 2011/1/28 Jan Urbański :
>>> On 27/01/11 00:41, Jan Urbański wrote:
I'm also attaching an updated version that should apply on top of my
github refactor branch (or incrementally over the new set of refactor
patches
On Sun, Feb 6, 2011 at 8:18 PM, Noah Misch wrote:
>> Or how about passing an ObjectType? Then we could specify
>> OBJECT_TABLE, OBJECT_FOREIGN_TABLE, or OBJECT_TYPE.
>
> Could this be done without a several-line blob of code at each call site to
> determine the answer? If and only if so, this so
On Sun, Feb 6, 2011 at 1:23 PM, Tom Lane wrote:
> I've not attempted to implement this idea, but offhand it looks like
> it would take a day or two's work, which seems well worthwhile to
> expend now in the hope of getting this feature right the first time.
>
> Comments?
The design you propose se
On Sun, Feb 6, 2011 at 11:12 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Bruce Momjian wrote:
>>> remove tags.
>
>> Sorry, vague commit message (I forgot squash).
>
>> Can I will use git ammend to improve this message?
Absolutely not.
> How about git revert, instead? It's not apparent to me
Bruce Momjian writes:
> Bruce Momjian wrote:
>> remove tags.
> Sorry, vague commit message (I forgot squash).
> Can I will use git ammend to improve this message?
How about git revert, instead? It's not apparent to me that these
changes were improvements.
regards, tom
On 02/06/2011 09:13 PM, Alex Hunsaker wrote:
I would have loved to add some regression
tests for some of this (like the example hek2cstr states). Is there
any way to do that?
I can't think of an obvious way. Anyone else?
cheers
ndrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Sun, Feb 6, 2011 at 18:02, Andrew Dunstan wrote:
>
>
>
>
>
> On 02/06/2011 05:31 PM, Andrew Dunstan wrote:
>>
>> Force strings passed to and from plperl to be in UTF8 encoding.
>>
>> String are converted to UTF8 on the way into perl and to the
>> database encoding on the way back. This avoids a
On Sun, Feb 06, 2011 at 12:54:19PM -0500, Robert Haas wrote:
> On Sun, Feb 6, 2011 at 12:13 PM, Robert Haas wrote:
> > That's not quite so good for translators, I think.
> >
> > Another option is that we could just say "relation" (table, foreign
> > table, etc...) or "type". ?We use the word relat
On 02/06/2011 05:31 PM, Andrew Dunstan wrote:
Force strings passed to and from plperl to be in UTF8 encoding.
String are converted to UTF8 on the way into perl and to the
database encoding on the way back. This avoids a number of
observed anomalies, and ensures Perl a consistent view of the
On Feb 6, 2011, at 10:23 AM, Tom Lane wrote:
> I've not attempted to implement this idea, but offhand it looks like
> it would take a day or two's work, which seems well worthwhile to
> expend now in the hope of getting this feature right the first tim
Seems worthwhile, and a much better approach
Robert Haas wrote:
> On Thu, Jul 22, 2010 at 1:41 AM, Fujii Masao wrote:
> > We should enclose -1 with tag.
>
> A quick survey of the documentation as a whole suggests that we
> enclose -1 with in a few places but more commonly we don't.
> I have no position on whether we should do it or not, b
On Sun, 2011-02-06 at 12:07 -0500, Robert Haas wrote:
> On Sun, Feb 6, 2011 at 11:16 AM, Bruce Momjian wrote:
> > I assume having psql support multiple -f files is not a high priority or
> > something we don't want.
>
> IIRC, nobody objected to the basic concept, and it seems useful. I
> thought
On Sun, 30 Jan 2011 21:26:22 +0100, Magnus Hagander
wrote:
it's not something we should hold up the CF / release for.
I agree.
At least it should get some more testing besides mine.
I've set up virtual machines with VS 2003, VS 2005 Express, VS 2008
Express (+ my PC with VS 2010) for testing
On 02/05/2011 12:58 AM, Vladimir Kokovic wrote:
make -C sepgsql all
make[2]: Entering directory
`/media/sda5/postgresql-9.1devel/build/contrib/sepgsql'
sed 's,MODULE_PATHNAME,$libdir/sepgsql,g'
/media/sda5/postgresql-9.1devel/build/../../tmp/postgresql-git/postgresql/contrib/sepgsql/sepgsql.
Hi,
My build script:
-
#!/bin/sh
set -v
set -e
cd /media/sda5/postgresql-9.1devel/build
export CFLAGS="-g3 -gdwarf-2"
../../tmp/postgresql-git/postgresql/configure
'--srcdir=../../tmp/postgresql-git/postgresql' '--enable-cassert' \
'--enable-nls' '--
On Sun, 2011-02-06 at 12:11 -0500, Bruce Momjian wrote:
> Did this ever get addressed?
Patch attached.
Seems like the easiest fix I can come up with.
> Simon Riggs wrote:
> >
> > As part of a performance investigation for a customer I've noticed an
> > O(N^2) performance issue on COMMITs of tra
"Kevin Grittner" wrote:
> Jeff Davis wrote:
>
>> What does PredicateLockTuple do that needs a share lock? Does a
>> pin suffice?
>
> If one process is reading a tuple and another is writing it (e.g.,
> UPDATE or DELETE) the concern is that we need to be able to
> guarantee that either the predi
On 27/01/11 23:24, Jan Urbański wrote:
> On 11/01/11 12:20, Jan Urbański wrote:
>> On 11/01/11 01:27, Tom Lane wrote:
>>> Hannu Krosing writes:
On 10.1.2011 17:20, Jan Urbański wrote:
> I changed that patch to use Perl instead of sed to generate the
> exceptions, which should be a mor
Jeff Davis wrote:
> On Sat, 2011-02-05 at 14:43 -0600, Kevin Grittner wrote:
>> In working on this I noticed the apparent need to move two calls
>> to PredicateLockTuple a little bit to keep them inside the buffer
>> lock. Without at least a share lock on the buffer, it seems that
>> here is a
On Sun, February 6, 2011 07:41, Jeff Davis wrote:
> New patch. All known TODO items are closed, although I should do a
I've been testing and find the patch to be
generally very stable.
More review follows ASAP, but I wanted to mention
this curious 'bug' already.
(below all with latest git + pa
On Sat, 2011-02-05 at 14:43 -0600, Kevin Grittner wrote:
> "Kevin Grittner" wrote:
>
> > So now that I'm sure we actually do need code there, I'll add it.
>
> In working on this I noticed the apparent need to move two calls to
> PredicateLockTuple a little bit to keep them inside the buffer lo
On Tue, Feb 1, 2011 at 11:32 PM, Joachim Wieland wrote:
> On Sun, Jan 30, 2011 at 5:26 PM, Robert Haas wrote:
>> The parallel pg_dump portion of this patch (i.e. the still-uncommitted
>> part) no longer applies. Please rebase.
>
> Here is a rebased version with some minor changes as well. I have
On 27/01/11 22:58, Jan Urbański wrote:
> On 23/12/10 14:56, Jan Urbański wrote:
>> Here's a patch implementing traceback support for PL/Python mentioned in
>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
>> an incremental patch on top of the plpython-refactor patch sent e
Em 06-02-2011 13:09, Bruce Momjian escreveu:
What happened to this idea/patch?
I refactored the patch [1] to not depend on strtoll.
[1] http://archives.postgresql.org/message-id/4d2cccd9@timbira.com
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mai
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> Could you try to "make html" in the doc directory?
Yeah, doesn't seem to work for me (missing '/bin/collateindex.pl',
apparently..).
> Your new decumentation after
> | These columns may be included in the CSV output:
> will be unaligned pla
On 06/02/11 10:54, Jan Urbański wrote:
> On 04/02/11 18:10, Hitoshi Harada wrote:
>> 2011/1/11 Jan Urbański :
>>> Here's a patch that adds a few PL/Python functions for quoting strings.
>>> It's an incremental patch on top of the plpython-refactor patch sent in
>>> http://archives.postgresql.org/me
"Kevin Grittner" wrote:
> I'm working on it now, and hope to have it all settled down today.
Done and pushed to the git repo. Branch serializable on:
git://git.postgresql.org/git/users/kgrittn/postgres.git
Heikki: I'm back to not having any outstanding work on the patch.
Does anyone wan
As I work through the extensions patch, the aspect of it that I like the
least is the NO USER DATA clause and related functions. I think it's
badly designed, badly implemented, and doesn't solve the problem.
If we accept it as-is, we'll soon have to rework it, and at that point
we'll be left with
Ibrar,
* Ibrar Ahmed (ibrar.ah...@gmail.com) wrote:
> I have reviewed/tested this patch.
Great, thanks for that!
> In my point code should be like this
>
> *if (conn->client_encoding_initial && conn->client_encoding_initial[0])
>{
>if (packet)
>{
>
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> I agree that it's logically good design, but we could not accept it
> as long as it breaks tools in the real world...
If it does, I think it's pretty clear that those tools are themselves
broken..
> Will it break "SHOW ALL" and "SELECT * FR
On 04/02/11 17:19, Hitoshi Harada wrote:
> 2011/1/28 Jan Urbański :
>> On 23/12/10 15:15, Jan Urbański wrote:
>>> Here's a patch implementing custom parsers for data types mentioned in
>>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
>>> an incremental patch on top of the
On Sun, Feb 6, 2011 at 12:13 PM, Robert Haas wrote:
> That's not quite so good for translators, I think.
>
> Another option is that we could just say "relation" (table, foreign
> table, etc...) or "type". We use the word relation as a more generic
> version of table in a few other places.
Or how
On Sun, Feb 6, 2011 at 8:58 AM, Noah Misch wrote:
> On Sun, Feb 06, 2011 at 08:40:44AM -0500, Noah Misch wrote:
>> On Sun, Feb 06, 2011 at 07:54:52AM -0500, Robert Haas wrote:
>> > Yeeah, that's actually a little ugly. It's actually a domain
>> > over a composite type, not a composite type p
Did this ever get addressed?
---
Simon Riggs wrote:
>
> As part of a performance investigation for a customer I've noticed an
> O(N^2) performance issue on COMMITs of transactions that contain many
> SAVEPOINTs. I've consis
On Sun, Feb 6, 2011 at 11:16 AM, Bruce Momjian wrote:
> I assume having psql support multiple -f files is not a high priority or
> something we don't want.
IIRC, nobody objected to the basic concept, and it seems useful. I
thought we were pretty close to committing something along those lines
at
On 6.2.2011 08:17, Greg Smith wrote:
> Below is what changed since the last posted version, mainly as feedback
> for Tomas:
>
> -Explained more clearly that pg_stat_reset and
> pg_stat_reset_single_counters will both touch the database reset time,
> and that it's initialized upon first connection
I wrote:
> First cut [of having predicate locks linked to later row versions
> for conflict detection purposes]
> It passes all the usual regression tests, the new isolation tests,
> and the example posted earlier in the thread of a test case which
> was allowing an anomaly. (That is to say, th
On 02/02/11 14:16, Steve Singer wrote:
> On 11-01-27 05:11 PM, Jan Urbański wrote:
>> On 23/12/10 15:32, Jan Urbański wrote:
>>> Here's a patch implementing explicitly starting subtransactions
>>> mentioned in
>>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
>>> an increm
I assume having psql support multiple -f files is not a high priority or
something we don't want.
---
Mark Wong wrote:
> Hi all,
>
> I took a stab at changing this up a little bit. I pushed the logic
> that David introduce
On 04/02/11 16:26, Hitoshi Harada wrote:
> 2011/1/28 Jan Urbański :
>> On 27/01/11 00:41, Jan Urbański wrote:
>>> I'm also attaching an updated version that should apply on top of my
>>> github refactor branch (or incrementally over the new set of refactor
>>> patches that I will post shortly to th
What happened to this idea/patch?
---
Greg Smith wrote:
> Tom Lane wrote:
> > Please choose a way that doesn't introduce new portability assumptions.
> > The backend gets along fine without strtoll, and I don't see why pgben
On Sun, Feb 6, 2011 at 23:31, Stephen Frost wrote:
> * Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
>> I think we need to improve postgresql.conf.sample a bit more, especially
>> the long line for #log_csv_fields = '...'. 330 characters in it!
>> #1. Leave the long line because it is nee
* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> I think we need to improve postgresql.conf.sample a bit more, especially
> the long line for #log_csv_fields = '...'. 330 characters in it!
> #1. Leave the long line because it is needed.
It's needed to match what the current default is..
On Sun, Feb 6, 2011 at 8:47 AM, Noah Misch wrote:
> On Sun, Feb 06, 2011 at 08:15:30AM -0500, Robert Haas wrote:
>> On Sun, Feb 6, 2011 at 5:52 AM, Noah Misch wrote:
>> > 1. Add PLpgSQL_var.should_be_detoasted; check it in plpgsql_param_fetch().
>> > Essentially Pavel's original patch, only with
On Sun, Feb 06, 2011 at 08:40:44AM -0500, Noah Misch wrote:
> On Sun, Feb 06, 2011 at 07:54:52AM -0500, Robert Haas wrote:
> > Yeeah, that's actually a little ugly. It's actually a domain
> > over a composite type, not a composite type proper, IIUC. Better
> > ideas?
>
> There are no domains
On Sun, Feb 06, 2011 at 08:15:30AM -0500, Robert Haas wrote:
> On Sun, Feb 6, 2011 at 5:52 AM, Noah Misch wrote:
> > 1. Add PLpgSQL_var.should_be_detoasted; check it in plpgsql_param_fetch().
> > Essentially Pavel's original patch, only with the check logic moved up from
> > exec_eval_datum() to p
On Sun, Feb 06, 2011 at 07:54:52AM -0500, Robert Haas wrote:
> On Sun, Feb 6, 2011 at 4:15 AM, Noah Misch wrote:
> >> That didn't quite work, because there's a caller in typecmds.c that
> >> doesn't have the relation handy. ?So I made it take a relkind and a
> >> name, which works fine.
> >
> > Hm
On Sun, Feb 6, 2011 at 5:52 AM, Noah Misch wrote:
> 1. Add PLpgSQL_var.should_be_detoasted; check it in plpgsql_param_fetch().
> Essentially Pavel's original patch, only with the check logic moved up from
> exec_eval_datum() to plpgsql_param_fetch() to avoid bothering a couple other
> callers that
On Sun, Feb 6, 2011 at 4:15 AM, Noah Misch wrote:
>> That didn't quite work, because there's a caller in typecmds.c that
>> doesn't have the relation handy. So I made it take a relkind and a
>> name, which works fine.
>
> Hmm, indeed. In get_rels_with_domain(), it's a scalar type.
Yeeah, th
Let's see if I can summarize the facts we've collected so far. I see four
options based on the discussion:
1. Add PLpgSQL_var.should_be_detoasted; check it in plpgsql_param_fetch().
Essentially Pavel's original patch, only with the check logic moved up from
exec_eval_datum() to plpgsql_param_fetc
On 04/02/11 18:10, Hitoshi Harada wrote:
> 2011/1/11 Jan Urbański :
>> Here's a patch that adds a few PL/Python functions for quoting strings.
>> It's an incremental patch on top of the plpython-refactor patch sent in
>> http://archives.postgresql.org/message-id/4d135170.3080...@wulczer.org.
>>
>>
On 02/02/11 14:16, Steve Singer wrote:
> On 11-01-27 05:11 PM, Jan Urbański wrote:
>> On 23/12/10 15:32, Jan Urbański wrote:
>>> Here's a patch implementing explicitly starting subtransactions
>>> mentioned in
>>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
>>> an increm
On Sun, Feb 06, 2011 at 02:15:47AM -0500, Robert Haas wrote:
> On Sat, Feb 5, 2011 at 7:44 PM, Noah Misch wrote:
> >> But this is a little unsatisfying, for two reasons. ?First, the error
> >> message will be subtly wrong: we can make it complain about a table or
> >> a type, but not a foreign tab
61 matches
Mail list logo
