Hi all,
I'm seeing the results of pg_basebackup and I saw postmaster.opts.
Is not necessary, although is inoffensive. But has the name of the
original cluster name inside. If it's only keep for information purposes,
maybe backup_label could be the right place.
Is just an idea.
Thougths?
--
--
Hi,
Query:
=
I am aware of the fact that Expression evaluator is used to filter tuples
based on the qual. However, I think it is not the only purpose it serves. As
I manipulated the ExecEvalVar in the executor, the queries started behaving
abnormally (the comparison operators < , <>, > lost ef
On Wed, May 25, 2011 at 3:22 PM, Vaibhav Kaushal <
vaibhavkaushal...@gmail.com> wrote:
> I see that the target list to be scanned is handled by "ExecTargetList"
> function.
>
> I am not so sure about this because this function is not listed in the list
> of functions which GDB shows me (./configur
On Wed, May 18, 2011 at 2:11 PM, Leonardo Francalanci wrote:
> this is a second version: now using
>
> int counts[1]; /* variable-length array of counts */
>
> in xl_xact_commit to keep track of number of
>
> different arrays at the end of the struct.
>
> Waiting for feedbacks...
* Alvaro Herrera (alvhe...@commandprompt.com) wrote:
> Excerpts from Stephen Frost's message of mar may 24 22:56:21 -0400 2011:
>
> > A couple of notes regarding the patch:
> >
> > First, it uses ffs(), which might not be fully portable.. We could
> > certainly implement the same thing in
On Tue, May 24, 2011 at 10:59 PM, Robert Haas wrote:
> So, first of all, thanks for putting some effort and thought into
> this. Despite the large number of improvements in this area in 8.3
> and 8.4, this is still a pain point, and it would be really nice to
> find a way to make some further im
I hear that CF manager is a difficult role for a single individual.
So it makes sense to split that role between multiple people.
I volunteer to be the CF manager for Replication, and also for
Performance. I have an interest in and long experience in each of
those areas, so that makes sense for m
On Tue, May 24, 2011 at 02:00:54PM -0400, Noah Misch wrote:
> On Tue, May 24, 2011 at 01:28:38PM -0400, Tom Lane wrote:
> > Noah Misch writes:
> > > On Tue, May 24, 2011 at 12:12:55PM -0400, Tom Lane wrote:
> > >> This is a consequence of the changes I made to fix bug #5717,
> > >> particularly th
On Tue, May 24, 2011 at 7:58 AM, Pavan Deolasee
wrote:
> The biggest gripe today is that vacuum needs two heap scans and each scan
> dirties the buffer.
That's not that clear to me. The debate usually stalls because we
don't have sufficient info from real world analysis of where the time
goes.
On Wed, May 25, 2011 at 6:16 AM, Heikki Linnakangas
wrote:
>> To achieve that, I'm thinking to change walsender so that, when the
>> standby
>> has caught up with the master, it sends back the message indicating that
>> to
>> the standby. And I'm thinking to add new function (or view like
>> pg_s
While looking at fixing the multiple-evaluation issue in IN and BETWEEN
discussed a while ago, I realized that the current assumption that only
one CaseTestExpr placeholder needs to be valid at any given time is not
true.
Here's a bit contrived example:
CREATE FUNCTION evileq (timestamptz, in
On 25.05.2011 14:57, Heikki Linnakangas wrote:
Here's a bit contrived example:
CREATE FUNCTION evileq (timestamptz, int4) returns boolean AS $$
SELECT case $2 WHEN length($1::text) THEN true ELSE false END;
$$ language sql;
CREATE OPERATOR = (procedure = evileq, leftarg = timestamptz, rightarg =
On Wed, May 25, 2011 at 7:31 AM, Simon Riggs wrote:
> On Tue, May 24, 2011 at 7:58 AM, Pavan Deolasee
> wrote:
>
>> The biggest gripe today is that vacuum needs two heap scans and each scan
>> dirties the buffer.
>
> That's not that clear to me. The debate usually stalls because we
> don't have s
On Tue, May 24, 2011 at 6:37 PM, Robert Haas wrote:
>> That being said, it's a slight extra cost for all fast-path lockers to
>> benefit
>> the strong lockers, so I'm not prepared to guess whether it will pay off.
>
> Yeah. Basically this entire idea is about trying to make life easier
> for we
On Tue, May 24, 2011 at 10:52 PM, Jeff Davis wrote:
> On Tue, 2011-05-24 at 16:34 -0400, Robert Haas wrote:
>> As I think about it a bit more, we'd
>> need to XLOG not only the parts of the page we actually modifying, but
>> any that the WAL record would need to be correct on replay.
>
> I don't u
On Tue, May 24, 2011 at 11:52 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> 2. The other fairly obvious alternative is to adjust our existing WAL
>> record types to be idempotent - i.e. to not rely on the existing page
>> contents. For XLOG_HEAP_INSERT, we currently store the target tid and
>>
On Wed, May 25, 2011 at 8:27 AM, Simon Riggs wrote:
> I got a bit lost with the description of a potential solution. It
> seemed like you were unaware that there is a local lock and a shared
> lock table, maybe just me?
No, I'm not unaware of the local lock table. The point of this
proposal is t
On Wed, May 25, 2011 at 1:44 PM, Robert Haas wrote:
> On Wed, May 25, 2011 at 8:27 AM, Simon Riggs wrote:
>> I got a bit lost with the description of a potential solution. It
>> seemed like you were unaware that there is a local lock and a shared
>> lock table, maybe just me?
>
> No, I'm not unaw
On Tue, May 24, 2011 at 9:34 PM, Robert Haas wrote:
> I'm not sure that these ideas are much good, but
> for the sake of posterity:
Both (1) and (2) seem promising to me.
Heikki mentioned (2) would only be effective if we managed to change
*all* WAL records. ISTM likely that we would find that
On Wed, May 25, 2011 at 1:27 PM, Robert Haas wrote:
>> At the moment we scan indexes if we have > 0 rows to remove, which is
>> probably wasteful. Perhaps it would be better to keep a running total
>> of rows to remove, by updating pg_stats, then when we hit a certain
>> threshold in total we can
> Da: Simon Riggs
> I can't find a clear discussion of what you are trying to do, and how,
> just a URL back to a complex discussion on another topic.
While trying to write a patch to allow changing an unlogged table into
a logged one, I had to add another int field to xl_xact_commit.
Robert H
On Wed, May 25, 2011 at 7:07 AM, Pavan Deolasee
wrote:
>> But instead of allocating permanent space in the page header, which would
>> both reduce (admittedly only by 8 bytes) the amount of space available
>> for tuples, and more significantly have the effect of breaking on-disk
>> compatibility,
commitlog_lessbytes02.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas writes:
> On 25.05.2011 07:42, Fujii Masao wrote:
>> To achieve that, I'm thinking to change walsender so that, when the standby
>> has caught up with the master, it sends back the message indicating that to
>> the standby. And I'm thinking to add new function (or view like
>> p
On Wed, May 25, 2011 at 7:20 PM, Robert Haas wrote:
> On Wed, May 25, 2011 at 7:07 AM, Pavan Deolasee
> wrote:
>>> But instead of allocating permanent space in the page header, which would
>>> both reduce (admittedly only by 8 bytes) the amount of space available
>>> for tuples, and more signific
* Simon Riggs (si...@2ndquadrant.com) wrote:
> So it makes sense to split that role between multiple people.
I agree that it'd be good to have multiple people supporting the CF.
I've been considering volunteering to be part of such a group for a
given CF.
> I volunteer to be the CF manager for Re
On Wed, May 25, 2011 at 5:57 PM, Robert Haas wrote:
>
> Alternatively, it's possible that we'd be better off vacuuming the
> table more often (say, autovacuum_vacuum_scale_factor=0.10 or 0.08 or
> something) but only doing the index scans every once in a while when
> enough dead line pointers hav
Robert Haas wrote:
> That idea has the additional advantage of confusing the level of
> detail of our WAL logging (minimal vs. archive vs. hot standby) with
> the mechanism used to protect against torn pages (full page writes vs.
> idempotent WAL records vs. prayer). When they set it wrong and
> d
Michael Nolan wrote:
Based on last year's discussion of this TODO item, it seems thoughts
have been focused on estimating how much data is
being satisfied from PG's shared buffers. However, I think that's
only part of the problem.
Sure, but neither it nor what you're talking about are the r
Simon Riggs writes:
> I hear that CF manager is a difficult role for a single individual.
> So it makes sense to split that role between multiple people.
> I volunteer to be the CF manager for Replication, and also for
> Performance. ...
> Patches need an eventual committer anyway, so this is a r
Sorry, email sent without body.
Fixed some English mistakes.
commitlog_lessbytes02.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 25, 2011 at 3:24 PM, Tom Lane wrote:
> Simon Riggs writes:
>> I hear that CF manager is a difficult role for a single individual.
>> So it makes sense to split that role between multiple people.
>
>> I volunteer to be the CF manager for Replication, and also for
>> Performance. ...
>>
Simon Riggs writes:
> On Wed, May 25, 2011 at 1:44 PM, Robert Haas wrote:
>> On Wed, May 25, 2011 at 8:27 AM, Simon Riggs wrote:
>>> Design seemed relatively easy from there: put local lock table in
>>> shared memory for all procs. We then have a use_strong_lock at proc
>>> and at transaction le
2011/5/25 Hitoshi Harada :
> So I'm still
> thinking which of pulling up and parameterized scan is better.
After more investigation I came up with third idea, pushing down
RangeTblEntry to aggregate subquery. This sounds like a crazy idea,
but it seems to me like it is slightly easier than pulling
Excerpts from Vaibhav Kaushal's message of mié may 25 05:52:32 -0400 2011:
> If the above is confusing, I just want to ask: "Is expression evaluator,
> even in part responsible for {PLANNEDSTMT creation?"
Yeah, as far as I understood Tom's talk, the expr evaluator is used to
reduce some expressio
Alvaro Herrera writes:
> Excerpts from Vaibhav Kaushal's message of mié may 25 05:52:32 -0400 2011:
>> If the above is confusing, I just want to ask: "Is expression evaluator,
>> even in part responsible for {PLANNEDSTMT creation?"
> Yeah, as far as I understood Tom's talk, the expr evaluator is
Hitoshi Harada writes:
> 2011/5/25 Hitoshi Harada :
>> So I'm still
>> thinking which of pulling up and parameterized scan is better.
> After more investigation I came up with third idea, pushing down
> RangeTblEntry to aggregate subquery. This sounds like a crazy idea,
Yes, it sure does. Won't
On Wed, May 25, 2011 at 8:56 AM, Simon Riggs wrote:
> On Wed, May 25, 2011 at 1:44 PM, Robert Haas wrote:
>> On Wed, May 25, 2011 at 8:27 AM, Simon Riggs wrote:
>>> I got a bit lost with the description of a potential solution. It
>>> seemed like you were unaware that there is a local lock and a
On Wed, May 25, 2011 at 2:43 PM, Leonardo Francalanci wrote:
>> Da: Simon Riggs
>> I can't find a clear discussion of what you are trying to do, and how,
>> just a URL back to a complex discussion on another topic.
>
>
> While trying to write a patch to allow changing an unlogged table into
> a
Florian Helmberger writes:
> On 25.05.11 04:47, Tom Lane wrote:
>> Florian Helmberger writes:
>>> I'm running a production database with PostgreSQL 9.0.3 (64-bit) on
>>> Debian 5.0.4 and have an issue with a TOAST table and far to frequent
>>> autovacuum runs.
>>>
>>> I think I've pinned the pro
2011/5/26 Tom Lane :
> Hitoshi Harada writes:
>> 2011/5/25 Hitoshi Harada :
>>> So I'm still
>>> thinking which of pulling up and parameterized scan is better.
>
>> After more investigation I came up with third idea, pushing down
>> RangeTblEntry to aggregate subquery. This sounds like a crazy ide
Heikki Linnakangas writes:
> While looking at fixing the multiple-evaluation issue in IN and BETWEEN
> discussed a while ago, I realized that the current assumption that only
> one CaseTestExpr placeholder needs to be valid at any given time is not
> true.
[ scratches head ... ] Why does the
On Wed, May 25, 2011 at 10:32 AM, Simon Riggs wrote:
> On Wed, May 25, 2011 at 3:24 PM, Tom Lane wrote:
>> Simon Riggs writes:
>>> I hear that CF manager is a difficult role for a single individual.
>>> So it makes sense to split that role between multiple people.
>>
>>> I volunteer to be the CF
Excerpts from Tom Lane's message of mié may 25 11:47:52 -0400 2011:
> I think I see what must be going on here: that toast table must contain
> a long run of all-visible-according-to-the-VM pages (which is hardly a
> surprising situation). This results in VACUUM choosing not to update
> the pg_cl
On Wed, May 25, 2011 at 10:13 AM, Bruce Momjian wrote:
>> > Idempotent does seem like the most promising idea.
>>
>> I tend to agree with you, but I'm worried it won't actually work out
>> to a win. By the time we augment the records with enough additional
>> information we may have eaten up a lo
On Wed, May 25, 2011 at 10:35 AM, Hitoshi Harada wrote:
> 2011/5/25 Hitoshi Harada :
>> So I'm still
>> thinking which of pulling up and parameterized scan is better.
>
> After more investigation I came up with third idea, pushing down
> RangeTblEntry to aggregate subquery. This sounds like a craz
Simon Riggs wrote:
> On Tue, May 24, 2011 at 6:37 PM, Robert Haas wrote:
>
> >> That being said, it's a slight extra cost for all fast-path lockers to
> >> benefit
> >> the strong lockers, so I'm not prepared to guess whether it will pay off.
> >
> > Yeah. ?Basically this entire idea is about tr
On Wed, May 25, 2011 at 11:47 AM, Tom Lane wrote:
> 2. Revise the vacuum code so that it doesn't skip updating the pg_class
> entries. We could have it count the number of pages it skipped, rather
> than just keeping a bool, and then scale up the rel_tuples count to be
> approximately right by as
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié may 25 11:47:52 -0400 2011:
>> I can see two basic approaches we might take here:
>>
>> 1. Modify autovacuum to use something from the stats collector, rather
>> than reltuples, to make its decisions. I'm not too clear on why
>> r
On Wed, May 25, 2011 at 10:07 AM, Pavan Deolasee
wrote:
>> I'm confused. A major point of the approach I was proposing was to
>> avoid having to move tuples around.
>
> Well, I am not sure how you can always guarantee to make space
> available for the LSN without moving tuples , irrespective of w
Tom Lane wrote:
> I don't know what client-side code might be looking at
> relpages/reltuples.
I know that I find reltuples useful for getting an "accurate enough"
sense of rows in a table (or set of tables) without resorting to
count(*). I'd be OK with any two of pages, tuples, and density;
Excerpts from Bruce Momjian's message of mar may 24 15:59:59 -0400 2011:
> > I think you misread what I wrote, or I misexplained it, but never
> > mind. Matching locale names case-insensitively sounds reasonable to
> > me, unless someone has reason to believe it will blow up.
>
> OK, that's what
Robert Haas writes:
> On Wed, May 25, 2011 at 11:47 AM, Tom Lane wrote:
>> 2. Revise the vacuum code so that it doesn't skip updating the pg_class
>> entries. We could have it count the number of pages it skipped, rather
>> than just keeping a bool, and then scale up the rel_tuples count to be
>
@pavan - thanks a lot. Will try it when i go to desktop the next time.
--
Sent from my Android
On 25 May 2011 15:33, "Pavan Deolasee" wrote:
> On Wed, May 25, 2011 at 3:22 PM, Vaibhav Kaushal <
> vaibhavkaushal...@gmail.com> wrote:
>
>> I see that the target list to be scanned is handled by "Exec
Please find the updated patch. I have added this "+Olibmerrno" compile flag
check in configure/configure.in file.
OS
HP-UX B.11.31 U ia64
without patch
---
postgres=# select acos(2);
acos
--
NaN
(1 row)
with patch
---
postgres=# select acos(2);
ERROR: input is
On Wed, May 25, 2011 at 10:17 AM, Greg Smith wrote:
>> This data would probably need to be kept separately for each table or
>> index, as some tables or indexes
>> may be mostly or fully in cache or on faster physical media than others,
>> although in the absence of other
>> data about a specific
Excerpts from Robert Haas's message of mié may 25 12:27:38 -0400 2011:
> On Wed, May 25, 2011 at 10:07 AM, Pavan Deolasee
> wrote:
> > I think if are reclaiming LP_DEAD line pointers only while
> > defragmenting the page, we can always reclaim the space for the LSN,
> > irrespective of where we s
On Wed, May 25, 2011 at 12:41 PM, Tom Lane wrote:
> Yeah, I had been thinking about the latter point. We could be
> conservative and just keep the reported tuple density the same (ie,
> update relpages to the new correct value, while setting reltuples so
> that the density ratio doesn't change).
Excerpts from Kevin Grittner's message of mié may 25 12:37:24 -0400 2011:
> Tom Lane wrote:
>
> > I don't know what client-side code might be looking at
> > relpages/reltuples.
>
> I know that I find reltuples useful for getting an "accurate enough"
> sense of rows in a table (or set of tables
Robert Haas writes:
> On Wed, May 25, 2011 at 12:41 PM, Tom Lane wrote:
>> Yeah, I had been thinking about the latter point. We could be
>> conservative and just keep the reported tuple density the same (ie,
>> update relpages to the new correct value, while setting reltuples so
>> that the dens
On Wed, May 25, 2011 at 12:48 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié may 25 12:27:38 -0400 2011:
>> On Wed, May 25, 2011 at 10:07 AM, Pavan Deolasee
>> wrote:
>
>> > I think if are reclaiming LP_DEAD line pointers only while
>> > defragmenting the page, we can alwa
On 25.05.2011 17:47, Tom Lane wrote:
Heikki Linnakangas writes:
While looking at fixing the multiple-evaluation issue in IN and BETWEEN
discussed a while ago, I realized that the current assumption that only
one CaseTestExpr placeholder needs to be valid at any given time is not
true.
[ scrat
Heikki Linnakangas writes:
> On 25.05.2011 17:47, Tom Lane wrote:
>> [ scratches head ... ] Why does the save/restore in ExecEvalCase not
>> take care of this?
> The mistake happens during planning, when the SQL function is inlined
> and pre-evaluated.
Hm. I'm inclined to think this may be mo
Excerpts from Robert Haas's message of mié may 25 12:54:28 -0400 2011:
> I don't know. That's maybe better, but I'd be willing to wager that
> in some cases it will just slow down the rate at which we converge to
> a completely incorrect value, while in other cases it'll fail to
> update the data
On Wed, May 25, 2011 at 1:04 PM, Tom Lane wrote:
> [ shrug... ] When you don't have complete information, it's *always*
> the case that you will sometimes make a mistake. That's not
> justification for paralysis, especially not when the existing code is
> demonstrably broken.
>
> What occurs to
On 05/24/2011 04:34 PM, Robert Haas wrote:
we could name this feature "partial full page writes" and enable it
either with a setting of full_page_writes=partial
+1 to overloading the initial name, but only if the parameter is named
'maybe', 'sometimes', or 'perhaps'.
I've been looking into a
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of mar may 24 15:59:59 -0400 2011:
>
> > > I think you misread what I wrote, or I misexplained it, but never
> > > mind. Matching locale names case-insensitively sounds reasonable to
> > > me, unless someone has reason to believe it wi
But somehow the execevalvar is being called. When i changed the logic of its
working to use slot_getattr instead of cute_datum_array for the first run /
call, everything just worked!
This would indicate surely that the function does get called at least once
before being called by executor for qual
On 25.05.2011 20:11, Tom Lane wrote:
Heikki Linnakangas writes:
On 25.05.2011 17:47, Tom Lane wrote:
[ scratches head ... ] Why does the save/restore in ExecEvalCase not
take care of this?
The mistake happens during planning, when the SQL function is inlined
and pre-evaluated.
Hm. I'm i
On Wed, May 25, 2011 at 1:06 PM, Greg Smith wrote:
> On 05/24/2011 04:34 PM, Robert Haas wrote:
>>
>> we could name this feature "partial full page writes" and enable it
>> either with a setting of full_page_writes=partial
>
> +1 to overloading the initial name, but only if the parameter is named
On Wed, May 25, 2011 at 1:15 PM, Robert Haas wrote:
> I agree that if VACUUM scanned 99% of the table, it's probably fine to
> use its numbers. It's also fine to use the numbers from ANALYZE,
> because those pages are chosen randomly. What bothers me is the idea
> of using a small *non-random* s
2011/5/25 Alvaro Herrera :
> Excerpts from Kevin Grittner's message of mié may 25 12:37:24 -0400 2011:
>> Tom Lane wrote:
>>
>> > I don't know what client-side code might be looking at
>> > relpages/reltuples.
>>
>> I know that I find reltuples useful for getting an "accurate enough"
>> sense of r
On Wed, May 25, 2011 at 12:34 PM, Vaibhav Kaushal
wrote:
> But somehow the execevalvar is being called. When i changed the logic of its
> working to use slot_getattr instead of cute_datum_array for the first run /
> call, everything just worked!
This is what gdb is for... set a breakpoint on that
On Wed, May 25, 2011 at 1:22 PM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> Excerpts from Bruce Momjian's message of mar may 24 15:59:59 -0400 2011:
>>
>> > > I think you misread what I wrote, or I misexplained it, but never
>> > > mind. Matching locale names case-insensitively sounds reason
2011/5/26 Robert Haas :
> On Wed, May 25, 2011 at 10:35 AM, Hitoshi Harada wrote:
>> 2011/5/25 Hitoshi Harada :
>>> So I'm still
>>> thinking which of pulling up and parameterized scan is better.
>>
>> After more investigation I came up with third idea, pushing down
>> RangeTblEntry to aggregate s
Excerpts from Cédric Villemain's message of mié may 25 13:24:01 -0400 2011:
> > Well, we only actually need to store one number, because you can figure
> > out a much more precise number-of-pages figure with pg_relation_size()
> > divided by configured page size.
> I may miss something but we nee
On Mon, May 23, 2011 at 11:08:40PM -0400, Robert Haas wrote:
>
> I don't really like the idea of adding a GUC for this, unless we
> convince ourselves that nothing else is sensible. I mean, that leads
> to conversations like this:
>
> Newbie: My query is slow.
> Hacker: Turn on enable_magic_pixi
Excerpts from Robert Haas's message of mié may 25 13:33:41 -0400 2011:
> On Wed, May 25, 2011 at 1:22 PM, Bruce Momjian wrote:
> > I can easily remove dashes before the compare if people like that idea
> > --- I think you could argue that a dash is not significant, unless "ab-c"
> > and "a-bc" ar
Excerpts from Tom Lane's message of mar may 24 17:11:17 -0400 2011:
> Right. It would also increase the cognitive load on the user to have
> to remember the command-line go-to-line-number switch for his editor.
> So I don't particularly want to redesign this feature. However, I can
> see the pos
On Wed, May 25, 2011 at 1:37 PM, Hitoshi Harada wrote:
>> How do you decide whether or not to push down?
>
> Yeah, that's the problem. In addition to the conditions of join-qual
> == grouping key && outer is unique on qual, we need some criteria if
> it should be done. At first I started to think
On Wed, May 25, 2011 at 10:36 PM, Robert Haas wrote:
>
>> I don't see how you'd store
>> anything in the hole without it being in a fixed place, where it would
>> eventually be hit by either the line pointer array or tuple data.
>
> The point is that it doesn't matter. Suppose we put it just aft
On Tue, May 24, 2011 at 22:31, Jaime Casanova wrote:
> On Tue, May 24, 2011 at 8:52 PM, Fujii Masao wrote:
>
>> + primary_xlp_magic = atoi(PQgetvalue(res, 0, 2));
>>
>> You wrongly get the third field (i.e., current xlog location) as the
>> WAL version.
>> You should call PQgetvalue(res, 0,
On Wed, May 25, 2011 at 1:43 PM, Pavan Deolasee
wrote:
> I think the point is you can not *always* put it just after the line
> pointer array without possibly shuffling the tuples. Remember we need
> to put the LSN when the dead line pointer is generated because we
> decided to prune away the dead
Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of mi?? may 25 13:33:41 -0400 2011:
> > On Wed, May 25, 2011 at 1:22 PM, Bruce Momjian wrote:
>
> > > I can easily remove dashes before the compare if people like that idea
> > > --- I think you could argue that a dash is not significant
While I was working on automatic translation of PostgreSQL's
documentation from SGML to XML, I found some minor issues.
In the file doc/src/sgml/ecpg.sgml there are many lines of C code
containing unescaped '<' characters.
In the file doc/src/sgml/array.sgml there is a tag which has a case
mismat
I think the command 'where' does the same. And the command showed something
which looked like was part of evaluation...it got me confused. Anyways,
thanks robert. I will check that too. I did not know the 'bt' command.
--
Sent from my Android
On 25 May 2011 23:02, "Robert Haas" wrote:
On Wed, May 25, 2011 at 12:34:59PM +0100, Simon Riggs wrote:
> On Wed, May 25, 2011 at 6:16 AM, Heikki Linnakangas
> wrote:
>
> >> To achieve that, I'm thinking to change walsender so that, when the
> >> standby
> >> has caught up with the master, it sends back the message indicating that
> >> to
On Wed, May 25, 2011 at 2:13 PM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> Excerpts from Robert Haas's message of mié may 25 13:33:41 -0400 2011:
>> > On Wed, May 25, 2011 at 1:22 PM, Bruce Momjian wrote:
>>
>> > > I can easily remove dashes before the compare if people like that idea
>> >
On Wed, May 25, 2011 at 3:41 PM, Simon Riggs wrote:
> On Wed, May 25, 2011 at 2:43 PM, Leonardo Francalanci
> wrote:
>>> Da: Simon Riggs
>>> I can't find a clear discussion of what you are trying to do, and how,
>>> just a URL back to a complex discussion on another topic.
>>
>>
>> While tryi
On Wed, May 25, 2011 at 10:41 AM, Simon Riggs wrote:
> OK, thats clear. Thanks.
>
> That formatting sounds quite complex.
>
> I would propose we split this into 2 WAL records: xl_xact_commit and
> xl_xact_commit_with_info
>
> xl_xact_commit doesn't have any flags, counts or arrays.
>
> xl_xact_com
2011/5/25 Alvaro Herrera :
> Excerpts from Cédric Villemain's message of mié may 25 13:24:01 -0400 2011:
>
>> > Well, we only actually need to store one number, because you can figure
>> > out a much more precise number-of-pages figure with pg_relation_size()
>> > divided by configured page size.
>
On ons, 2011-04-27 at 18:14 -0400, Noah Misch wrote:
> Enthusiastic +1 for this concept. There's at least one rough edge: it fails
> if
> you have another postmaster running on port 5432.
This has now been addressed: pg_upgrade accepts PGPORT settings.
Attached is a slightly updated patch runs t
On Wed, May 25, 2011 at 3:05 PM, Simon Riggs wrote:
> On Wed, May 25, 2011 at 3:41 PM, Simon Riggs wrote:
>> On Wed, May 25, 2011 at 2:43 PM, Leonardo Francalanci
>> wrote:
Da: Simon Riggs
I can't find a clear discussion of what you are trying to do, and how,
just a URL back to
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mar may 24 17:11:17 -0400 2011:
>> Right. It would also increase the cognitive load on the user to have
>> to remember the command-line go-to-line-number switch for his editor.
>> So I don't particularly want to redesign this feature.
Robert Haas writes:
> I think getting it working is probably a good first goal. I am not
> really sure that we want to commit it that way, and I think my vote
> would be for you to work on the approach we discussed before rather
> than this one, but it's your project, and I think you'll probably
Robert Haas writes:
> On Wed, May 25, 2011 at 2:13 PM, Bruce Momjian wrote:
>> I thought the problem was that they upgraded the OS and now the encoding
>> names changed, though they behaved the same. Is that now what is
>> happening? Can they supply the values with different cases?
> Oh, hmm.
Heikki Linnakangas writes:
> On 25.05.2011 17:47, Tom Lane wrote:
>> [ scratches head ... ] Why does the save/restore in ExecEvalCase not
>> take care of this?
> The mistake happens during planning, when the SQL function is inlined
> and pre-evaluated.
OK, I see the problem now: we have a Case
Tom Lane wrote:
> Robert Haas writes:
> > On Wed, May 25, 2011 at 2:13 PM, Bruce Momjian wrote:
> >> I thought the problem was that they upgraded the OS and now the encoding
> >> names changed, though they behaved the same. ?Is that now what is
> >> happening? ?Can they supply the values with dif
Robert Haas writes:
> On Wed, May 25, 2011 at 1:04 PM, Tom Lane wrote:
>> Because the problem is not specific to TOAST tables. As things
>> currently stand, we will accept the word of an ANALYZE as gospel even if
>> it scanned 1% of the table, and completely ignore the results from a
>> VACUUM e
> I thought the problem was that they upgraded the OS and now the encoding
> names changed, though they behaved the same. Is that now what is
> happening? Can they supply the values with different cases?
>
In my case I never touched the locale. It was set by the OS. I presume
this is true for m
1 - 100 of 114 matches
Mail list logo
