On Tue, Nov 1, 2011 at 12:11 PM, Simon Riggs si...@2ndquadrant.com wrote:
When I say skip the shutdown checkpoint, I mean remove it from the
critical path of required actions at the end of recovery. We can still
have a normal checkpoint kicked off at that time, but that no longer
needs to be
Hello,
I'm a new programmer in postgreSQL source code..
Is possible use MPI functions in postgreSQL source code?
Help me please!
Best Regards.
Rudyar.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 11/10/11 00:48, José Arthur Benetasso Villanova wrote:
First, I couldn't apply it as in the email, even in REL9_0_STABLE: the
offset doesn't look right. Which commit are your repository in?
Hi Jose, thanks for looking at the patch. It's based on
b07b2bdc570cfbb39564c8a70783dbce1edcb3d6,
Hi,
I don't know if you know but in case :
I have jaguar in check failure (
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=jaguardt=2011-11-03%2023%3A05%3A01
) since 03-11-2011 and I don't know what is it.
I built in other system with --nosend and it seems I have the same problem :
test
Hi José and Robert, thanks for your time and a review. Comments below.
On 11/10/11 03:47, Robert Haas wrote:
It does this already, without this patch. This patch is about CHECK
constraints, not UNIQUE ones.
That's right. This is how to check what the patch changes:
jkt= CREATE TABLE tbl
Hello
(And as a side note, I'm not really familiar with Postgres' internals,
so it took me roughly six hours to arrive to a working patch from the
very start. I'd therefore welcome pointers about the best way to achieve
that with Postgres' string stream interface.)
Hi Andrew,
On 13/11/2011 02:56, Andrew Dunstan wrote:
Here is a patch for that for pg_dump. The sections provided for are
pre-data, data and post-data, as discussed elsewhere. I still feel that
anything finer grained should be handled via pg_restore's --use-list
functionality. I'll provide a
On sön, 2011-11-13 at 00:58 +, Thom Brown wrote:
Is there a cost to having them there? Could there be tools that might
break if the columns were no longer available?
Doubtful. Views don't have system columns either.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Hi,
I don't know if this has been discussed before, but would it be
feasible to introduce the ability to detach and attach databases? (if
you're thinking stop right there skip to the end) What I had in
mind would be to do something like the following:
SELECT pg_detach_database('my_database')
This must have been a cut and paste bug and is incorrect
in 9.0.x, 9.1.x and GIT HEAD. It would be nice to have it
applied before the next point releases come out.
Applied, thanks for the patch.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
On Sun, Nov 13, 2011 at 1:13 PM, Thom Brown t...@linux.com wrote:
I don't know if this has been discussed before, but would it be
feasible to introduce the ability to detach and attach databases? (if
you're thinking stop right there skip to the end) What I had in
mind would be to do
Simon Riggs si...@2ndquadrant.com writes:
If we could be certain that a query was being executed immediately
... that is, with the same snapshot ...
then it would be possible to simplify expressions using stable
functions as if they were constants. My earlier patch did exactly
that.
Mph. I
Boszormenyi Zoltan z...@cybertec.at writes:
I had a report about ECPG code crashing which involved
a query using a date field. Attached is a one liner fix to make
the date type's offset computed consistently across
sqlda_common_total_size(), sqlda_compat_total_size() and
On Sun, Nov 13, 2011 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
As far as partitioning goes, the correct solution there
is to move the partition selection to run-time, so we should not be
contorting query semantics to make incremental performance improvements
with the existing
Thom Brown t...@linux.com writes:
I don't know if this has been discussed before, but would it be
feasible to introduce the ability to detach and attach databases? (if
you're thinking stop right there skip to the end)
... skipping ...
It's just a vague idea, and I'm kind of expecting
Simon Riggs si...@2ndquadrant.com writes:
It's all very well to refuse individual cases where linkage is
required, but ISTM clear that there are many possible uses of being
able to tell whether a plan is one-shot or not and nothing lost by
allowing that information (a boolean) pass to the
On Sunday, November 13, 2011 13:13:11 Thom Brown wrote:
Hi,
I don't know if this has been discussed before, but would it be
feasible to introduce the ability to detach and attach databases? (if
you're thinking stop right there skip to the end)
It's just a vague idea, and I'm kind of
On 13 November 2011 16:42, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com writes:
I don't know if this has been discussed before, but would it be
feasible to introduce the ability to detach and attach databases? (if
you're thinking stop right there skip to the end)
... skipping
On Sun, Nov 13, 2011 at 11:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
If we could be certain that a query was being executed immediately
... that is, with the same snapshot ...
then it would be possible to simplify expressions using stable
functions
Robert Haas robertmh...@gmail.com writes:
On Sun, Nov 13, 2011 at 11:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I remain of the opinion that Robert's proposal is a bad idea.
Wait a minute. I can understand why you think it's a bad idea to
preserve a snapshot across multiple protocol messages
Mehdi Maache ml...@ide-environnement.com writes:
test case : rangetypes ... FAILED
Hmm ... jaguar is the CLOBBER_CACHE_ALWAYS machine, isn't it.
I bet this reflects a cache flush bug in the new range-types code.
That would explain the fact that some other machines show the same
Tom Lane wrote:
Robert Haas writes:
I can understand why you think it's a bad idea to preserve a
snapshot across multiple protocol messages (parse/bind/execute),
but why or how would it be a bad idea to keep the same snapshot
between planning and execution when the whole thing is being
While digging around for the cause of the buildfarm failures in the new
rangetypes code, I noticed that range_gettypinfo thinks it can memcpy
the result of fmgr_info(). This is not cool. It's true that fn_extra
is likely to be NULL at the instant the copy occurs, but what will
happen if the
Well, I was overthinking the question of why rangetypes sometimes fails
with
select count(*) from test_range_gist where ir int4range(100,500);
! ERROR: input range is empty
Turns out that happens whenever auto-analyze has managed to process
test_range_gist before we get to this part of the
While investigating bug #6291 I was somewhat surprised to discover
$SUBJECT. The cause turns out to be this kluge in alter_table.sql:
select virtualtransaction
from pg_locks
where transactionid = txid_current()::integer
which of course starts to fail with integer out of
On Sun, Nov 13, 2011 at 12:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Wait a minute. I can understand why you think it's a bad idea to
preserve a snapshot across multiple protocol messages
(parse/bind/execute), but why or how would it be a bad idea to keep
the same snapshot between planning
On Nov14, 2011, at 00:13 , Robert Haas wrote:
On Sun, Nov 13, 2011 at 12:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In that case you must be of the opinion that extended query protocol
is a bad idea and we should get rid of it, and the same for prepared
plans of all types. What you're
On Nov13, 2011, at 01:38 , Tom Lane wrote:
Just a couple hours ago I was wondering why we create system columns for
foreign tables at all. Is there a reasonable prospect that they'll ever
be useful? I can see potential value in tableoid, but the others seem
pretty dubious --- even if you
On Sun, Nov 13, 2011 at 6:45 PM, Florian Pflug f...@phlo.org wrote:
On Nov14, 2011, at 00:13 , Robert Haas wrote:
On Sun, Nov 13, 2011 at 12:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In that case you must be of the opinion that extended query protocol
is a bad idea and we should get rid of it,
Hi,
I've noticed that psql query buffer somehow interferes with dearmor
(from pgcrypto), corrupting the data. For example this works fine:
SELECT dearmor('-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v2.0.17 (GNU/Linux)
mQGiBE7AfUoRBACpupjE5tG9Fh1dWe2kb/yX+lNlMLpwMj1hjTrJo1cYmSYixkGX
On Sun, Nov 13, 2011 at 7:37 PM, Robert Haas robertmh...@gmail.com wrote:
In my experience, it's hard enough as it is to convince developers to
use statement parameters instead of interpolating them into the SQL
string. Once word gets out that the simple protocol is now has less locking
On Sun, Nov 13, 2011 at 6:57 PM, Florian Pflug f...@phlo.org wrote:
On Nov13, 2011, at 01:38 , Tom Lane wrote:
Just a couple hours ago I was wondering why we create system columns for
foreign tables at all. Is there a reasonable prospect that they'll ever
be useful? I can see potential value
On Sun, Nov 13, 2011 at 8:57 PM, Robert Haas robertmh...@gmail.com wrote:
In the -M extended case, we take a snapshot from exec_parse_message(),
and the same two in the exec_bind_message() call that are taken in the
-M prepared case. So reducing the prepared case from two snapshots to
one
On Sun, 2011-11-13 at 15:38 -0500, Tom Lane wrote:
If the table has been analyzed, then the
most_common_values array for column ir will consist of
{empty}
which is entirely correct since that value accounts for 16% of the
table. And then, when mcv_selectivity tries to estimate
34 matches
Mail list logo
