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():
/*
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"
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 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
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
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 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
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
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
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
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
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
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
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
"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 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
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.
>
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:
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
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,
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
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
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
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
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
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.
>>
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 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
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
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 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];
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.
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
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
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
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 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
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
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
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
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
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
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
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
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, "
"
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
>>
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
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/
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
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
50 matches
Mail list logo
