Hi Greg,
On Tue, Nov 15, 2011 at 11:53:53PM -0500, Greg Smith wrote:
> Two years ago Magnus submitted a patch to parse all the configuration
> files in a directory. After some discussion I tried to summarize what I
> thought the most popular ideas were for moving that forward:
>
> http://arch
Hi,
A while ago when blogging about WAL [1], I noticed a function to deal with
xlog location arithmetic is wanted. I remembered Depez [2] mentioning it and
after some questions during trainings and conferences I decided to translate
my shell script function in C.
The attached patch implements the
While working on KaiGai's "leaky views" patch, I found myself
scrutinizing the behavior of the function named in the subject line;
and specifically the retest of is_simple_subquery(). I've been unable
to make that fail. For example, the following patch fails to break
the regression tests:
--- a/
On 12/05/2011 09:31 AM, NISHIYAMA Tomoaki wrote:
Hi,
If we are not to use 64 bit file size (and time),
#undef stat may be sufficient. The #undef should be
before the prototype of pgwin32_safestat because the
#define stat _stat64 affect both the function and struct stat.
The #undef stat necessi
On 5.12.2011 00:06, Tom Lane wrote:
> Tomas Vondra writes:
>> On 4.12.2011 22:16, Tom Lane wrote:
>>> Um ... why would you design it like that?
>
>> The backends are added to pg_stat_activity after the auth hook finishes,
>> which means possible race conditions (backends executed at about the
>>
Pg_upgrade has the following check to make sure the cluster is safe for
upgrading:
res = executeQueryOrDie(conn,
"SELECT n.nspname, c.relname, a.attname
"
"FROM pg_catalog.pg_class c, "
"
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > In Postgres 8.4, pg_upgrade preserved pg_class relfilenodes by creating
> > files in the file system. In Postgres 9.0, we changed this by creating
> > pg_upgrade_support functions which allow us to directly preserve
> > pg_class.oids.
> >
> > Unfor
Bruce Momjian wrote:
> In Postgres 8.4, pg_upgrade preserved pg_class relfilenodes by creating
> files in the file system. In Postgres 9.0, we changed this by creating
> pg_upgrade_support functions which allow us to directly preserve
> pg_class.oids.
>
> Unfortunately, check.c was not updated t
Hi,
Please find an update attached, v4, fixing most remaining items. Next
steps are better docs and more commands support (along with finishing
currently supported ones), and a review locking behavior.
If you want to just scroll over the patch to get an impression of what's
in there rather than t
On Mon, Dec 5, 2011 at 3:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Dec 5, 2011 at 2:47 PM, Tom Lane wrote:
>>> Peter Eisentraut writes:
To clarify, I believe the rule is that the first variable-length field
can be accessed as a struct field. Are there any exceptions to
Where are we with adding JSON for Postgres 9.2? We got bogged down in
the data representation last time we discussed this.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent
Robert Haas writes:
> On Mon, Dec 5, 2011 at 2:47 PM, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> To clarify, I believe the rule is that the first variable-length field
>>> can be accessed as a struct field. Are there any exceptions to this?
>> If it is known not null, yes, but I wonder ju
On sön, 2011-11-27 at 19:12 -0500, Andrew Dunstan wrote:
> Contrib tests are only run by the buildfarm in installcheck mode, so
> that will probably turn the tests off for the buildfarm, so +1 on that
Does the new buildfarm modular thing support that some members could run
the checks through exp
On Mon, Dec 5, 2011 at 2:47 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> To clarify, I believe the rule is that the first variable-length field
>> can be accessed as a struct field. Are there any exceptions to this?
>
> If it is known not null, yes, but I wonder just how many places actuall
Peter Eisentraut writes:
> To clarify, I believe the rule is that the first variable-length field
> can be accessed as a struct field. Are there any exceptions to this?
If it is known not null, yes, but I wonder just how many places actually
depend on that. It might be better to remove all varl
On sön, 2011-11-27 at 18:17 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > I've committed it now, and some buildfarm members are failing with lack
> > of shared memory, semaphores, or disk space. Don't know what to do with
> > that or why so many are failing like that. We could create a w
On 05.12.2011 21:36, Tom Lane wrote:
Heikki Linnakangas writes:
Or pass a flag to ExecInitExpr() to skip through the CacheExprs.
Not sure what you mean by that --- are you imagining that the ExprState
tree would have structure not matching the Expr tree?
Yes. Or it could just set a flag in
Heikki Linnakangas writes:
> On 05.12.2011 20:53, Marti Raudsepp wrote:
>> I considered stripping CacheExpr nodes later in PL/pgSQL, but I can't
>> remember right now why I rejected that approach (sorry, it's been 2
>> months).
> Yet another idea would be to leave the CacheExprs there, but provid
Pavel Stehule writes:
> 2011/12/4 Tom Lane :
>> Is this x86? I can't reproduce it on x86_64.
> yes, this is x86 platform
> uname -a
> Linux nemesis 2.6.35.14-106.fc14.i686.PAE #1 SMP Wed Nov 23 13:39:51
> UTC 2011 i686 i686 i386 GNU/Linux
I reproduced this with gcc 4.6.0 on Fedora 15 x86, too.
On sön, 2011-11-27 at 18:20 -0500, Tom Lane wrote:
> The low-tech way would be
>
> CATALOG(pg_attribute,1249) BKI_BOOTSTRAP ...
> {
> ...
> int4attinhcount;
> Oid attcollation;
> aclitem attacl[1];
> #ifdef CATALOG_VARLEN_FIELDS
> textattoptions[1];
Heikki Linnakangas writes:
> I wonder if it would be better to add the CacheExpr nodes to the tree as
> a separate pass, instead of shoehorning it into eval_const_expressions?
> I think would be more readable that way, even though a separate pass
> would be more expensive.
A separate pass woul
On 05.12.2011 20:53, Marti Raudsepp wrote:
I considered stripping CacheExpr nodes later in PL/pgSQL, but I can't
remember right now why I rejected that approach (sorry, it's been 2
months).
Yet another idea would be to leave the CacheExprs there, but provide a
way to reset the caches. PL/pgSQL
On Mon, Dec 5, 2011 at 19:31, Tom Lane wrote:
> I think if you have some call sites inject CacheExprs and others not,
> it will get more difficult to match up expressions that should be
> considered equal. On the whole this seems like a bad idea. What is
> the reason for having such a control bo
2011/12/5 Merlin Moncure :
> On Mon, Dec 5, 2011 at 12:17 PM, Pavel Stehule
> wrote:
>> Hello
>>
>> 2011/12/4 Tom Lane :
>>> Pavel Stehule writes:
it looks like gcc bug - gcc 4.5.1 20100924 (Red Hat 4.5.1) It was
configured just with --enable-debug and --enable-cassert
>>>
>>> Is this
On Mon, Dec 5, 2011 at 12:17 PM, Pavel Stehule wrote:
> Hello
>
> 2011/12/4 Tom Lane :
>> Pavel Stehule writes:
>>> it looks like gcc bug - gcc 4.5.1 20100924 (Red Hat 4.5.1) It was
>>> configured just with --enable-debug and --enable-cassert
>>
>> Is this x86? I can't reproduce it on x86_64.
>>
On 05/12/11 19:12, Bruce Momjian wrote:
> Jan Urbański wrote:
>> On 05/12/11 18:58, Peter Eisentraut wrote:
>>> On ons, 2011-11-23 at 19:58 +0100, Jan Urba?ski wrote:
On 20/11/11 19:14, Steve Singer wrote:
Responding now to all questions and attaching a revised patch based on
your c
Jan Urba??ski wrote:
> On 05/12/11 18:58, Peter Eisentraut wrote:
> > On ons, 2011-11-23 at 19:58 +0100, Jan Urba?ski wrote:
> >> On 20/11/11 19:14, Steve Singer wrote:
> >> Responding now to all questions and attaching a revised patch based on
> >> your comments.
> >
> > Committed
> >
> > Pleas
Excerpts from Peter Eisentraut's message of lun dic 05 14:27:41 -0300 2011:
> The cases in libpq are
>
> * various places in fe-print.c calling exit(1) when malloc fails,
> presumably having run out of memory, and
> * in libpq-int.h the macro PGTHREAD_ERROR, which is called i
On 05/12/11 18:58, Peter Eisentraut wrote:
> On ons, 2011-11-23 at 19:58 +0100, Jan Urbański wrote:
>> On 20/11/11 19:14, Steve Singer wrote:
>> Responding now to all questions and attaching a revised patch based on
>> your comments.
>
> Committed
>
> Please refresh the other patch.
Great, than
On ons, 2011-11-23 at 19:58 +0100, Jan Urbański wrote:
> On 20/11/11 19:14, Steve Singer wrote:
> > On 11-10-15 07:28 PM, Jan Urbański wrote:
> >> Hi,
> >>
> >> attached is a patch implementing the usage of SPI cursors in PL/Python.
> >> Currently when trying to process a large table in PL/Python y
Peter Geoghegan writes:
> Why the strong aversion to what I've done? I accept that it's ugly,
> but is it really worth worrying about that sort of regression in
> maintainability for something that was basically untouched since 2006,
> and will probably remain untouched after this work concludes,
Marti Raudsepp writes:
> On Sun, Dec 4, 2011 at 22:53, Heikki Linnakangas
> wrote:
>> This comment in RelationGetExpressions() also worries me:
> [...]
>> Do the injected CacheExprs screw up that equality? Or the constraint
>> exclusion logic in predtest.c?
> I suspect these cases are guaranteed
Debian's package policy and quality check tool lintian reports the
following (among other things) on the postgresql-9.1 (and earlier)
packages:
X: libpq5: shlib-calls-exit usr/lib/libpq.so.5.4
X: libecpg6: shlib-calls-exit usr/lib/libecpg.so.6.3
which is explained as
I: shlib-calls-exit
N:
N:
On Sun, Dec 4, 2011 at 22:53, Heikki Linnakangas
wrote:
> This seems to have bitrotted, thanks to the recent refactoring in
> eval_const_expressions().
Luckily the conflicts are mostly whitespace changes, so shouldn't be
hard to fix. I'll try to come up with an updated patch today or
tomorrow.
>
On 5 December 2011 13:23, Heikki Linnakangas
wrote:
> I'm still not convinced the big gain is in inlining the comparison
> functions. Your patch contains a few orthogonal tricks, too:
>
> * A fastpath for the case of just one scankey. No reason we can't do that
> without inlining.
True, though To
"Kevin Grittner" wrote:
> Yeb Havinga wrote:
>> I personally tend to believe it doesn't even need to be an error.
>> There is no technical reason not to allow it. All the user needs
>> to do is make sure that the combination of named parameters and
>> the positional ones together are complete a
On Mon, Dec 5, 2011 at 10:46 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'm still puzzled that Tomas got it working at all. If MyDatabaseId
>> hasn't been set yet, the how did we manage to build a relcache entry
>> for anything - let alone an unshared catalog?
>
> Well, he wasn't actually issu
Robert Haas writes:
> I don't think so. There's no ALTER RULE command; should we add one
> (matching ALTER TRIGGER) or make this part of ALTER TABLE? I don't
> think constraints can be renamed either, which should probably be
> addressed along with rules.
Note that renaming an index-based const
Robert Haas writes:
> I'm still puzzled that Tomas got it working at all. If MyDatabaseId
> hasn't been set yet, the how did we manage to build a relcache entry
> for anything - let alone an unshared catalog?
Well, he wasn't actually issuing a SQL query, just calling some of the
pgstat.c subrout
On Sat, Dec 3, 2011 at 4:46 PM, Peter Eisentraut wrote:
> I noticed the following object types don't have support for an ALTER ...
> RENAME command:
>
> DOMAIN (but ALTER TYPE works)
> FOREIGN DATA WRAPPER
> OPERATOR
> RULE
> SERVER
>
> Are there any restrictions why these couldn't be added?
I do
On Sun, Dec 4, 2011 at 4:26 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> What about the pg_stat_activity - is it safe to access that from auth
>> hook or is that just a coincidence that it works (and might stop working
>> in the future)?
>
> It doesn't seem like a good thing to rely on. There's
Yeb Havinga wrote:
> On 2011-12-03 21:53, Kevin Grittner wrote:
>> (1) Doc changes:
>>
>>(a) These contain some unnecessary whitespace changes which
>>make it harder to see exactly what changed.
>
> This is probably caused because I used emacs's fill-paragraph
> (alt+q) command, a
Merlin Moncure writes:
> On Sun, Dec 4, 2011 at 4:55 PM, Tom Lane wrote:
>> Pavel Stehule writes:
> it looks like gcc bug - gcc 4.5.1 20100924 (Red Hat 4.5.1) It was
> configured just with --enable-debug and --enable-cassert
>>
>> Is this x86? I can't reproduce it on x86_64.
> reading all the
On Sat, Dec 03, 2011 at 01:26:22AM +0100, Andres Freund wrote:
> On Saturday, December 03, 2011 01:09:48 AM Alvaro Herrera wrote:
> > Excerpts from Andres Freund's message of vie dic 02 19:09:47 -0300 2011:
> > > Hi all,
> > >
> > > There is also the point about how permission checks on the actual
Hi,
If we are not to use 64 bit file size (and time),
#undef stat may be sufficient. The #undef should be
before the prototype of pgwin32_safestat because the
#define stat _stat64 affect both the function and struct stat.
The #undef stat necessitate #undef fstat as the parameter
struct stat * is c
On Sun, Dec 4, 2011 at 4:55 PM, Tom Lane wrote:
> Pavel Stehule writes:
>> it looks like gcc bug - gcc 4.5.1 20100924 (Red Hat 4.5.1) It was
>> configured just with --enable-debug and --enable-cassert
>
> Is this x86? I can't reproduce it on x86_64.
reading all the comments in the gcc bug repor
On 05.12.2011 02:14, Peter Geoghegan wrote:
On 4 December 2011 19:17, Tom Lane wrote:
I have not done any performance testing on this patch, but it might be
interesting to check it with the same test cases Peter's been using.
I've attached a revision of exactly the same benchmark run to get t
Kevin,
Thank you for your review!
On 2011-12-03 21:53, Kevin Grittner wrote:
(1) Doc changes:
(a) These contain some unnecessary whitespace changes which make it
harder to see exactly what changed.
This is probably caused because I used emacs's fill-paragraph (alt+q)
command, af
On Tue, Nov 29, 2011 at 12:02 PM, Alexander Shulgin
wrote:
>
> Excerpts from Alexander Shulgin's message of Sat Nov 26 22:07:21 +0200 2011:
>>
>> So how about this:
>>
>> postgresql:ssl://user:pw@host:port/dbname?sslmode=...
>>
>> The "postgresql:ssl://" designator would assume "sslmode=require"
Thinking about this some more, why don't we just elog(FATAL) in
internal_flush(), if the write fails, instead of setting the flag and
waiting for the next CHECK_FOR_INTERRUPTS(). That sounds scary at first,
but why not?
There's this comment in internal_flush():
/*
50 matches
Mail list logo