On Sun, Jan 9, 2011 at 5:01 PM, Noah Misch wrote:
> This patch removes ALTER TYPE rewrites in cases we can already prove valid. I
> add a function GetCoerceExemptions() that walks an Expr according to rules
> discussed in the design thread, simplified slightly pending additions in the
> next patc
On 23 January 2011 13:14, Andrew Dunstan wrote:
> But there are quite a few perlheads around. ISTR Matt Trout was muttering
> about these scripts on IRC recently.
A quick cleanup of the check_rules.pl...
It's a starting point at least.
ecpg_prepoc_check_rules_cleanup.patch
Description: Binary
On Sat, Jan 22, 2011 at 10:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jan 22, 2011 at 9:50 PM, Tom Lane wrote:
>>> So I don't want to give up the details of the function
>>> or operator. But sticking them at the end after a colon might make it
>>> clearer that the func/operator is
Robert Haas writes:
> On Sat, Jan 22, 2011 at 9:50 PM, Tom Lane wrote:
>> So I don't want to give up the details of the function
>> or operator. But sticking them at the end after a colon might make it
>> clearer that the func/operator is referenced by the amproc or amop
>> entry, but is not the
Robert Haas writes:
> On Sat, Jan 22, 2011 at 9:42 PM, Tom Lane wrote:
>> It does strike me that we could provide SetConfigOptionInt,
>> SetConfigOptionBool, and SetConfigOptionReal for the benefit of callers
>> who'd prefer to pass values in those formats. They'd still do sprintf
>> internally,
On Sat, Jan 22, 2011 at 9:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jan 16, 2011 at 2:28 PM, Tom Lane wrote:
>>> If we were to go with this, I'd be strongly tempted to rearrange all
>>> four of the messages involved to put the operator or function name
>>> at the end, eg
>>>
>>> fu
On Sat, Jan 22, 2011 at 9:42 PM, Tom Lane wrote:
> Robert Haas writes:
>>> Oh, you're complaining about SetConfigOption, not the assign hooks.
>
>> I was actually complaining about the latter, and then switched gears
>> to the former. I'm an equal-opportunity complainer today, I guess...
>
> It
Robert Haas writes:
> On Sun, Jan 16, 2011 at 2:28 PM, Tom Lane wrote:
>> If we were to go with this, I'd be strongly tempted to rearrange all
>> four of the messages involved to put the operator or function name
>> at the end, eg
>>
>> function 1 (oidvector[], oidvector[]) of operator family ar
Hi,
I know you people have talked a lot about this, but until now I still
can't install the newest release installed on my new Win7 Home basic 64 bit
notebook, the user I run has administration previliege, and I have tried C
and POSIX locale, neither works. The error message are the same:
Probl
Robert Haas writes:
>> Oh, you're complaining about SetConfigOption, not the assign hooks.
> I was actually complaining about the latter, and then switched gears
> to the former. I'm an equal-opportunity complainer today, I guess...
It does strike me that we could provide SetConfigOptionInt,
Se
On Sun, Jan 16, 2011 at 2:28 PM, Tom Lane wrote:
> Andreas Karlsson writes:
>> On Sat, 2011-01-15 at 10:36 -0500, Tom Lane wrote:
>>> But I can read the handwriting on the wall: if I want this done right,
>>> I'm going to have to do it myself.
>
>> Do I understand you correctly if I interpret wha
On Sat, Jan 22, 2011 at 9:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'm going with hacks. Any API that requires you to print to a string
>> so you can turn around and immediately convert it back to an integer
>> is not too swift.
>
> Oh, you're complaining about SetConfigOption, not the as
Robert Haas writes:
> I'm going with hacks. Any API that requires you to print to a string
> so you can turn around and immediately convert it back to an integer
> is not too swift.
Oh, you're complaining about SetConfigOption, not the assign hooks.
Not sure if it's really worth refactoring tha
On Thu, Jan 20, 2011 at 5:22 AM, Marko Tiikkaja
wrote:
> On 2011-01-17 9:28 AM +0200, Itagaki Takahiro wrote:
>>
>> Here is a short review for Transaction scoped advisory locks:
>> https://commitfest.postgresql.org/action/patch_view?id=518
>
> Thanks for reviewing!
>
>> == Features ==
>> The patch
2011/1/21 KaiGai Kohei :
> Do we have any workaround to avoid these indenting/formatting?
> Or, the reformatted code is better than before?
That's pretty horrendous. Tom/Bruce, any ideas?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pg
I wrote:
> He's complaining that it dies with EINVAL.
> I notice that (1) it's using O_DIRECT even though the printout claims
> otherwise, and (2) it's writing from a buffer that has no better than
> char alignment, which is certainly not OK for O_DIRECT. Either one
> of those could plausibly res
On 01/22/2011 08:48 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 01/22/2011 06:06 PM, Tom Lane wrote:
On Fedora 14 I see these warnings while building ecpg's preproc.y:
Use of assignment to $[ is deprecated at ./parse.pl line 21.
Use of assignment to $[ is deprecated at ./check_rules.pl li
On Sat, Jan 22, 2011 at 9:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> This is certainly shorter than I wrote, which is good, but it strikes
>> me that the fundamental problem here is that the API for an assign
>> hook is fundamentally different for strings than it is for other data
>> types.
On Mon, Jan 17, 2011 at 2:52 PM, Robert Haas wrote:
> On Mon, Jan 17, 2011 at 2:25 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Mon, Jan 17, 2011 at 9:41 AM, Peter Eisentraut wrote:
Maybe instead of the proposed patch, a notice could be added:
NOTICE: existing object was replaced
Robert Haas writes:
> This is certainly shorter than I wrote, which is good, but it strikes
> me that the fundamental problem here is that the API for an assign
> hook is fundamentally different for strings than it is for other data
> types.
I agree that that's annoying, but given that strings ar
On Mon, Jan 3, 2011 at 2:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 3, 2011 at 1:34 PM, Tom Lane wrote:
>>> Yeah, that's exactly it. I can think of some possible uses for
>>> splitting up pg_dump output, but frankly "to ease diff-ing" is not
>>> one of them. For that problem,
On Fri, Jan 21, 2011 at 10:21 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> Upon further review, I am wondering if it wouldn't be simpler and
>> more logical to allow idempotent changes of these settings at any
>> time, and to restrict only changes that actually change something.
>
> I don'
Robert Haas writes:
> On Sat, Jan 22, 2011 at 2:46 AM, Vladimir Kokovic
> wrote:
>> Something is wrong with contrib/pg_test_fsync on Ubuntu 10.10 maverick.
> What, specifically, is wrong?
He's complaining that it dies with EINVAL.
I notice that (1) it's using O_DIRECT even though the printout
On Sat, Jan 22, 2011 at 8:45 PM, Robert Haas wrote:
>> "Just set" means "use SetConfigOption".
>
> OK.
*reads patch as committed*
This is certainly shorter than I wrote, which is good, but it strikes
me that the fundamental problem here is that the API for an assign
hook is fundamentally differe
Robert Haas writes:
>> As penance, I've committed the corrected patch.
> Which is obviously derived from my version rather than Greg's, without credit.
Apologies --- I thought I'd ended up reverting basically all your
changes, so I just credited him.
regards, tom lane
-
Andrew Dunstan writes:
> On 01/22/2011 06:06 PM, Tom Lane wrote:
>> On Fedora 14 I see these warnings while building ecpg's preproc.y:
>>
>> Use of assignment to $[ is deprecated at ./parse.pl line 21.
>> Use of assignment to $[ is deprecated at ./check_rules.pl line 18.
>>
>> Any Perl experts w
On Sat, Jan 22, 2011 at 2:46 AM, Vladimir Kokovic
wrote:
> Something is wrong with contrib/pg_test_fsync on Ubuntu 10.10 maverick.
What, specifically, is wrong?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (p
On Sat, Jan 22, 2011 at 4:25 PM, Dimitri Fontaine
wrote:
> Hi,
>
> This is a first level of review for the patch. I finally didn't get as
> much time as I hoped I would, so couldn't get familiar with the locking
> internals and machinery… as a result, I can't much comment on the code.
>
> The pat
On Sat, Jan 22, 2011 at 8:33 PM, Tom Lane wrote:
> Um: that was probably too brief.
Yep.
> "Just set" means "use SetConfigOption".
OK.
> As penance, I've committed the corrected patch.
Which is obviously derived from my version rather than Greg's, without credit.
--
Robert Haas
EnterpriseDB
On 01/22/2011 06:06 PM, Tom Lane wrote:
On Fedora 14 I see these warnings while building ecpg's preproc.y:
Use of assignment to $[ is deprecated at ./parse.pl line 21.
Use of assignment to $[ is deprecated at ./check_rules.pl line 18.
Any Perl experts want to make those go away?
I wrote:
> Robert Haas writes:
>> Barring screams of agony^W^W^Whelpful suggestions for how to code this
>> more neatly, I'll go ahead and commit this.
> The show_hook sucks, and is unnecessary, as is exposing the format
> function. Just set the GUC variable to the correct value.
Um: that was p
Robert Haas writes:
> Barring screams of agony^W^W^Whelpful suggestions for how to code this
> more neatly, I'll go ahead and commit this.
The show_hook sucks, and is unnecessary, as is exposing the format
function. Just set the GUC variable to the correct value.
regards
On Fedora 14 I see these warnings while building ecpg's preproc.y:
Use of assignment to $[ is deprecated at ./parse.pl line 21.
Use of assignment to $[ is deprecated at ./check_rules.pl line 18.
Any Perl experts want to make those go away?
regards, tom lane
--
Sent via
On 22/01/11 19:38, Tom Lane wrote:
> Buildfarm members bobcat (Fedora 14 x86) and frogmouth (mingw) have
> been showing an assertion failure in the plpython regression tests
> since this patch went in:
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=740e54c
> Given these facts,
On 22/01/11 21:53, Peter Eisentraut wrote:
> On tor, 2011-01-20 at 03:16 +0100, Jan Urbański wrote:
>> Here's an updated patch series for PL/Python refactoring. It was 16
>> patches at first, 8 are committed, 1 got dropped, so we're down to 7.
>
>> Refactor PLy_spi_prepare to save two levels of in
Hi,
This is a first level of review for the patch. I finally didn't get as
much time as I hoped I would, so couldn't get familiar with the locking
internals and machinery… as a result, I can't much comment on the code.
The patch applies cleanly (patch moves one hunk all by itself) and
compiles w
On tor, 2011-01-20 at 03:16 +0100, Jan Urbański wrote:
> Here's an updated patch series for PL/Python refactoring. It was 16
> patches at first, 8 are committed, 1 got dropped, so we're down to 7.
> Refactor PLy_spi_prepare to save two levels of indentation.
>
> Instead of checking if the arglist
I wrote:
> Andrew Dunstan writes:
>> Why does pg_test_fsync.c include postgres.h? Shouldn't it use postgres_fe.h?
> I had tried that, actually, but it fails because the other include files
> test_fsync needs are backend-specific. We may have to refactor those
> include files so that the stuff te
On 01/22/2011 01:38 PM, Tom Lane wrote:
Buildfarm members bobcat (Fedora 14 x86) and frogmouth (mingw) have
been showing an assertion failure in the plpython regression tests
since this patch went in:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=740e54c
I have been able to
Buildfarm members bobcat (Fedora 14 x86) and frogmouth (mingw) have
been showing an assertion failure in the plpython regression tests
since this patch went in:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=740e54c
I have been able to reproduce the problem locally on Fedora 14 x
Magnus Hagander writes:
> I still get:
> pg_test_fsync.c
> 1>.\contrib\pg_test_fsync\pg_test_fsync.c(398) : warning C4101: 'ops'
> : unreferenced local variable
> 1>.\contrib\pg_test_fsync\pg_test_fsync.c(398) : warning C4101:
> 'writes' : unreferenced local variable
> 1>.\contrib\pg_test_fsync\pg
On Sat, Jan 22, 2011 at 18:12, Tom Lane wrote:
> Andrew Dunstan writes:
>> This appears to have broken Solaris, Unixware and MSVC builds.
>
> BTW, the MSVC problem appears to stem from failure to include libpgport
> when linking pg_test_fsync. I imagine this requires a fix in the MSVC
> build sc
Andrew Dunstan writes:
> This appears to have broken Solaris, Unixware and MSVC builds.
BTW, the MSVC problem appears to stem from failure to include libpgport
when linking pg_test_fsync. I imagine this requires a fix in the MSVC
build scripts.
regards, tom lane
--
Sen
On Jan22, 2011, at 17:55 , Tom Lane wrote:
> Reflecting on that, I'm inclined to suggest
>
> Bitmap Heap Scan ...
> Recheck Cond: blah blah
> Rows Removed by Recheck: 42
> Filter Cond: blah blah blah
> Rows Removed by Filter: 77
>
> or
On Sat, Jan 22, 2011 at 11:55:51AM -0500, Tom Lane wrote:
> Hitoshi Harada writes:
> > 2011/1/21 Florian Pflug :
> >> "Rows Skipped: nnn", maybe?
>
> > +1. Very straightforward to me.
>
> I didn't really care for that one, because I think it *won't* be
> straightforward when there's more than on
Andrew Dunstan writes:
> Why does pg_test_fsync.c include postgres.h? Shouldn't it use postgres_fe.h?
I had tried that, actually, but it fails because the other include files
test_fsync needs are backend-specific. We may have to refactor those
include files so that the stuff test_fsync actually
Hitoshi Harada writes:
> 2011/1/21 Florian Pflug :
>> "Rows Skipped: nnn", maybe?
> +1. Very straightforward to me.
I didn't really care for that one, because I think it *won't* be
straightforward when there's more than one filter condition at a node.
Imagine
Bitmap Heap Scan ...
On 01/21/2011 12:48 PM, Bruce Momjian wrote:
Move test_fsync to /contrib.
This appears to have broken Solaris, Unixware and MSVC builds.
Here's the error on Solaris:
gmake[1]: Entering directory
`/export/home/dpage/pgbuildfarm/moa/HEAD/pgsql.4167/contrib/pg_test_fsync'
cc -Xa -m64 -xarc
On 22/01/11 11:15, Hitoshi Harada wrote:
> This is a review for
> https://commitfest.postgresql.org/action/patch_view?id=460
Thanks,
> One issue is typmod of record type.
>
> regression=# create or replace function func1(t text) returns record
> as $$ return {'name': t, 'value': 0} $$ language
On Sat, Jan 22, 2011 at 1:30 AM, Jaime Casanova wrote:
> why is this better than using XLOG_BUFFER_MIN? (the same for the 8
> buffers assigned just above of it)
>
> + else if (XLOGbuffers < 4)
> + XLOGbuffers = 4;
Oh, good point. Woops.
> also this
> + Assert(XLOGbuffe
On Fri, 2011-01-21 at 13:32 -0500, Robert Haas wrote:
> One idea might be to wait both before and after commit. If
> allow_standalone_primary is off, and a commit is attempted, we check
> whether there's a slave connected, and if not, wait for one to
> connect. Then, we write and sync the commit
Hello,
because I am not sure so any complex solution can be done to deadline
for 9.1, I created a patch that is based on Tom ideas - just
explicitly detoast function parameters.
Regards
Pavel
2011/1/19 Robert Haas :
> On Wed, Jan 19, 2011 at 4:18 PM, Tom Lane wrote:
>> One idea that I think we
This is a review for https://commitfest.postgresql.org/action/patch_view?id=460
== Submission ==
The patch applies and compiles with success, on the top of the general
refactor patch. It is possible it cannot in HEAD now that the part of
the refactor patch applied in the core. I'll check it after
#x27;--with-python'
'--with-tcl' '--with-krb5' '--with-openssl' '--enable-thread-safety'
'--with-ldap' '--prefix=/media/sda5/postgresql-9.1devel/20110122' >
configure-out1.log 2>&1
make world > make-out1.log 2>&am
54 matches
Mail list logo
