On Tue, Dec 15, 2009 at 5:30 AM, Greg Smith wrote:
> When I look at http://www.pgadmin.org/support/ for example it suggests the
> right list. I only see this one listed in the Translation section, as the
> place to ask to get added to the translators list. Does anyone know where
> the tips sect
Le mardi 15 décembre 2009 à 06:30:15, Greg Smith a écrit :
> [...]
> > BTW, this list is listed as the list for tech questions in the pgAdmin
> > tips, therefore if you don't want to be disturb, you might want to
> > remove it from the pgAdmin tips.
>
> When I look at http://www.pgadmin.org/suppor
Looks like Andrew Dunstan didn't want to go public...
Fred
-- Forwarded message --
From: Fred Janon
Date: Tue, Dec 15, 2009 at 10:03
Subject: Re: [HACKERS] pgAdmin III: timestamp displayed in what time zone?
To: Andrew Dunstan
Thanks for being so polite. At least Greg Smith su
Hot Standby node can freeze when startup process calls LockBufferForCleanup().
This bug can be reproduced by the following procedure.
0. start Hot Standby, with one active node(node A) and one standby node(node B)
1. create table X and table Y in node A
2. insert several rows in table X in node A
Hot Standby node can freeze when startup process calls LockBufferForCleanup().
This bug can be reproduced by the following procedure.
0. start Hot Standby, with one active node(node A) and one standby node(node B)
1. create table X and table Y in node A
2. insert several rows in table X in node A
On 12/15/09, Kurt Harriman wrote:
> Attached is a revised patch, offered for the 2010-01 commitfest.
> It's also available in my git repository in the "submitted" branch:
>
> http://git.postgresql.org/gitweb?p=users/harriman/share.git;a=shortlog;h=refs/heads/submitted
>
> In this version, the "
* Robert Haas (robertmh...@gmail.com) wrote:
> I think there was a previous discussion of this when Heikki first
> posted the issue to -hackers.
There was, it's now linked off the http://wiki.postgresql.org/wiki/RLS
page (as well as this thread). Feel free to add other threads, update
with your t
On Tue, Dec 15, 2009 at 7:28 AM, wrote:
> The situation is even more restricted with floats (they are much
> smaller; thus one could say that they're more "discrete" than strings,
> even). Problem with floats is -- the granule is not the "same size" over
> the whole range (nasty), and it's all im
Hi,
here's another patch that aims to fix auto-prepare.
The reason is, that in the project porting from Informix,
a small test case that used a cursor and two small SELECTs
issued for every record retrieved by the cursor showed that
for this case, the ESQL compiled binary finished about 60%
faste
*ahem*
You double-post a query *knowing* you shouldn't (otherwise why the
"sorry"?), compounding the error by not picking the right list at all. I
chide you for it privately, not to hide my actions but to keep
irrelevant traffic on the list down, and you then decide it's proper to
post my pr
Hi
HEAD fails to compile in 64-bit mode on Mac OS X 10.6 with gcc 4.2 and
-Werror.
What happens is that INT64_FORMAT gets defined as "%ld" (which is
correct - "long" and "unsigned long" are 64 bits wide on x86_64), but
the check for a working 64-bit int fails, causing INT64_IS_BUSTED to get
defi
Takahiro Itagaki wrote:
> Here is an updated patch rebased to the latest CVS HEAD.
>
> One remaining concern is VERBOSE. Log messages by FULL (rewrite) are less
> verbose than FULL INPLACE. The same can be said for CLUSTER VERBOSE, though.
> I don't have any plans to make CLUSTER more verbose in t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Dec 15, 2009 at 01:09:02PM +, Greg Stark wrote:
[...]
> In fact, as I only recently found out, one of the design goals of IEEE
> floats was specifically that they sort lexicographically and use every
> bit pattern. So you can alwys get th
to...@tuxteam.de writes:
> (and as Andrew Dunstan pointed out off-list: I was wrong with my bold
> assertion that one can squeeze infinitely many (arbitrary length)
> strings between two given. This is not always the case).
Really? If the string length is unbounded I think you were right.
Greg Stark writes:
> In fact, as I only recently found out, one of the design goals of IEEE
> floats was specifically that they sort lexicographically and use every
> bit pattern. So you can alwys get the "next" float by just
> incrementing your float as an 64-bit integer. Yes that raises your
> v
"Florian G. Pflug" writes:
> configure fails to recognize "long" as a working 64-bit type because the
> does_int64_work configure test produces warning due to a missing return
> value declaration for main() and a missing prototype for
> does_int64_work(). (Aain, those warning are turned into error
On Mon, Dec 14, 2009 at 10:21 PM, Stephen Frost wrote:
> Bruce,
>
> * Bruce Momjian (br...@momjian.us) wrote:
>> You are fine. I was just saying that at a time I was one of the few
>> loud voices on this, and if this is going to happen, it will be because
>> we have a team that wants to do this,
On Tue, Dec 15, 2009 at 9:58 AM, Tom Lane wrote:
> Greg Stark writes:
>> In fact, as I only recently found out, one of the design goals of IEEE
>> floats was specifically that they sort lexicographically and use every
>> bit pattern. So you can alwys get the "next" float by just
>> incrementing y
On 15.12.09 16:02 , Tom Lane wrote:
"Florian G. Pflug" writes:
configure fails to recognize "long" as a working 64-bit type
because the does_int64_work configure test produces warning due to
a missing return value declaration for main() and a missing
prototype for does_int64_work(). (Aain, tho
2009/12/15 Tom Lane :
> to...@tuxteam.de writes:
>
>> (and as Andrew Dunstan pointed out off-list: I was wrong with my bold
>> assertion that one can squeeze infinitely many (arbitrary length)
>> strings between two given. This is not always the case).
>
> Really? If the string length is unbounde
Robert Haas writes:
> I also have to say that I'm very skeptical of the argument
> that there is only a small list of types people will want this for.
I'm not sure that anyone has argued that. I did suggest that there
might be a small list of types for which we should provide discrete
behavior (
On 12/15/09, Florian G. Pflug wrote:
> On 15.12.09 16:02 , Tom Lane wrote:
>
> > "Florian G. Pflug" writes:
> >
> > > configure fails to recognize "long" as a working 64-bit type
> > > because the does_int64_work configure test produces warning due to
> > > a missing return value declaration for
On Tue, Dec 15, 2009 at 10:19 AM, Tom Lane wrote:
> Robert Haas writes:
>> I also have to say that I'm very skeptical of the argument
>> that there is only a small list of types people will want this for.
>
> I'm not sure that anyone has argued that. I did suggest that there
> might be a small l
Nicolas Barbier writes:
> Assuming lexicographical ordering (first different character
> determines order; end-of-string is sorted before anything else),
> consider the following two strings:
>
> and
> + the character with the lowest value in
> lexicographical ordering.
> I don't think it is po
On 15.12.09 15:52 , Tom Lane wrote:
to...@tuxteam.de writes:
(and as Andrew Dunstan pointed out off-list: I was wrong with my
bold assertion that one can squeeze infinitely many (arbitrary
length) strings between two given. This is not always the case).
Really? If the string length is unbound
On Tue, Dec 15, 2009 at 02:19:19PM +0100, Boszormenyi Zoltan wrote:
> here's another patch that aims to fix auto-prepare.
> ...
> --- pgsql.6/src/interfaces/ecpg/preproc/output.c 2009-12-15
> 13:12:37.0 +0100
> *** hashline_number(void)
> *** 106,112
> }
>
> vo
Tom Lane wrote:
So the long and the short of it is that next/previous are not
going to work for string types, maxlength or no maxlength.
Even more importantly, I strongly doubt they would be of the slightest
practical value.
cheers
andrew
--
Sent via pgsql-ha
Michael Meskes írta:
> On Tue, Dec 15, 2009 at 02:19:19PM +0100, Boszormenyi Zoltan wrote:
>> here's another patch that aims to fix auto-prepare.
>> ...
>> --- pgsql.6/src/interfaces/ecpg/preproc/output.c 2009-12-15
>> 13:12:37.0 +0100
>> *** hashline_number(void)
>> *** 10
Zdenek Kotala wrote:
Bernd Helmle píše v po 14. 12. 2009 v 20:42 +0100:
Oh, and i was under the opinion the last discussions were about executor
probes only (note the patch is split up into two parts now, SLRU and
executor probes). The latter won't be fixed, but it seems the SLRU part at
le
We're down to five patches that are ready for a committer still on the
table:
-New VACUUM FULL
-tsearch parser inefficiency with urls or emails
-ProcessUtility_hook
-Aggregate ORDER BY support
-Hot Standby
I just bounced "Streaming Replication" forward to the next CF, and
specifically noted th
On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
> I'm not sure that anyone has argued that. I did suggest that there
> might be a small list of types for which we should provide discrete
> behavior (ie, with next/previous functions) and the rest could have
> continuous behavior (without that as
On 12/15/09 1:05 AM, Takahiro Itagaki wrote:
> Here is an updated patch rebased to the latest CVS HEAD.
>
> One remaining concern is VERBOSE. Log messages by FULL (rewrite) are less
> verbose than FULL INPLACE. The same can be said for CLUSTER VERBOSE, though.
> I don't have any plans to make CLUS
Andrew Gierth writes:
> Updated version of the aggregate order by patch.
Applied with some editorialization. The main change I made was to get
rid of all the ad-hoc DISTINCT handling in parse_agg.c and use
transformDistinctClause() instead. This exposed what I believe to
be a bug in the submitt
On Tue, Dec 15, 2009 at 12:27 PM, Greg Smith wrote:
> -New VACUUM FULL
I get the impression there is still some discussion that needs to
happen about the design of this. I think we should mark it Returned
with Feedback for now, and let whoever ends up working on it resubmit
whatever ends up gett
running with log_checkpoints = on
pg_ctl -D foo -m fast stop
log says
LOG: received fast shutdown request
LOG: aborting any active transactions
LOG: shutting down
LOG: restartpoint starting: shutdown immediate
Some of us know that the "immediate" word refers to the restartpoint
request, tho
On Tue, Dec 15, 2009 at 12:19 PM, Simon Riggs wrote:
> running with log_checkpoints = on
>
> pg_ctl -D foo -m fast stop
>
> log says
>
> LOG: received fast shutdown request
> LOG: aborting any active transactions
> LOG: shutting down
> LOG: restartpoint starting: shutdown immediate
>
> Some of
Jeff Davis writes:
> If I'm correct, continuous ranges always need two extra bits of storage
> for the exclusivity. But for timestamps, that means 16 bytes (2 x 8-byte
> timestamp) turns into 17 bytes, which is really more like 20 or 24 bytes
> with alignment.
You probably need some flag bits any
Greg Smith writes:
> We're down to five patches that are ready for a committer still on the
> table:
> -New VACUUM FULL
> -tsearch parser inefficiency with urls or emails
> -ProcessUtility_hook
> -Aggregate ORDER BY support
> -Hot Standby
Aggregate ORDER BY is in. I will pick up the ProcessUti
I get this when testing prepared transactions, which looks like it is
unrelated to Hot Standby.
2009-12-15 17:28:08 GMT[10385]LOG: archive recovery complete
2009-12-15 17:28:08 GMT[10428]LOG: checkpoint starting: end-of-recovery
immediate wait
2009-12-15 17:28:08 GMT[10428]DEBUG: creating and
Just to make those who care aware of it, here is Michael Cahill's
Doctoral Thesis based on implementing Serializable Snapshot
Isolation in InnoDB using a refined version of the techniques
previously used in the Berkley DB (and previously discussed on this
list):
http://hdl.handle.net/2123/5353
Jeff Davis wrote:
On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
I'm not sure that anyone has argued that. I did suggest that there
might be a small list of types for which we should provide discrete
behavior (ie, with next/previous functions) and the rest could have
continuous behavior (wi
Robert Haas wrote:
On Tue, Dec 15, 2009 at 12:27 PM, Greg Smith wrote:
-New VACUUM FULL
I get the impression there is still some discussion that needs to
happen about the design of this. I think we should mark it Returned
with Feedback for now, and let whoever ends up working on it r
On Tuesday 15 December 2009 20:44:36 Greg Smith wrote:
> As for the tsearch improvements, not to trivialize the patch, but I
> think this one will survive being committed between alpha3 & CF 2010-01
> if it doesn't make it in this week. Teodor can work on getting that
> committed when he has time,
On Tue, Dec 15, 2009 at 11:31:05AM -0800, Scott Bailey wrote:
> Jeff Davis wrote:
> >On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
>
> Would it be OK if we handled float timestamp ranges as continuous
> and int64 timestamps discrete?
That sounds like a recipe for disaster. Whatever timestam
I applied this patch after a little bit of editorialization concerning
the points mentioned in this discussion:
Robert Haas writes:
> On Wed, Dec 9, 2009 at 9:33 PM, Takahiro Itagaki
> wrote:
>> Robert Haas wrote:
>>> Why does this patch #ifdef out the _PG_fini code in pg_stat_statements?
>>
>
On tis, 2009-12-15 at 16:15 +0100, Florian G. Pflug wrote:
> Alternatively - is there a way to use -Werror only for building the
> actual sources, not the configure tests? I didn't find one, but my
> autoconf-fu is pretty limited...
I always build with
pgmake='make COPT="-Werror -Wno-inline"'
(T
Greg Smith writes:
> We're down to five patches that are ready for a committer still on the
> table:
> -tsearch parser inefficiency with urls or emails
I just looked at this one and concluded that it was pretty harmless;
will commit it.
regards, tom lane
--
Sent via p
> "Tom" == Tom Lane writes:
Tom> Andrew Gierth writes:
>> Updated version of the aggregate order by patch.
Tom> Applied with some editorialization. The main change I made was
Tom> to get rid of all the ad-hoc DISTINCT handling in parse_agg.c
Tom> and use transformDistinctClause() inst
"Kevin Grittner" writes:
> Andres Freund wrote:
>> [concerns addressed in new patch version]
> Looks good to me. I'm marking this Ready for Committer.
Applied with minor editorialization --- improving the comments mostly.
regards, tom lane
--
Sent via pgsql-hackers
Andrew Gierth writes:
> Query-level DISTINCT shouldn't allow columns in the order by that
> aren't in the select list because those columns _do not exist_ at the
> point that ordering logically takes place (even though in the
> implementation, they might).
> This isn't the case for aggregate orde
> "Tom" == Tom Lane writes:
>> Query-level DISTINCT shouldn't allow columns in the order by that
>> aren't in the select list because those columns _do not exist_ at
>> the point that ordering logically takes place (even though in the
>> implementation, they might).
>> This isn't the ca
Andrew Gierth writes:
> Notice that there are cases where agg(distinct x order by x) is
> nondeterministic while agg(distinct x order by x,y) is deterministic.
Well, I think what you're really describing is a case where you're using
the wrong sort opclass. If the aggregate can distinguish two va
On 12/15/2009 4:05 AM, Marko Kreen wrote:
On 12/15/09, Kurt Harriman wrote:
Attached is a revised patch, offered for the 2010-01 commitfest.
It's also available in my git repository in the "submitted" branch:
http://git.postgresql.org/gitweb?p=users/harriman/share.git;a=shortlog;h=refs/hea
David Fetter writes:
> On Tue, Dec 15, 2009 at 11:31:05AM -0800, Scott Bailey wrote:
>> As for the extra bits, would it be better to just require continuous
>> ranges to be either [] or [)? But I don't know which would be
>> preferred. My inclination would be toward [), but Tom seemed to
>> indica
Peter Eisentraut writes:
> I have also tried in the past to pass -Werror through configure, but
> that caused too many problems.
Is it your opinion that we shouldn't bother fixing this particular
test? I was on the fence about it myself. I don't want to promise
that configuring with -Werror wil
On Tue, 2009-12-15 at 13:15 -0500, Tom Lane wrote:
> You probably need some flag bits anyway, so flailing frantically to
> avoid that doesn't seem like a profitable use of time.
I think "need" and "flailing" are both a little too strong here. The
biggest use case will almost certainly be ranges of
Hello
I am looking on new feature - ORDER clause in aggregate, and I thing,
so we are able to effectively implement some non standard, but well
known aggregates.
a) function median - it is relative frequent request - with usually
slow implementation
b) function listagg (it is analogy of group_co
On 12/15/09, Kurt Harriman wrote:
> On 12/15/2009 4:05 AM, Marko Kreen wrote:
> > Unless it is some popular compiler (as "in actual use") it is
> > premature complexity. Please remove that.
>
> Microsoft's compilers are in actual use, and some might even
> say they are popular. For example,
On 12/15/09, Tom Lane wrote:
> Peter Eisentraut writes:
> > I have also tried in the past to pass -Werror through configure, but
> > that caused too many problems.
>
> Is it your opinion that we shouldn't bother fixing this particular
> test? I was on the fence about it myself. I don't want
On Tue, 2009-12-15 at 18:49 +, Simon Riggs wrote:
> This looks like the code is setting the parent to be zero.
[Sorry, that comment is completely off, misread the line number.]
The assertion is failing because the parent entry for that subxid had
already been set.
Investigating how that coul
On 12/15/2009 1:31 PM, Marko Kreen wrote:
Do you have actual proof that MSVC launches warnings on unused
"static inline" functions? Not "static", but "static inline".
Yes, I tried it, and that's why I did it this way.
If yes, indeed we need to fix it. MSVC is broken then, but it does
not ma
Jeff Davis writes:
> I think "need" and "flailing" are both a little too strong here. The
> biggest use case will almost certainly be ranges of timestamps, and most
> of those people will have no use for flag bits (or if they do, it might
> not be worth an 8-byte-per-value overhead).
When the alt
David Fetter wrote:
On Tue, Dec 15, 2009 at 11:31:05AM -0800, Scott Bailey wrote:
Jeff Davis wrote:
On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
Would it be OK if we handled float timestamp ranges as continuous
and int64 timestamps discrete?
That sounds like a recipe for disaster. Wha
On Tue, 2009-12-15 at 11:49 -0800, David Fetter wrote:
> That sounds like a recipe for disaster. Whatever timestamp ranges
> are, float and int64 should be treated the same way so as not to get
> "surprises" due to implementation details.
It's a compile-time option that will change the semantics
On 12/15/09, Kurt Harriman wrote:
> On 12/15/2009 1:31 PM, Marko Kreen wrote:
>
> > Do you have actual proof that MSVC launches warnings on unused
> > "static inline" functions? Not "static", but "static inline".
>
> Yes, I tried it, and that's why I did it this way.
Oh. Ok then. Force-inline
--On 15. Dezember 2009 12:10:09 -0500 Greg Smith
wrote:
But I'm afraid we're already out of time for this one if you're still
tweaking the probes here. With a functional change like that, our
normal process at this point would be to have the reviewer re-evaluate
things before they head to
Jeff Davis writes:
> On Tue, 2009-12-15 at 11:49 -0800, David Fetter wrote:
>> FWIW, I think it would be a good idea to treat timestamps as
>> continuous in all cases.
> I disagree. There is a lot of value in treating timestamp ranges as
> discrete.
> One big reason is that the ranges can be tra
On Tue, Dec 15, 2009 at 10:28:49PM +0100, Pavel Stehule wrote:
> Hello
>
> I am looking on new feature - ORDER clause in aggregate, and I thing,
> so we are able to effectively implement some non standard, but well
> known aggregates.
>
> a) function median - it is relative frequent request - wit
On tis, 2009-12-15 at 16:22 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > I have also tried in the past to pass -Werror through configure, but
> > that caused too many problems.
>
> Is it your opinion that we shouldn't bother fixing this particular
> test? I was on the fence about it mys
Scott Bailey writes:
> Ok, let me give an example of what we can do with the current
> implementations that would not be possible with timestamps if we
> implement as suggested. ...
> The function below takes two period arrays that can have overlapping and
> adjacent elements. It subtracts all
Peter Eisentraut writes:
> So to summarize, this is just a bad idea. Creating a less obscure way
> to use -Werror might be worthwhile, though.
I suppose we could add "--with-Werror" but it seems pretty specialized
to me. A more appropriate solution would allow the user to provide
flags that get
Tom Lane wrote:
Jeff Davis writes:
On Tue, 2009-12-15 at 11:49 -0800, David Fetter wrote:
FWIW, I think it would be a good idea to treat timestamps as
continuous in all cases.
I disagree. There is a lot of value in treating timestamp ranges as
discrete.
One big reason is that the ranges
> If this were an amazingly
short and beautiful piece of code, it might support your argument,
but it's neither.
Well we can't all be arrogant brainiacs.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
On Dec 11, 2009, at 8:44 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Ashish wrote:
>>> I am thinking about starting with the following TODO item:
>>> --> Have EXPLAIN ANALYZE issue NOTICE messages when the estimated
>>> and actual row counts differ by a specified percentage.
>
>> I even have a
I wrote:
> The proposed problem is certainly soluble without any assumptions
> of discreteness.
To be concrete, I think it could be approached like this:
Assume the datatype provides a built-in function
period_except(p1 period, p2 period) returns setof period
which can return zero, one,
On Tue, 2009-12-15 at 17:17 -0500, Tom Lane wrote:
> Actually, that is exactly one of the reasons why what you propose is
> a *bad* idea. You want to institutionalize application dependence on
> a non-portable implementation detail, namely the granularity of machine
> representation of what's in p
On 12/15/09 2:40 PM, Scott Bailey wrote:
>> If this were an amazingly
>> short and beautiful piece of code, it might support your argument,
>> but it's neither.
>
> Well we can't all be arrogant brainiacs.
Tom, Scott,
Let's keep it constructive here. Thanks!
--Josh
--
Sent via pgsql-hackers
On Dec 15, 2009, at 5:40 PM, Jeff Davis wrote:
> If you think I'm proposing that we drop inclusivity/exclusivity before
> telling the application, that's not what I'm proposing at all. I'm
> proposing that, at least in some circumstances, it's important to be
> able to display the same value in dif
On Dec 15, 2009, at 11:34 AM, Jeff Davis wrote:
> On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote:
>> I'm not sure that anyone has argued that. I did suggest that there
>> might be a small list of types for which we should provide discrete
>> behavior (ie, with next/previous functions) and the r
On Dec 15, 2009, at 3:40 PM, Jeff Davis wrote:
Based on the premise that timestamps are a continuous value and the
granularity/precision is entirely an implementation detail, you're
right. But I disagree with the premise, at least in some cases that I
think are worthwhile.
The argument is, in
Alvaro Herrera wrote:
> Hmm. With this patch, if I do "vacuumdb -f" it will not vacuum the
> special system catalogs that can only be vacuumed with INPLACE, correct?
No. It will vacuum normal tables with FULL (rewrite), and system catalogs
with FULL INPLACE. FULL vacuums for system catalogs al
Tom Lane wrote:
I wrote:
The proposed problem is certainly soluble without any assumptions
of discreteness.
To be concrete, I think it could be approached like this:
Assume the datatype provides a built-in function
period_except(p1 period, p2 period) returns setof period
which can r
On Tue, 2009-12-15 at 18:06 -0600, decibel wrote:
> Now that varlena's don't have an enormous fixed overhead, perhaps it's
> worth looking at using them. Obviously some operations would be
> slower, but for your stated examples of auditing and history, I
> suspect that you're not going to notice th
On Tue, 2009-12-15 at 18:03 -0600, decibel wrote:
> I think it would help the discussion if you could provide some real
> examples. I suspect you're thinking of things like scheduling apps,
> where it's important to be able to do things like "what's the next
> available time slot?". There are proba
On Tue, 2009-12-15 at 16:08 -0800, Christophe Pettus wrote:
> The argument is, in essence:
>
> DECIMAL is continuous.
> DECIMAL(10,3) is discrete.
>
> timestamptz in general is a continuous value (unless we're talking
> Planck times :) ). There is no way for us to guarantee that
On 15.12.09 23:38 , Tom Lane wrote:
Peter Eisentraut writes:
So to summarize, this is just a bad idea. Creating a less obscure
way to use -Werror might be worthwhile, though.
I suppose we could add "--with-Werror" but it seems pretty
specialized to me. A more appropriate solution would allo
On 12/15/2009 2:09 PM, Marko Kreen wrote:
Oh. Ok then. Force-inline seems better fix as we may want to use
it for other reasons too (converting big macros).
So it seems like a good moment to solve it for gcc too.
Is ordinary inlining not sufficient?
If deluxe inlining is something that mig
(2009/12/16 0:03), Robert Haas wrote:
> But these patches are, unfortunately, not technically excellent.
> There have been multiple reviews of these patches that have produced
> extensive laundry lists of items to be fixed. In the ordinary course
> of events, that leads to one of two things happen
On Tue, Dec 15, 2009 at 3:47 AM, Heikki Linnakangas
wrote:
> Tom Lane wrote:
>> The very, very large practical problem with this is that if you decide
>> to change the behavior at any time, the only way to be sure that the WAL
>> receiver is using the right libpq version is to perform a soname maj
[Please ignore the previous incomplete version of this reply, which I
sent by mistake. Sorry for the list noise.]
On 12/15/2009 2:09 PM, Marko Kreen wrote:
>
> Oh. Ok then. Force-inline seems better fix as we may want to use
> it for other reasons too (converting big macros).
>
> So it seems l
On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harriman wrote:
>> Your worry ii) can be ignored, managing to compile on such
>> compilers is already overachievement.
>
> I think so too. With your opinion added to mine, do we constitute a
> consensus of the pg community? Someone might object that a sampl
The attached patch is a draft for the discussion.
It cleans up the existing PG privileges checks related to databases
and schemas, and consolidates points where it applies privileges
checks as a groundwork for the upcoming security framework.
We have tried a few approaches to implement SE-PgSQL f
It is a cleanup patch apart from SELinux and security framework.
Now, EnableDisableRule() checks ownership of the relation which
owns the rewrite rule to be enabled/disabled.
But it has the following call path, and this check is already done
in the ATPrepCmd().
ATExecCmd()
-> ATExecEnableDisa
The patch was not attached...
(2009/12/16 15:15), KaiGai Kohei wrote:
> It is a cleanup patch apart from SELinux and security framework.
>
> Now, EnableDisableRule() checks ownership of the relation which
> owns the rewrite rule to be enabled/disabled.
>
> But it has the following call path, and
2009/12/15 David Fetter :
> On Tue, Dec 15, 2009 at 10:28:49PM +0100, Pavel Stehule wrote:
>> Hello
>>
>> I am looking on new feature - ORDER clause in aggregate, and I thing,
>> so we are able to effectively implement some non standard, but well
>> known aggregates.
>>
>> a) function median - it i
This patch fixes a problem discussed earlier.
Now, FindConversion() which is only called from FindConversionByName()
checks ACL_EXECUTE permission on the conversion procedure matched.
If not allowed, it performs as if the given conversion does not exist
(InvalidOid shall be returned).
The FindCon
Simon Riggs wrote:
> Investigating how that could come about, it looks like there is some
> fairly strange stuff going on here. StandbyRecoverPreparedTransactions()
> is never called at all.
I told you so:
http://archives.postgresql.org/message-id/4b260b5e.3010...@enterprisedb.com
StandbyRecoverP
On 12/15/2009 9:42 PM, Robert Haas wrote:
On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harriman wrote:
Your worry ii) can be ignored, managing to compile on such
compilers is already overachievement.
I think so too. With your opinion added to mine, do we constitute a
consensus of the pg community?
98 matches
Mail list logo
