Jaime Casanova wrote:
On Fri, Feb 13, 2009 at 8:32 PM, KaiGai Kohei wrote:
If you can help to test the patches, I recommend you to install Fedora 10
on your VM images, because it includes SELinux in the default and its
default security policy (selinux-policy-targeted) also supports
SE-PostgreSQ
On Fri, Feb 13, 2009 at 8:32 PM, KaiGai Kohei wrote:
>>
> If you can help to test the patches, I recommend you to install Fedora 10
> on your VM images, because it includes SELinux in the default and its
> default security policy (selinux-policy-targeted) also supports
> SE-PostgreSQL.
>
i only h
So far, we have the below ideas:
1. void PQinitSSL(MAGIC_VALUES)
The idea is to use some magic values to add more options, converting the do_init
argument from a flag to an enumeration. The idea is choose magic values that
would most likely never be used by existing libpq applications. The do
Jaime Casanova wrote:
On Fri, Feb 13, 2009 at 9:07 AM, Joshua Brindle wrote:
KaiGai Kohei wrote:
KaiGai Kohei wrote:
The series of SE-PostgreSQL patches are updated:
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1530.patch
[2/5]
http://sepgsql.googlecode.com/files
> Personally, I still subscribe to the PNG design theory that
> conditionalizing code on overall version numbers isn't a very good idea.
> Version information should be tied as tightly as possible to the
> particular behavior for which it applies.
> http://www.w3.org/TR/PNG-Rationale.html#R.Chunk-n
Robert Haas writes:
>> BTW, the bitmask isn't perfect either --- doesn't it just reintroduce
>> the problem already complained of with your idea for PQinitSSL? That
>> is, how does the client know whether the function recognized all the
>> bits it passed?
> Well, if we add the PQgetLibraryVersio
On Fri, Feb 13, 2009 at 4:53 PM, Robert Haas wrote:
>> BTW, the bitmask isn't perfect either --- doesn't it just reintroduce
>> the problem already complained of with your idea for PQinitSSL? That
>> is, how does the client know whether the function recognized all the
>> bits it passed?
>
> Well,
Zdenek Kotala writes:
> I attached fix for regression tests and Czech locale. It is not complete
> yet, because I fighting with foreign_data test. But it fix three other
> tests.
As per buildfarm member gothic_moth, this didn't fix it.
> The difference is that Czech collation sorts numbers after
> BTW, the bitmask isn't perfect either --- doesn't it just reintroduce
> the problem already complained of with your idea for PQinitSSL? That
> is, how does the client know whether the function recognized all the
> bits it passed?
Well, if we add the PQgetLibraryVersion() function I suggested
up
Tom Lane wrote:
is, how does the client know whether the function recognized all the
bits it passed?
How about returning the bits it could set?
int mask = PG_INITSSL | PG_INITCRYPTO;
if (!(PQinitSecure(mask) & PG_INITCRYPTO))
; // no support for crypto
...OR...
consider a generic PQinit c
On Fri, Feb 13, 2009 at 3:27 PM, Joshua D. Drake wrote:
> On Fri, 2009-02-13 at 20:10 +, Grzegorz Jaskiewicz wrote:
>> yet more arguments, to let postgresql estimate those automatically.
>
> Well I haven't seen any arguments actually. Which was the point of my
> original question. I don't thin
"Joshua D. Drake" writes:
> Thanks for the work around, but that is ridiculous. I still say this is
> a bug. If I say enabled = f, the *only* thing that should be firing
> autovacuum on that relation is xid wrap.
Right, and you have the xid wrap timeout set to zero.
regar
On Fri, 2009-02-13 at 15:51 -0500, Jaime Casanova wrote:
> On Fri, Feb 13, 2009 at 3:21 PM, Joshua D. Drake
> wrote:
> > Hello,
> >
> > I found this today. Note, auto vacuum has been disabled for this
> > relation for a very, very long time. At the very end you will see that
> > this relation has
On Thu, 2009-02-12 at 16:06 -0800, Joshua D. Drake wrote:
> Hello,
>
> I was helping a customer today with what is becoming a common theme with
> a lot of work we do. Basically, "It was working fine until recently."
> Now 90% of the time it is as simple as running an ANALYZE VERBOSE and
> picking
On Fri, Feb 13, 2009 at 3:21 PM, Joshua D. Drake wrote:
> Hello,
>
> I found this today. Note, auto vacuum has been disabled for this
> relation for a very, very long time. At the very end you will see that
> this relation has been autovacuumed previously as well. We have a manual
> cron to vacuum
Merlin Moncure writes:
> On Fri, Feb 13, 2009 at 3:06 PM, Tom Lane wrote:
>> +1 for thinking ahead to the next time, but is a bit mask the right thing?
> What would you suggest? struct pointer? varargs?
Not sure. By definition, we're trying to predict an unforeseen
requirement, and that's al
On Fri, 2009-02-13 at 20:10 +, Grzegorz Jaskiewicz wrote:
> yet more arguments, to let postgresql estimate those automatically.
>
Well I haven't seen any arguments actually. Which was the point of my
original question. I don't think anyone actually knows what these knobs
change, in practice.
Hello,
I found this today. Note, auto vacuum has been disabled for this
relation for a very, very long time. At the very end you will see that
this relation has been autovacuumed previously as well. We have a manual
cron to vacuum this table every hour so I am unsure why autovacuum is
doing what i
On Fri, Feb 13, 2009 at 3:06 PM, Tom Lane wrote:
> Andrew Chernow writes:
>> Maybe the argument to PQinitSSLExtended should be a bit mask, making
>> this version more extendable ... PG_INITSSL, PG_INITCRYPTO?
>
> +1 for thinking ahead to the next time, but is a bit mask the right thing?
What wou
yet more arguments, to let postgresql estimate those automatically.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Chernow writes:
> Maybe the argument to PQinitSSLExtended should be a bit mask, making
> this version more extendable ... PG_INITSSL, PG_INITCRYPTO?
+1 for thinking ahead to the next time, but is a bit mask the right thing?
regards, tom lane
--
Sent via pgsql-ha
Tom Lane wrote:
Andrew Chernow writes:
Also, this definition feels a bit wrong --- it's not possible for
all four cases to be valid, is it?
Yes it is.
PQinitSSLExtended(0, 0); // don't init anything, PQinitSSL(0)
PQinitSSLExtended(1, 0); // init ssl, don't init crypto
PQinitSSLExtended(0,
Andrew Chernow writes:
>> Also, this definition feels a bit wrong --- it's not possible for
>> all four cases to be valid, is it?
> Yes it is.
> PQinitSSLExtended(0, 0); // don't init anything, PQinitSSL(0)
> PQinitSSLExtended(1, 0); // init ssl, don't init crypto
> PQinitSSLExtended(0, 1); // d
Andrew Chernow wrote:
At this point I like Merlin's proposal of a third parameter value to
PQinitSSL the best.
I'm not opposed to it, although I don't think it is as clean as a new
function.
Also, this definition feels a bit wrong --- it's not possible for
all four cases to be valid, is it
At this point I like Merlin's proposal of a third parameter value to
PQinitSSL the best.
I'm not opposed to it, although I don't think it is as clean as a new
function.
Also, this definition feels a bit wrong --- it's not possible for
all four cases to be valid, is it?
Yes it is.
PQinit
Andrew Chernow writes:
>> One problem with this patch is that a libpq app using PQinitSSL(0) is
>> under the assumption that this shuts off ssl init and crypto init. That
>> app might be doing its own crypto init which would be overwritten by
>> libpq because the app is unaware of PQinitCrypto
Andrew Chernow wrote:
Andrew Chernow wrote:
Robert Haas wrote:
On Fri, Feb 13, 2009 at 12:06 PM, Andrew Chernow wrote:
Patch attached.
One thing I noticed is the ssl_open_connections variable is ref
counting
connections when pq_initssllib is true. But, it now only affects
crypto
library i
Andrew Chernow wrote:
Robert Haas wrote:
On Fri, Feb 13, 2009 at 12:06 PM, Andrew Chernow wrote:
Patch attached.
One thing I noticed is the ssl_open_connections variable is ref counting
connections when pq_initssllib is true. But, it now only affects crypto
library init and cleanup calls. P
Robert Haas wrote:
On Fri, Feb 13, 2009 at 12:06 PM, Andrew Chernow wrote:
Patch attached.
One thing I noticed is the ssl_open_connections variable is ref counting
connections when pq_initssllib is true. But, it now only affects crypto
library init and cleanup calls. Point is, ref counting i
On Fri, Feb 13, 2009 at 12:06 PM, Andrew Chernow wrote:
> Patch attached.
>
> One thing I noticed is the ssl_open_connections variable is ref counting
> connections when pq_initssllib is true. But, it now only affects crypto
> library init and cleanup calls. Point is, ref counting is only needed
Cheers, i'll give it ago. I'm probably going to do a full restore over
the weekend while i can shut things down without too many complaints...
I can save any of the files if you are interested in them later on...
JOHN
Tom Lane wrote:
John Lister writes:
Any help would be appreciated as th
Teodor Sigaev writes:
>> seems to me that we ought to get rid of intarray's @> and <@ operators
>> and have the module depend on the core anyarray operators, just as we
>> have already done for = and <>. Comments?
> Agree, will do. Although built-in anyarray operators have ~N^2 behaviour
> whil
Robert Haas wrote:
On Fri, Feb 13, 2009 at 9:17 AM, Andrew Chernow wrote:
Should I create a patch implementing the PQinitCrypto idea?
I think that would be helpful. Seeing the code will give everyone a
better idea of exactly what the proposed change is and whether it's
acceptable.
...Robert
John Lister writes:
> Any help would be appreciated as the pg_class table is constantly
> growing which i'm guessing is going to start to affect performance
> fairly soon. I'd like to avoid a full restore from backup if possible.
BTW, what I would recommend as a recovery action is to zero out t
On Fri, Feb 13, 2009 at 9:07 AM, Joshua Brindle wrote:
> KaiGai Kohei wrote:
>>
>> KaiGai Kohei wrote:
>>>
>>> The series of SE-PostgreSQL patches are updated:
>>> [1/5]
>>> http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1530.patch
>>> [2/5]
>>> http://sepgsql.googlecode.com/
John Lister writes:
> Originally in psql-admin, but copied here at the request of Tom to..
Thanks for forwarding this. The reason I wanted to call it to the
attention of pgsql-hackers is that the page contents seem a bit odd,
and I'm not sure that we should just write it off as "pilot error".
Wh
Nikhil Sontakke writes:
>> Shouldn't the drop cascade have deleted comptype2 itself, instead of just
>> deleting the dependent column? Or this is the expected intentional
>> behaviour?
In the case of a table it's certainly the desired behavior that only
the column and not the whole table goes awa
[ shrug... ] The proposed implementation fails to be particularly
fast-start anyway, since it will process the entire pending queue
before returning anything to the executor.
That is not true for fastupdate=off. But in any case it could be improved, but
improvements doesn't solve the issue wit
Heikki Linnakangas writes:
> Teodor Sigaev wrote:
>> But I don't believe that is popular use-case. In most cases, GIN is used
>> with bitmap scan. Your emails are so convincing and I'll remove support
>> amgettuple interface in GIN.
> SELECT * FROM foo WHERE t @@ query LIMIT 100
> might be a fa
Teodor Sigaev writes:
> Do you think we need to add new pg_am boolean option? Like
> pg_am.amcangettuple
> or pg_am.amcanpertuplescan
I think it's sufficient to mark this by setting amgettuple to zero.
We might as well allow amgetbitmap to be zero, too, to mark the case
where the AM doesn't wa
On Fri, Feb 13, 2009 at 02:29:39PM +0200, BogDan Vatra wrote:
> [..]
> >> A message for postgresql decision board:
> >>
> >> Dear postgresql hackers, if I can do something to push row level
> >> acl for 8.4 please tell me, I do anything to have this feature,
> >> it will help me, and I hope many ot
On Fri, Feb 13, 2009 at 9:17 AM, Andrew Chernow wrote:
> Should I create a patch implementing the PQinitCrypto idea?
I think that would be helpful. Seeing the code will give everyone a
better idea of exactly what the proposed change is and whether it's
acceptable.
...Robert
--
Sent via pgsql-
Robert Haas wrote:
On Feb 11, 2009, at 12:12 AM, Andrew Chernow wrote:
Robert Haas wrote:
I am not in love with the idea of using PQinitSSL(SOME_MAGIC_VALUE)
The issue I see is the inability to toggle crypto initialization. I
think crypto init and ssl init are 2 different things. Thus, I
KaiGai Kohei wrote:
KaiGai Kohei wrote:
The series of SE-PostgreSQL patches are updated:
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1530.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1530.patch
[3/5]
http://sepgsql.googlecod
On Fri, Feb 13, 2009 at 04:12:53PM +0300, Teodor Sigaev wrote:
>> The short-term workaround for Rusty is probably to create his GIN
>> index using the intarray-provided gin__int_ops opclass. But it
> Right
>> seems to me that we ought to get rid of intarray's @> and <@ operators
>> and have the mo
On Fri, Feb 13, 2009 at 8:00 AM, Teodor Sigaev wrote:
>> SELECT * FROM foo WHERE t @@ query LIMIT 100
>> might be a fairly common use case.
>
> It seems to me -
> SELECT * FROM foo WHERE t @@ query *ORDER BY rank* LIMIT 100;
I'm not sure you can really assume that the ORDER BY rank will always
be
The short-term workaround for Rusty is probably to create his GIN
index using the intarray-provided gin__int_ops opclass. But it
Right
seems to me that we ought to get rid of intarray's @> and <@ operators
and have the module depend on the core anyarray operators, just as we
have already done f
Peter Eisentraut píše v čt 12. 02. 2009 v 15:30 +0200:
>
> > I am not aware of any server changes needed for 8.3-8.4 migration.
>
> OK, Zdenek, any concerns, or can we consider this chapter closed?
I think, that it is closed now. Space reservation will be backported if
we need it for 8.4->8.5.
--On Donnerstag, Februar 12, 2009 16:06:31 -0800 "Joshua D. Drake"
wrote:
However, in recent times I have found that increasing cpu_tuple_cost,
cpu_operator_cost and cpu_index_tuple_cost to be very useful. This is
always in the scenario of, "queries were running fine for months and
then all of
SELECT * FROM foo WHERE t @@ query LIMIT 100
might be a fairly common use case.
It seems to me -
SELECT * FROM foo WHERE t @@ query *ORDER BY rank* LIMIT 100;
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: ht
Teodor Sigaev wrote:
So? Barring some evidence that there's a significant performance win
from a conventional indexscan, this is a weak argument. AFAICS the only
significant advantage of the conventional API is to support ordered
scans, and GIN doesn't do that anyway.
What about SELECT ... AN
[..]
>> A message for postgresql decision board:
>>
>>Dear postgresql hackers, if I can do something to push row level acl
>> for 8.4 please tell me, I do anything to have this feature, it will
>> help me, and I hope many others, this feature will help to develop
>> client to postgres applicati
>
>
> Consider the following on latest sources:
>
> postgres=# create type c3 as (y int, z c1);
Oops, please disregard the above copy-paste unwanted sql.
>
> postgres=# create type comptype1 as (elem1 int);
>
> postgres=# create type comptype2 as (elem1 int, elem2 comptype1);
> postgres=# \d co
Hi,
Consider the following on latest sources:
postgres=# create type c3 as (y int, z c1);
postgres=# create type comptype1 as (elem1 int);
postgres=# create type comptype2 as (elem1 int, elem2 comptype1);
postgres=# \d comptype2
Composite type "public.comptype2"
Column | Type
+---
So? Barring some evidence that there's a significant performance win
from a conventional indexscan, this is a weak argument. AFAICS the only
significant advantage of the conventional API is to support ordered
scans, and GIN doesn't do that anyway.
What about SELECT ... AND EXISTS (SELECT ... t
Simon Riggs wrote:
I think my proposal still holds water, but I also think it is probably
time to say OK, let's make this simpler and take the subxid tuning off
line.
Agreed.
We would need to increase the max size of the xip array by
2*max_connections. So an increase of 80kB on normal running
On Thu, 2009-02-12 at 09:50 +0200, Heikki Linnakangas wrote:
> It occurs to me that we don't need this patch for hot standby if we
> abuse the main xid array (SnapshotData.xip) to store the unobserved xids
> instead of the subxid array. That one is always scanned in
> XidInMVCCSnapshot. I thin
On Fri, 2009-02-13 at 10:55 +0200, Heikki Linnakangas wrote:
> >>> The logic is: if there is no lock table entry for that xid *and* it is
> >>> not in progress *and* it is not in pg_subtrans, then it must have been
> >>> an aborted subtransaction of a currently active xact or it has otherwise
> >
Hi,
Thanks for the comments!
On Fri, Feb 13, 2009 at 5:00 AM, Alvaro Herrera
wrote:
> Fujii Masao escribió:
>
> I noticed two very minor issues while reading your docs:
>
>>This is because WAL files generated in the primary server before this
>> built-in
>>replication starts hav
Heikki Linnakangas wrote:
And on top of that, decode() is supposed to do short-circuit evaluation
of the arguments.
Then the only solution is to hack it right into the parser.
There is an existing decode() function however ...
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
2009/2/13 Heikki Linnakangas :
> Peter Eisentraut wrote:
>>
>> Tom Lane wrote:
>>>
>>> Peter Eisentraut writes:
I think what you want here is some way to define a function that takes
an arbitrary number of arguments of arbitrary type and let the function
figure everything out.
Bruce Momjian wrote:
Tom Lane wrote:
Alvaro Herrera writes:
Heikki Linnakangas wrote:
Hmm, I remember I pondered for a long time if it should be COLLATE and
CTYPE or LC_COLLATE and LC_CTYPE. I think the rationale in the end was
that a) COLLATE/CTYPE looks nicer and b) if we add support for
>Please send to pgsql-hackers --- I'd like to get more eyeballs on this.
>There's no personally identifiable information here except that you've
>got a table named temp_queue that you've repeatedly TRUNCATEd or
>CLUSTERed or some such (likely the former since the reltuples counts
>are all zero). I
Euler Taveira de Oliveira wrote:
IMHO, we shouldn't advise packagers to do it and instead put some efforts in
the in-place-upgrade project.
First, packagers are already doing (part of) it. Second, I don't see
where this in-place-upgrade is suddenly going to come from. And third,
even if you
Tom Lane wrote:
ISTM that having psql alone be cross-version-compatible will be just
about completely uninteresting to packagers. If we could make *all*
the user-facing executables be cross-version, then we'd be getting
somewhere;
Wel, I'm not so sure about the "completely uninteresting", but
Euler Taveira de Oliveira wrote:
Alvaro Herrera escreveu:
Euler Taveira de Oliveira wrote:
Peter Eisentraut escreveu:
If no such list exists yet, perhaps we can complete the above one, document
it, and pass it on to the packagers.
Are you suggesting that if an user has 7.4 and install 8.3 t
Michael Meskes wrote:
On Thu, Feb 12, 2009 at 04:16:05PM +0200, Peter Eisentraut wrote:
ItemCompatible across major versions?
(i.e. the 8.4 version works with 7.4+ server)
...
ecpgno?
It depends on which kind of compatibility you're looking for. The gram
Simon Riggs wrote:
On Thu, 2009-02-12 at 14:23 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2009-02-12 at 09:50 +0200, Heikki Linnakangas wrote:
So far so good, but what about all the other callers of
SubTransGetParent()? For example, XactLockTableWait will fail an
assertion if
Andrew Dunstan wrote:
I also don't really understand what is confusing about the description.
Where does the benefit of using it come from? When would one want to
use it? Is it because the parallelization happens on the client or on
the server? Does it happen because to CPU parallelization
Tom Lane wrote:
Is this acceptable to everyone? We could name the option
-u/--upgrade-compatible.
If the switch is specifically for pg_upgrade support (enabling this as
well as any other hacks we find necessary), which seems like a good
idea, then don't chew up a short option letter for it. T
Peter Eisentraut wrote:
Tom Lane wrote:
Peter Eisentraut writes:
I think what you want here is some way to define a function that
takes an arbitrary number of arguments of arbitrary type and let the
function figure everything out. I see no reason why this can't be a
variant on CREATE FUNCTI
Tom Lane wrote:
Peter Eisentraut writes:
I think what you want here is some way to define a function that takes an
arbitrary number of arguments of arbitrary type and let the function figure
everything out. I see no reason why this can't be a variant on CREATE
FUNCTION, except that of course
Originally in psql-admin, but copied here at the request of Tom to..
Story so far, transaction log archiving went wrong causing the
transaction log disk to fill up. Foolishly i deleted the unarchived
transaction logs (early monday morning) which required a pg_resetxlog to
get the db up and run
On Thu, 2009-02-12 at 14:23 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-02-12 at 09:50 +0200, Heikki Linnakangas wrote:
> >> So far so good, but what about all the other callers of
> >> SubTransGetParent()? For example, XactLockTableWait will fail an
> >> assertion if
74 matches
Mail list logo
