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 asked to
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
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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,
Peter Eisentraut wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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.
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
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
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
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
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:
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
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). It'd
Bruce Momjian wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
2009/2/13 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Peter Eisentraut wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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
Hi,
Thanks for the comments!
On Fri, Feb 13, 2009 at 5:00 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
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
completed.
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 think
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
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 ...
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
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 comptype2
[..]
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 applications without
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 ...
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:
--On Donnerstag, Februar 12, 2009 16:06:31 -0800 Joshua D. Drake
j...@commandprompt.com 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
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. And
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
On Fri, Feb 13, 2009 at 8:00 AM, Teodor Sigaev teo...@sigaev.ru 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
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 module
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]
Robert Haas wrote:
On Feb 11, 2009, at 12:12 AM, Andrew Chernow a...@esilo.com 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
On Fri, Feb 13, 2009 at 9:17 AM, Andrew Chernow a...@esilo.com 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
--
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 others, this
Teodor Sigaev teo...@sigaev.ru 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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 @@
[ 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
Nikhil Sontakke nikhil.sonta...@enterprisedb.com 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
John Lister john.lister...@kickstone.com 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
On Fri, Feb 13, 2009 at 9:07 AM, Joshua Brindle met...@manicmethod.com 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]
John Lister john.lister...@kickstone.com 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
Robert Haas wrote:
On Fri, Feb 13, 2009 at 9:17 AM, Andrew Chernow a...@esilo.com 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
Teodor Sigaev teo...@sigaev.ru 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
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 john.lister...@kickstone.com writes:
Any
On Fri, Feb 13, 2009 at 12:06 PM, Andrew Chernow a...@esilo.com 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
Robert Haas wrote:
On Fri, Feb 13, 2009 at 12:06 PM, Andrew Chernow a...@esilo.com 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,
Andrew Chernow wrote:
Robert Haas wrote:
On Fri, Feb 13, 2009 at 12:06 PM, Andrew Chernow a...@esilo.com 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
Andrew Chernow wrote:
Andrew Chernow wrote:
Robert Haas wrote:
On Fri, Feb 13, 2009 at 12:06 PM, Andrew Chernow a...@esilo.com 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
Andrew Chernow a...@esilo.com 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
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.
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
Andrew Chernow a...@esilo.com 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,
Tom Lane wrote:
Andrew Chernow a...@esilo.com 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
Andrew Chernow a...@esilo.com 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
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
On Fri, Feb 13, 2009 at 3:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Chernow a...@esilo.com 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
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
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.
Merlin Moncure mmonc...@gmail.com writes:
On Fri, Feb 13, 2009 at 3:06 PM, Tom Lane t...@sss.pgh.pa.us 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
On Fri, Feb 13, 2009 at 3:21 PM, Joshua D. Drake j...@commandprompt.com 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
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 apart
On Fri, 2009-02-13 at 15:51 -0500, Jaime Casanova wrote:
On Fri, Feb 13, 2009 at 3:21 PM, Joshua D. Drake j...@commandprompt.com
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
Joshua D. Drake j...@commandprompt.com 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.
On Fri, Feb 13, 2009 at 3:27 PM, Joshua D. Drake j...@commandprompt.com 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
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
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
Zdenek Kotala zdenek.kot...@sun.com 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
On Fri, Feb 13, 2009 at 4:53 PM, Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
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.
Jaime Casanova wrote:
On Fri, Feb 13, 2009 at 9:07 AM, Joshua Brindle met...@manicmethod.com 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]
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
On Fri, Feb 13, 2009 at 8:32 PM, KaiGai Kohei kai...@kaigai.gr.jp 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
Jaime Casanova wrote:
On Fri, Feb 13, 2009 at 8:32 PM, KaiGai Kohei kai...@kaigai.gr.jp 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
74 matches
Mail list logo
