On Tue, Nov 1, 2011 at 12:11 PM, Simon Riggs 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 on the critical pa
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:
http://www.postgresql.org/mailpref
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, whi
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=jaguar&dt=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 :
te
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 (n
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.)
>
http://www.pgsql.cz
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 pat
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)
Mich
On Sun, Nov 13, 2011 at 1:13 PM, Thom Brown 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 something like th
Simon Riggs 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 had forgotten abo
Boszormenyi Zoltan 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
> sqlda_native_total_size().
Is th
On Sun, Nov 13, 2011 at 4:09 PM, Tom Lane 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 partitioning infrastructur
Thom Brown 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 responses to beg
Simon Riggs 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 executor.
It's an int
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 o
On 13 November 2011 16:42, Tom Lane wrote:
> Thom Brown 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
On Sun, Nov 13, 2011 at 11:09 AM, Tom Lane wrote:
> Simon Riggs 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
Robert Haas writes:
> On Sun, Nov 13, 2011 at 11:09 AM, Tom Lane 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
> (parse/bind/execute), but why or
Mehdi Maache 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
regression diff intermittent
> 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 i
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 calle
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 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 and execution
On Nov14, 2011, at 00:13 , Robert Haas wrote:
> On Sun, Nov 13, 2011 at 12:57 PM, Tom Lane 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 basically proposing
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 wrote:
> On Nov14, 2011, at 00:13 , Robert Haas wrote:
>> On Sun, Nov 13, 2011 at 12:57 PM, Tom Lane 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 prepa
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
Si90
On Sun, Nov 13, 2011 at 7:37 PM, Robert Haas 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
>> overhead than the ex
On Sun, Nov 13, 2011 at 6:57 PM, Florian Pflug 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 in tab
On Sun, Nov 13, 2011 at 8:57 PM, Robert Haas 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 will reduce the exten
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 esti
34 matches
Mail list logo
