On Thu, Jun 10, 2010 at 11:56 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki
>> wrote:
>>> I found a term "InvalidXLogRecPtr" in 9.0 docs.
>>> http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE
>>> | .
On 10/06/10 06:47, Mark Wong wrote:
I wanted to propose a fix for to xlog.c regarding the use of
posix_fadvise() for 9.1 (unless someone feels it's ok for 9.0).
Currently posix_fadvise() is used right before a log file is closed so
it's effectively not doing anything, when posix_fadvise is to be
On Thu, Jun 10, 2010 at 12:09 AM, Heikki Linnakangas
wrote:
> Ok, committed with some cosmetic changes.
Thanks!
> BTW, should there be doc changes for this? I didn't find anything explaining
> how restartpoints are triggered, we should add a paragraph somewhere.
+1
What about the attached patc
Hi all,
I wanted to propose a fix for to xlog.c regarding the use of
posix_fadvise() for 9.1 (unless someone feels it's ok for 9.0).
Currently posix_fadvise() is used right before a log file is closed so
it's effectively not doing anything, when posix_fadvise is to be
called. This patch moves the
On Tue, Jun 08, 2010 at 04:18:08PM -0400, Robert Haas wrote:
> On Wed, May 26, 2010 at 11:24 PM, Joshua Tolley wrote:
> > On Wed, May 26, 2010 at 03:47:25PM -0400, Robert Haas wrote:
> >> On Tue, May 25, 2010 at 4:34 AM, Jonathan Leto wrote:
> >> > This tiny doc patch adds _PG_init to the skeleto
Robert Haas writes:
> On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki
> wrote:
>> I found a term "InvalidXLogRecPtr" in 9.0 docs.
>> http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE
>> | ... then the return value will be InvalidXLogRecPtr (0/0).
Josh Berkus writes:
> It appears that the ts parser will ignore any punctuation surrounding
> the special value calls.
The datetime parser ignores "extraneous" punctuation all over the place,
not only with regards to special values. I'm hesitant to monkey with
that, because there are so many wei
On 10/06/10 14:07, Tatsuo Ishii wrote:
The one of top 3 questions I got
when we propose them our HA solution is, "how long will it take to
do failover when the master DB crashes?"
Same here +1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Robert Haas writes:
> On Wed, Jun 9, 2010 at 5:02 PM, Robert Haas wrote:
>> I believe that the comment code is probably right, because I think
>> IConst can only handle values < 2^31, whereas OIDs can be as large as
>> 2^32-1.
> I investigated this a little more and the above analysis turns out
> The fact that failover current does *not* terminate existing queries and
> transactions was regarded as a feature by the audience, rather than a
> bug, when I did demos of HS/SR. Of course, they might not have been
> thinking of the delay for writes.
Probably you would hear different respose fr
On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki
wrote:
> I found a term "InvalidXLogRecPtr" in 9.0 docs.
> http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE
> | ... then the return value will be InvalidXLogRecPtr (0/0).
>
> I think it should not ap
Excerpts from David Gardner's message of mié jun 09 20:55:36 -0400 2010:
> In 8.4.4 I used to be able to rename input parameters via "create or
> replace function".
> In 9.0 beta2 this no longer is allowed, and I get a descriptive message
> informing me to use
> drop function instead, but I coul
I found a term "InvalidXLogRecPtr" in 9.0 docs.
http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE
| ... then the return value will be InvalidXLogRecPtr (0/0).
I think it should not appear in docs because it's a name for an internal
constant variabl
On Wed, Jun 9, 2010 at 8:55 PM, David Gardner wrote:
> In 8.4.4 I used to be able to rename input parameters via "create or replace
> function".
> In 9.0 beta2 this no longer is allowed, and I get a descriptive message
> informing me to use
> drop function instead, but I couldn't find this docume
Excerpts from Robert Haas's message of mar jun 08 17:01:28 -0400 2010:
> I think only one of them has
> an actual patch associated with it, viz:
>
> ALTER TABLE .. DISABLE/ENABLE TRIGGER are out of date
>
> I took a look at that patch, and I expect it's probably correct, but I
> haven't actually
In 8.4.4 I used to be able to rename input parameters via "create or
replace function".
In 9.0 beta2 this no longer is allowed, and I get a descriptive message
informing me to use
drop function instead, but I couldn't find this documented anywhere as a
change between 8.4 and 9.0.
-
Fujii Masao wrote:
> > 1. Reset max_standby_delay = 0 in postgresql.conf
> > 2. pg_ctl reload
> > 3. Create a trigger file
>
> As far as I read the HS code, SIGHUP is not checked while a recovery
> is waiting for queries :( So pg_ctl reload would have no effect on
> the conflicting queries.
>
On Wed, Jun 9, 2010 at 5:02 PM, Robert Haas wrote:
> I believe that the comment code is probably right, because I think
> IConst can only handle values < 2^31, whereas OIDs can be as large as
> 2^32-1.
I investigated this a little more and the above analysis turns out to
be correct. ALTER LARGE
gram.y treats large object identifiers inconsistently. The privileges
stuff treats them as IConst:
| LARGE_P OBJECT_P Iconst_list
{
PrivTarget *n = (PrivTarget *) palloc(sizeof(PrivTarget));
n->targtype = ACL_TARGET_OBJECT;
On Wed, 2010-06-09 at 11:34 +0100, Greg Stark wrote:
> On Wed, Jun 9, 2010 at 7:27 AM, Simon Riggs wrote:
> ...
> > Absence of evidence is not evidence of absence.
> ...
> > A lack of bugs usually indicates there are no bugs in the areas being
> > tested.
>
> Would the real Simon Riggs please spe
select 'NOW?'::TIMESTAMP;
timestamp
2010-06-09 14:08:21.020259
postgres=# select ';;;infinity?...@$%$'::TIMESTAMP;
timestamp
---
infinity
(1 row)
It appears that the ts parser will ignore any punctuation surrounding
the special value calls.
In ge
On Wed, 2010-06-09 at 12:22 -0700, Josh Berkus wrote:
> > To fix the problem, when the trigger file is found, I think
> > that we should cancel all the running read only queries
> > immediately (or forcibly use -1 as the max_standby_delay
> > since that point) and make the recovery go ahead. If som
On Wed, Jun 9, 2010 at 12:09 PM, Tom Lane wrote:
>> If you
>> freeze all tuples by the time the pages are marked all-visible,
>> perhaps via the xmin-preserving mechanism Simon suggested, then you
>> can use the visibility map to skip anti-wraparound vacuum as well as
>> regular vacuum. That soun
marcin mank writes:
> Could a tuple wih the bit set be considered frozen already? Would we
> actually ever need to rewrite the xmin, even for anti-wraparound
> reasons?
That's exactly what Simon is suggesting: if we had a tuple status flag
with the semantics of "this xmin is known visible to all
On Thu, 2010-06-03 at 19:02 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Thu, 2010-06-03 at 18:18 +0100, Simon Riggs wrote:
> >> Are you planning to work on these things now as you said?
>
> > Are you? Or do you want me to?
>
> I decided there wasn't time to get anything useful done on it
Simon Riggs writes:
> On Thu, 2010-06-03 at 19:02 -0400, Tom Lane wrote:
>> I decided there wasn't time to get anything useful done on it before the
>> beta2 deadline (which is, more or less, right now). I will take another
>> look over the next few days.
> We all really need you to fix up max_s
I wrote:
> [ thinks for awhile... ] I wonder whether there is any way of locking
> down pg_get_expr so that it throws an error if called with anything
> except a suitable field from one of the system catalogs.
I did a bit of research into this idea. It looks at least somewhat
feasible:
* All PG
On Tue, 2010-06-08 at 17:24 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > Well, yes. But then to stop that you could just lock users out using
> > pg_hba.conf, no? It just doesn't seem to be buying all that much to me.
>
> The main reason to turn it off is to disable a whole lot of very p
Robert Haas writes:
> On Wed, Jun 9, 2010 at 2:04 PM, Tom Lane wrote:
>> Well, ideally yes, but if it's not actually *secure* then there's no
>> point --- and I don't believe that the approach of making readfuncs.c
>> secure against malicious input has the proverbial snowball's chance
>> of ever
On Wed, Jun 9, 2010 at 2:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 9, 2010 at 1:34 PM, Tom Lane wrote:
>>> Yes, it's not a trivial fix either. We'll have to provide functions or
>>> views that replace the current usages without letting the user insert
>>> untrusted strings.
>
On Tue, 2010-06-08 at 18:30 -0400, Andrew Dunstan wrote:
> I prefer archive_cleanup_command. We should name things after their
> principal function, not an implementation detail, IMNSHO.
>
> More importantly, we should include an example in the docs. I created
> one the other day when this was
On Wed, Jun 9, 2010 at 3:22 PM, Josh Berkus wrote:
>
>> To fix the problem, when the trigger file is found, I think
>> that we should cancel all the running read only queries
>> immediately (or forcibly use -1 as the max_standby_delay
>> since that point) and make the recovery go ahead. If some
>>
> To fix the problem, when the trigger file is found, I think
> that we should cancel all the running read only queries
> immediately (or forcibly use -1 as the max_standby_delay
> since that point) and make the recovery go ahead. If some
> people prefer queries over failover even when they create
On Wed, 2010-06-09 at 11:18 +0900, Takahiro Itagaki wrote:
> Robert Haas wrote:
> > I think we're replacing restartpoint_command, not recovery_end_command.
>
> Ah, sorry. I did the same replacement for restartpoint_command
> in _, -, and camel case words.
>
> BTW, should we also have a release n
Josh Berkus writes:
> The fact that failover current does *not* terminate existing queries and
> transactions was regarded as a feature by the audience, rather than a
> bug, when I did demos of HS/SR. Of course, they might not have been
> thinking of the delay for writes.
> If there were an easy
On Thu, Jun 3, 2010 at 8:44 PM, Takahiro Itagaki
wrote:
> Ther is an open item:
> Standby instead of "slave" in documentation
> http://archives.postgresql.org/message-id/1273682033.12754.1.ca...@vanquo.pezone.net
>
> I replacesd almost all "slave" to "standby" or "standby servers"
> not only in HS
On Wed, Jun 9, 2010 at 1:15 PM, David E. Wheeler wrote:
> On Jun 9, 2010, at 10:04 AM, Tom Lane wrote:
>
>>> I actually like :> pretty well. It looks more like =>, and has nice
>>> correspondence to := for named function params.
>>
>> Colon was removed from the set of allowed operator-name charac
On Sun, May 30, 2010 at 6:58 PM, Andrew Dunstan wrote:
> Tim Bunce wrote:
>> p.s. It also turned to be insufficiently useful for NYTProf since it
>> doesn't also update some internals to record the 'filename' and line
>> number range of the sub. So PostgreSQL::PLPerl::NYTProf works around
>> that
> "Tom" == Tom Lane writes:
>> While I don't like the inconsistency between ==> or whatever and
>> the use of => in type input and output, I regard the text
>> representation as being much harder to change safely, since client
>> code will be parsing it. In this case the inconsistency see
Hi,
thanks so far.
However, if I attach a Debugger (which I did in advance, too) and I use
explain, I get the same results.
My first guess in each case is always that it is my fault. However, I don't
know exactly, why this strange behaviour occurs here. The problem I have is
that EXPLAIN, too, a
Robert Haas writes:
> On Wed, Jun 9, 2010 at 1:34 PM, Tom Lane wrote:
>> Yes, it's not a trivial fix either. We'll have to provide functions or
>> views that replace the current usages without letting the user insert
>> untrusted strings.
> Maybe I'm all wet here, but don't we need to come up w
Excerpts from Dean Rasheed's message of dom jun 06 05:11:02 -0400 2010:
> Hi,
>
> I just spotted that the docs for ALTER TABLE .. DISABLE/ENABLE TRIGGER
> are out of date, now that we have deferrable uniqueness and exclusion
> constraints.
applied, thanks
> Also, I think that the original commen
On Jun 9, 2010, at 10:33 AM, Robert Haas wrote:
> Well, that doesn't look much like an arrow, at least not to me...
It's a pointer, though. Not in the C sense, of course. But I often use » for
"read more" style links in HTML. Its the same idea: move from this to that.
Anyway, for comparison's p
On Wed, Jun 9, 2010 at 1:34 PM, Tom Lane wrote:
> Kris Jurka writes:
>> On Wed, 9 Jun 2010, Heikki Linnakangas wrote:
>>> Are you thinking we should retrict pg_get_expr() to superusers then?
>
>> That seems like it will cause problems for both pg_dump and drivers which
>> want to return metadata
Kris Jurka writes:
> On Wed, 9 Jun 2010, Heikki Linnakangas wrote:
>> Are you thinking we should retrict pg_get_expr() to superusers then?
> That seems like it will cause problems for both pg_dump and drivers which
> want to return metadata as pg_get_expr has been the recommended way of
> fetch
On Wed, Jun 9, 2010 at 1:15 PM, David E. Wheeler wrote:
> On Jun 9, 2010, at 10:04 AM, Tom Lane wrote:
>
>>> I actually like :> pretty well. It looks more like =>, and has nice
>>> correspondence to := for named function params.
>>
>> Colon was removed from the set of allowed operator-name charac
On Wed, Jun 9, 2010 at 11:57 AM, Greg Sabino Mullane wrote:
> The bug was only reported Monday morning, and you are yelling at me
> on a Tuesday night for not being willing to drop everything I'm doing
> and fix it right now?
I am not saying and have not said that you needed to drop everything
yo
On Wed, 9 Jun 2010, Heikki Linnakangas wrote:
Are you thinking we should retrict pg_get_expr() to superusers then?
That seems like it will cause problems for both pg_dump and drivers which
want to return metadata as pg_get_expr has been the recommended way of
fetching this information.
Robert Haas writes:
> Look at how the POSITION() pseudofunction is defined around gram.y
> line 9651. Essentially any special syntax of this type gets converted
> to a regular function call internally. So in your case I think there
> will be some function that gets called something ike this:
>
On Jun 9, 2010, at 10:04 AM, Tom Lane wrote:
>> I actually like :> pretty well. It looks more like =>, and has nice
>> correspondence to := for named function params.
>
> Colon was removed from the set of allowed operator-name characters years
> ago. There are conflicts with various usages (ecp
On Wed, Jun 9, 2010 at 4:35 AM, Carsten Kropf wrote:
> Hi *,
> during the last few months I've been building a new index structure as part
> of a research project.
> Everything seems to work properly, however I have some strange issues with
> the count sql command.
> I introduced some custom str
"David E. Wheeler" writes:
> I actually like :> pretty well. It looks more like =>, and has nice
> correspondence to := for named function params.
Colon was removed from the set of allowed operator-name characters years
ago. There are conflicts with various usages (ecpg & psql variables).
This
Hi,
Youre on the wrong list for this. This is not a -hackers (i.e. developer
targeted) but a -general (user targeted) question.
On Wednesday 09 June 2010 15:11:41 rupendra.chulya...@gmail.com wrote:
> I tried to store a BitString of length 2 million in a Postgres table (see
> code below), but i
On Wed, Jun 9, 2010 at 12:54 PM, David E. Wheeler wrote:
>> Perhaps it would be sane to make hstore_in accept either => or ==>, but
>> not change hstore_out (for now)?
>
> +1
Anyone want to take a crack at coding that? I took a brief look at
the code but it looked a bit intimidating at first gla
On Jun 9, 2010, at 9:30 AM, Tom Lane wrote:
> Andrew Gierth writes:
>> I'd really like to find a better operator name than ==>. But I'm not
>> convinced one exists.
>
> I agree.
+1
No one liked my suggestion of ~> ? Too similar to -> ? Other ideas:
'foo' :> 'bar'
'foo' @> 'bar'
'foo'
On Tue, 2010-06-08 at 18:35 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 2010-06-08 at 18:03 -0400, Robert Haas wrote:
> >> OK, yes, I see what you're getting at now. There are two possible
> >> ways to do freeze the tuples and keep the xmin: we can either rely on
> >> the PD_ALL_VISI
On Wed, Jun 9, 2010 at 12:35 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On Tue, 2010-06-08 at 18:03 -0400, Robert Haas wrote:
>>> OK, yes, I see what you're getting at now. There are two possible
>>> ways to do freeze the tuples and keep the xmin: we can either rely on
>>> the PD_ALL_VISIBLE p
Robert Haas writes:
> On Tue, Jun 8, 2010 at 6:35 PM, Tom Lane wrote:
>> But none of this accomplishes a damn thing towards the original goal,
>> which was to avoid an extra disk write associated with freezing (not
>> to mention an extra write for setting the transaction-committed hint
>> bit).
Hi,
I tried to store a BitString of length 2 million in a Postgres table (see
code below), but it did not complete even in 3 mins and then I cancelled
it. Surprisingly, it only took few seconds when BitString was of length
500K. Is there any restriction of length of BitString or am I missin
Andrew Gierth writes:
> I'd really like to find a better operator name than ==>. But I'm not
> convinced one exists.
I agree.
> While I don't like the inconsistency between ==> or whatever and the use
> of => in type input and output, I regard the text representation as being
> much harder to ch
> "Robert" == Robert Haas writes:
Robert> I don't think so, either. The most someone might want to do
Robert> is make ==> work wherever => does now, but I wouldn't want to
Robert> start monkeying with that without some input from Andrew
Robert> Gierth; and I don't think it's a stop-ship
Robert Haas writes:
> + if (!strcmp(oprName, "=>"))
BTW, project standard is to spell that like
> + if (strcmp(oprName, "=>") == 0)
The other way looks confusingly like a "not equal" test.
> + (errmsg("The use of => as an operator name is
> deprecated and m
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Robert Haas wrote:
>> When I get some free time, I'll make a patch to implement as
>> much of the spec as we sanely can.
> Saying that you'll fix it but not on any particular timetable is
> basically equivalent to saying that you're not willin
On 09/06/10 05:26, Fujii Masao wrote:
On Wed, Jun 2, 2010 at 10:24 PM, Fujii Masao wrote:
On Wed, Jun 2, 2010 at 8:40 PM, Heikki Linnakangas
wrote:
On 02/06/10 06:23, Fujii Masao wrote:
On Mon, May 31, 2010 at 7:17 PM, Fujii Masao
wrote:
4) Change it so that checkpoint_segments takes e
Heikki Linnakangas writes:
> On 09/06/10 17:34, Tom Lane wrote:
>> I think #1 is a fool's errand. There is far too much structure to a
>> node tree that is outside the scope of what readfuncs.c is capable of
>> understanding.
> That's why I said that ruleutils.c will need to understand and compl
Fujii Masao writes:
> When the trigger file is created while the recovery keeps
> waiting for the release of the lock by read only queries,
> it might take a very long time for the standby to become
> the master. The recovery cannot go ahead until those read
> only queries have gone away. This wou
On 09/06/10 17:34, Tom Lane wrote:
Heikki Linnakangas writes:
We have two options:
1. Make pg_get_expr() handle arbitrary (possibly even malicious) input
gracefully.
2. Restrict pg_get_expr() to superusers only.
I think #1 is a fool's errand. There is far too much structure to a
node t
On 09/06/10 17:34, Tom Lane wrote:
Heikki Linnakangas writes:
We have two options:
1. Make pg_get_expr() handle arbitrary (possibly even malicious) input
gracefully.
2. Restrict pg_get_expr() to superusers only.
I think #1 is a fool's errand. There is far too much structure to a
node t
Heikki Linnakangas writes:
> We have two options:
> 1. Make pg_get_expr() handle arbitrary (possibly even malicious) input
> gracefully.
> 2. Restrict pg_get_expr() to superusers only.
I think #1 is a fool's errand. There is far too much structure to a
node tree that is outside the scope of w
On Wed, Jun 9, 2010 at 6:32 AM, Mike Fowler wrote:
> I've been working to improve the syntax of the XMLEXISTS function that I put
> a patch forward for and have been attempting to get my head around how you
> modify the grammar. I admit I'm not getting much anywhere probably as I
> don't know biso
On Wed, Jun 9, 2010 at 9:06 AM, Dimitri Fontaine wrote:
> Robert Haas writes:
>>> What about a WARNING at CREATE OPERATOR time?
>>
>> That's what the patch I sent already does.
>
> Great :)
> I read comments in the email instead of the commit…
>
>> I'm not following this part.
>
> I'm wondering i
Robert Haas writes:
>> What about a WARNING at CREATE OPERATOR time?
>
> That's what the patch I sent already does.
Great :)
I read comments in the email instead of the commit…
> I'm not following this part.
I'm wondering if deprecating => as an SQL operator, we should too
deprecate its usage i
> I've re-run git repack on
> it, please try again. At least that file is
> accessible from here
> now..
It worked, thank you very much
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
On Mon, Jun 7, 2010 at 8:30 PM, Takahiro Itagaki
wrote:
>
> Dave Cramer wrote:
>
>> I noted on line 169 that max_avail is still an int ? Where else would
>> it be having problems ?
>
> It should not a problem because the local variable only stores byte
> size in a page. It will be at most only BL
On 09/06/10 15:04, Kevin Grittner wrote:
Magnus Hagander wrote:
The way to provoke the problem is:
The way I ran into it was to have a web application which only ran
read-only transactions. Sooner or later it would need to write a
page from the buffer to make space to read a new page, and th
On Wed, Jun 9, 2010 at 14:04, Kevin Grittner
wrote:
> Magnus Hagander wrote:
>
>> I've just applied the attached file to the walwriter, to solve a
>> case when it keeps handles around to old xlog segments, preventing
>> them from actually being removed, and as such also causing alerts
>> in some
Magnus Hagander wrote:
> I've just applied the attached file to the walwriter, to solve a
> case when it keeps handles around to old xlog segments, preventing
> them from actually being removed, and as such also causing alerts
> in some monitoring systems.
Thanks! I wasted some time on these
On Wed, Jun 9, 2010 at 6:53 AM, Dimitri Fontaine wrote:
> Greg Stark writes:
>> On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas wrote:
>>> I believe that the consensus was mostly in favor of deprecating => as
>>> an operator name, with the intent to abolish it completely in a future
>>> release. At
I've just applied the attached file to the walwriter, to solve a case
when it keeps handles around to old xlog segments, preventing them
from actually being removed, and as such also causing alerts in some
monitoring systems. The way to provoke the problem is:
1. Do something that makes the walwri
Greg Stark writes:
> On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas wrote:
>> I believe that the consensus was mostly in favor of deprecating => as
>> an operator name, with the intent to abolish it completely in a future
>> release. Attached is a patch to implement ==> as an alternative
>> operato
On Wed, Jun 9, 2010 at 6:41 AM, Greg Stark wrote:
> On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas wrote:
>> I believe that the consensus was mostly in favor of deprecating => as
>> an operator name, with the intent to abolish it completely in a future
>> release. Attached is a patch to implement =
On Tue, Jun 8, 2010 at 8:07 PM, Robert Haas wrote:
> I believe that the consensus was mostly in favor of deprecating => as
> an operator name, with the intent to abolish it completely in a future
> release. Attached is a patch to implement ==> as an alternative
> operator name for hstore, and to
On Wed, Jun 9, 2010 at 7:27 AM, Simon Riggs wrote:
...
> Absence of evidence is not evidence of absence.
...
> A lack of bugs usually indicates there are no bugs in the areas being
> tested.
Would the real Simon Riggs please speak up? Isn't that precisely what
"absence of evidence is not evidence
Hi,
I've been working to improve the syntax of the XMLEXISTS function that I
put a patch forward for and have been attempting to get my head around
how you modify the grammar. I admit I'm not getting much anywhere
probably as I don't know bison but I'm starting to wonder if it's worth
the pai
On Wed, Jun 9, 2010 at 6:13 PM, Takahiro Itagaki
wrote:
>> To fix the problem, when the trigger file is found, I think
>> that we should cancel all the running read only queries
>> immediately (or forcibly use -1 as the max_standby_delay
>> since that point) and make the recovery go ahead.
>
> Hmm
On Wed, Jun 9, 2010 at 5:47 PM, Fujii Masao wrote:
> To fix the problem, when the trigger file is found, I think
> that we should cancel all the running read only queries
> immediately (or forcibly use -1 as the max_standby_delay
> since that point) and make the recovery go ahead.
Oops! I made an
Fujii Masao wrote:
> To fix the problem, when the trigger file is found, I think
> that we should cancel all the running read only queries
> immediately (or forcibly use -1 as the max_standby_delay
> since that point) and make the recovery go ahead.
Hmmm, does the following sequence work as you
> When the trigger file is created while the recovery keeps
> waiting for the release of the lock by read only queries,
> it might take a very long time for the standby to become
> the master. The recovery cannot go ahead until those read
> only queries have gone away. This would increase the downt
Hi,
When the trigger file is created while the recovery keeps
waiting for the release of the lock by read only queries,
it might take a very long time for the standby to become
the master. The recovery cannot go ahead until those read
only queries have gone away. This would increase the downtime
a
Hi *,
during the last few months I've been building a new index structure as part of
a research project.
Everything seems to work properly, however I have some strange issues with the
count sql command.
I introduced some custom structures (mainly document and hybrid_query) with
which my index ac
(moving to pgsql-hackers)
On 03/06/10 10:37, Heikki Linnakangas wrote:
However, I'm afraid we're lacking in input validation of read-funcs in
general. ...
>
Does anyone have an idea on how
to validate the input in a more wholesale fashion, so that we don't need
to plug these holes one by one?
On Tue, Jun 8, 2010 at 13:55, Leonardo F wrote:
> Hi,
>
>
> I tried getting the source using:
>
> git clone http://git.postgresql.org/git/postgresql.git postgresql-git
>
> but after a while (252MB) I always get:
>
> [...]
> Getting pack 61e1395a5bdacda95de5432123a0f8124fff05e6
> which contains 476
On Jun 8, 2010, at 12:12 , P. Caillaud wrote:
> I'd like to experiment on compiling postgres with LLVM (either llvm-gcc or
> clang) on Linux, is it supported ? Where should I start ?
Setting the environment variables CC and perhabs LD to your favorite compile
before running ./configure should do
2010/6/8 Tom Lane :
> Pavel Stehule writes:
>> p.s. I hope so in 9.1 will be complete hstore module marked as deprecated
>
> Really? And replaced with what? And why wouldn't the replacement use
> the same operator names?
>
We talked about integrated hash tables support.
regards
Pavel
>
94 matches
Mail list logo
