On Mon, Feb 08, 2010 at 08:20:04PM -0500, Tom Lane wrote:
> > MSVC builds are broken from a missing _isnan function on the ECPG tests.
> > Do we need to link in a math lib or something there?
>
> It looks to me like the problem is that that test is being compiled
> without benefit of any platform
On Tue, Feb 9, 2010 at 9:39 AM, Michael Meskes wrote:
> Actually I was hoping someone with some Windows experience would take a look
> at
> it or Zoltan would come up with a fix, after all it was his addition. :-)
>
> Looking at the portability header file it appears that isnan/isinf are only
>
On Tuesday, February 9, 2010, Dave Page wrote:
> On Tue, Feb 9, 2010 at 9:39 AM, Michael Meskes wrote:
>> Actually I was hoping someone with some Windows experience would take a look
>> at
>> it or Zoltan would come up with a fix, after all it was his addition. :-)
>>
>> Looking at the portabili
Michael Meskes írta:
> On Mon, Feb 08, 2010 at 08:20:04PM -0500, Tom Lane wrote:
>
>>> MSVC builds are broken from a missing _isnan function on the ECPG tests.
>>> Do we need to link in a math lib or something there?
>>>
>> It looks to me like the problem is that that test is being compi
Not even a comment? As I said, performance results on my system
were very good
> I know you're all very busy getting 9.0 out, but I think the results in
> heap scanning + sort instead of index scanning for CLUSTER are
> very good... I would like to know if I did something wrong/I should
> impr
KaiGai Kohei wrote:
> > I don't think this is necessarily a good idea. We might decide to treat
> > both things separately in the future and it having them represented
> > separately in the dump would prove useful.
>
> I agree. From design perspective, the single section approach is more
> sim
I've been discussing this with Josh, Heikki, and Peter E. over the past
few weeks.
As Peter observed years ago, prepared statements can perform badly
because their plans are overly generic. Also, statistics change and
sometimes plans should change with them. It would be nice if we could
avo
(2010/02/09 20:16), Takahiro Itagaki wrote:
KaiGai Kohei wrote:
I don't think this is necessarily a good idea. We might decide to treat
both things separately in the future and it having them represented
separately in the dump would prove useful.
I agree. From design perspective, the singl
> For the regression test, I am inclined to just do
>
> #ifdef WIN32
> #define isnan(x) _isnan(x)
> #define isinf(x) _isinf(x)
> #endif
Well the isinf() macro is different in win32.h. I did make a change and
apparently red_bat is now green again. Hopefully that was it.
Michael
--
Michael Me
On Tue, Feb 9, 2010 at 02:20, Tom Lane wrote:
> Andrew Dunstan writes:
>> Mingw builds are missing in6addr_any in backend/libpq/auth.c, added by a
>> recent RADIUS support fix. Looks like we might need to include win32.h
>> in there.
>
> That was discussed already. I assume Magnus is going to ad
(please Cc me on replies, I am not subscribed)
Hi,
libpq currently does not use TCP keepalives. This is a problem in our
case where we have some clients waiting for notifies and then the
connection is dropped on the server side. The client never gets the FIN
and thinks the connection is up. T
On Tue, Feb 9, 2010 at 14:03, Tollef Fog Heen
wrote:
>
> (please Cc me on replies, I am not subscribed)
>
> Hi,
>
> libpq currently does not use TCP keepalives. This is a problem in our
> case where we have some clients waiting for notifies and then the
> connection is dropped on the server side.
Yeb Havinga wrote:
I've been discussing this with Josh, Heikki, and Peter E. over the
past few weeks.
Is this searchable in the archives? I'm interested in ideas discussed.
No, sorry. These were face-to-face discussions at linux.conf.au and FOSDEM.
If a prepared statement takes parameters,
On 09/02/10 12:08, Jeroen Vermeulen wrote:
= Projected-cost threshold =
[snip - this is the simple bit. Sounds very sensible. ]
= Actual-cost threshold =
Also stop using the generic plan if the statement takes a long time to
run in practice.
Do you mean:
1. Rollback the current query and
Jeroen Vermeulen wrote:
I've been discussing this with Josh, Heikki, and Peter E. over the
past few weeks.
Is this searchable in the archives? I'm interested in ideas discussed.
If a prepared statement takes parameters, and the generic plan has a
high projected cost, re-plan each EXECUTE indivi
Robert Haas escribió:
> On Mon, Feb 8, 2010 at 3:05 PM, Alvaro Herrera
> wrote:
> > How do we now that it works?
>
> Visual inspection? It's not very complicated.
Well, that works if you assume the trivial/usual malloc/free coding
style, but it fails in the hypothetical scenario I described ea
First of all let me say that from such incredible hackers as the
PostgreSQL people I'd have expected the ability to find my email address
and maybe keep me or (even better) the psycopg mailing list in CC. That
would have avoided a lot of confusion both on the license and the status
of psycopg2. If
On Tuesday 09 February 2010 13:08:54 Jeroen Vermeulen wrote:
> I've been discussing this with Josh, Heikki, and Peter E. over the past
> few weeks.
>
> As Peter observed years ago, prepared statements can perform badly
> because their plans are overly generic. Also, statistics change and
> someti
]] Magnus Hagander
| Seems reasonable to add this. Are there any scenarios where this can
| cause trouble, that would be fixed by having the ability to select
| non-standard behavior?
Well, it might be unwanted if you're on a pay-per-bit connection such as
3G, but in this case, it just makes the
Good idea, implemented.
Hmm. I think your implementation is prone to overflow in two places -
both when computing step, and also when stepping through the array.
Pls, point me, I don't see that
! step |= (step >> 1);
! step |= (step >> 2);
! step |= (step >> 4);
! s
On Tue, Feb 9, 2010 at 1:56 PM, Federico Di Gregorio wrote:
> Btw, I was
> at FOSDEM as probably other PostgreSQL people were and all this could
> have been discussed while drinking a couple of beers if only someone
> cared to contact me.
Hmm, I resent that. As one of the people at FOSDEM a) I ha
Richard Huxton wrote:
= Actual-cost threshold =
Also stop using the generic plan if the statement takes a long time to
run in practice.
Do you mean:
1. Rollback the current query and start again
2. Mark the plan as a bad one and plan again next execute
If you can figure out how to do #1 then
On 09/02/2010 15:22, Dave Page wrote:
> On Tue, Feb 9, 2010 at 1:56 PM, Federico Di Gregorio wrote:
>> Btw, I was
>> at FOSDEM as probably other PostgreSQL people were and all this could
>> have been discussed while drinking a couple of beers if only someone
>> cared to contact me.
>
> Hmm, I res
Andres Freund wrote:
= Actual-cost threshold =
Also stop using the generic plan if the statement takes a long time to
run in practice. Statistics may have gone bad. It could also be a
one-off due to a load peak or something, but that's handled by:
That is not that easy. It means that you ha
Tollef Fog Heen wrote:
(please Cc me on replies, I am not subscribed)
Hi,
libpq currently does not use TCP keepalives. This is a problem in our
case where we have some clients waiting for notifies and then the
connection is dropped on the server side. The client never gets the FIN
and thinks
On Tue, Feb 9, 2010 at 15:28, Federico Di Gregorio wrote:
> On 09/02/2010 15:22, Dave Page wrote:
>> On Tue, Feb 9, 2010 at 1:56 PM, Federico Di Gregorio wrote:
>>> Btw, I was
>>> at FOSDEM as probably other PostgreSQL people were and all this could
>>> have been discussed while drinking a couple
On 09/02/10 14:25, Jeroen Vermeulen wrote:
Richard Huxton wrote:
= Actual-cost threshold =
Also stop using the generic plan if the statement takes a long time to
run in practice.
Do you mean:
1. Rollback the current query and start again
2. Mark the plan as a bad one and plan again next exec
On 02/09/2010 08:46 AM, Jeroen Vermeulen wrote:
This sounds like a really nice to have feature. Maybe it'd also be
possible to skip replanning between executes if the current bound
values are 'indexwise-equivalent' to the values used at previous
planning, i.e. nothing in the statistics indicate
On Tue, Feb 9, 2010 at 13:52, Magnus Hagander wrote:
> On Tue, Feb 9, 2010 at 02:20, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Mingw builds are missing in6addr_any in backend/libpq/auth.c, added by a
>>> recent RADIUS support fix. Looks like we might need to include win32.h
>>> in there.
>>
[Resending; I accidentally failed to copy the list.]
Federico Di Gregorio wrote:
> the logical choice is plain LGPL3. I am open to motivated
> suggestions about other licenses but I'll ignore such crap as "BSD
> is more open than LGPL".
Well, I don't know about "more open", but I find the Pos
On Mon, Feb 8, 2010 at 6:07 PM, David E. Wheeler wrote:
> On Feb 8, 2010, at 5:15 AM, Magnus Hagander wrote:
>
>> The text is about 180Kb. PostgreSQL takes ~40 seconds without the
>> patch, ~36 seconds with it, to extract the match from it. Perl takes
>> 0.016 seconds.
>
> Obviously we need to sup
Hello,
I am returning back to message
http://archives.postgresql.org/pgsql-general/2010-02/msg00119.php
Our implementation of variadic parameters missing correct handling
test on NULL, and test on non constant value.
This patch add correct tests for variadic parameters. Probably
Gen_fmgrtab.pl h
Magnus Hagander writes:
> Here's a patch that "fixes" this. I put it locally for the radius
> authentication for now, since we don't use this anywhere else. Should
> we put this in /port/ somewhere, or is this good for now?
How about dropping it in src/backend/port/win32/mingwcompat.c ?
The adva
Pavel Stehule writes:
> + /*
> + * If function has variadic argument, skip calling
> + * when variadic array contains NULL values.
> + */
I don't think this is right at all. The strict check ought to apply to
the array argument as a whole.
On Tue, Feb 9, 2010 at 17:11, Tom Lane wrote:
> Magnus Hagander writes:
>> Here's a patch that "fixes" this. I put it locally for the radius
>> authentication for now, since we don't use this anywhere else. Should
>> we put this in /port/ somewhere, or is this good for now?
>
> How about dropping
On Tue, Feb 9, 2010 at 5:49 AM, Leonardo F wrote:
> Not even a comment? As I said, performance results on my system
> were very good
>
Hi Leonardo,
Perhaps you could supply a .sql file containing a testcase illustrating the
performance benefits you tested with your patch -- as I understand,
On Tue, Feb 9, 2010 at 7:08 AM, Jeroen Vermeulen wrote:
> = Projected-cost threshold =
>
> If a prepared statement takes parameters, and the generic plan has a high
> projected cost, re-plan each EXECUTE individually with all its parameter
> values bound. It may or may not help, but unless the pl
2010/2/9 Tom Lane :
> Pavel Stehule writes:
>> + /*
>> + * If function has variadic argument, skip calling
>> + * when variadic array contains NULL values.
>> + */
>
> I don't think this is right at all. The strict check ought to apply to
> the a
Thom Brown wrote:
> On 9 February 2010 01:57, Fujii Masao wrote:
>> The attached patch changes the layout according to your suggestion
>> (but with a small modification). Here is the new layout:
>>
>> ---
>> Chapter 24. Backup and Restore
>> 24.1. SQL Dump
>>24.1.1.
On Mon, 8 Feb 2010, Tom Lane wrote:
Robert Haas writes:
On Mon, Feb 8, 2010 at 3:05 PM, Alvaro Herrera
wrote:
It seems a bit strange to have all the rb_free_recursive support and not
use it anywhere ... and a freefunc callback even, whose only caller
seems to set as null currently. ═Hmm, eve
Robert Haas writes:
> On Tue, Feb 9, 2010 at 7:08 AM, Jeroen Vermeulen wrote:
>> Periodically re-plan prepared statements on EXECUTE. This is also a chance
>> for queries that were being re-planned every time to go back to a generic
>> plan.
> The most common problem here seems to be that (some
kevina...@hotmail.com (Kevin Ar18) writes:
> Of course all of this is from the perspective of Python users. Of
> course, you have your own features that you want from your end (from
> PostgreSQL's perspective). Perhaps this info would help you to know
> which avenue to pursue.
No, those seem lik
Pavel Stehule writes:
> 2010/2/9 Tom Lane :
>> I don't think this is right at all.
> yes, this isn't clear. My arguments for change:
> a) the behave depends on types - "any" is different than others.
So what? "variadic any" is different in a lot of ways.
> b) optimization over fmgr doesn't wo
2010/2/9 Tom Lane :
> Pavel Stehule writes:
>> 2010/2/9 Tom Lane :
>>> I don't think this is right at all.
>
>> yes, this isn't clear. My arguments for change:
>
>> a) the behave depends on types - "any" is different than others.
>
> So what? "variadic any" is different in a lot of ways.
>
imple
Pavel Stehule writes:
> 2010/2/9 Tom Lane :
>> So what? Â "variadic any" is different in a lot of ways.
> implementation is different, but from users perspective there can not
> be differences. I am not sure. From my programmer's view is all ok.
> But I believe so from customer view, there can be
2010/2/9 Tom Lane :
> Pavel Stehule writes:
>> 2010/2/9 Tom Lane :
>>> So what? "variadic any" is different in a lot of ways.
>
>> implementation is different, but from users perspective there can not
>> be differences. I am not sure. From my programmer's view is all ok.
>> But I believe so from
I was rather surprised to find this code still present:
/*
* We set up the lockRelId in case anything tries to lock the dummy
* relation. Note that this is fairly bogus since relNode may be
* different from the relation's OID. It shouldn't really matter
though
Seems inconsistent ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
> Seems inconsistent ...
Indeed. Seems like an oversight.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Seems inconsistent ...
> Indeed. Seems like an oversight.
OK, will fix since I'm fooling with that code anyway.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Tom Lane wrote:
>>> Seems inconsistent ...
>
>> Indeed. Seems like an oversight.
>
> OK, will fix since I'm fooling with that code anyway.
Thanks. While we're at it, the comment above visibilitymap_truncate()
has a copy-pasto in it (it claims the
I was recently experimenting with explain analyze and I realized there
are two things arguably wrong with the "Buffers" output in explain
analyze:
Firstly, it's printing out a number of buffers. We spent a lot of
effort making all GUC variables use units of memory like "kB" and "MB"
so the user sh
Tom Lane wrote:
> I was rather surprised to find this code still present:
>
> /*
>* We set up the lockRelId in case anything tries to lock the dummy
>* relation. Note that this is fairly bogus since relNode may be
>* different from the relation's OID. It shouldn't r
On 2010-02-08 18:42 +0200, Robert Haas wrote:
> On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
> wrote:
>> Here's an updated patch. Only changes from the previous patch are
>> fixing the above issue and a regression test for it.
>
> - I'm not sure that canSetTag is the right name for the additi
Heikki Linnakangas writes:
> I started looking at the callers of CreateFakeRelcacheEntry to see if
> any of them actually take a lock on the Relation. It seems not, so maybe
> we should just set those to InvalidOid, and add an
> Assert(OidIsValid(dbId) && OidIsValid(relId)) to LockAcquire() to ens
On 2/9/10 11:50 AM, Greg Stark wrote:
> Secondly, I think it's printing the total buffer usage for that node
> across the whole query -- not the average per iteration. I agree that
> the average is probably more confusing but it's what we do for every
> other stat. Do we want to be consistent? Call
Magnus Hagander wrote:
IIRC, we've had zero reports on whether the patch worked at all on 8.2
in an environment where the problem actually existed. So yes, some
testing and feedback would be much apprecaited.
//Magnus
Thanks for your quick reply.
We upgraded to Service Pack 2 and it solved
On Mon, 2010-02-08 at 22:13 -0800, Jeff Davis wrote:
> I would like to support encoded text, but I think there are other
> problems. For instance, what if one server has a client_encoding that
> doesn't support some of the glyphs being sent by the notifying backend?
> Then we have a mess, because w
Jeff Davis writes:
> Looking at the documentation, it appears that all of the server
> encodings represent 7-bit ascii characters using the same 7-bit ascii
> representation. Is that true?
Correct. We only support ASCII-superset encodings, both for frontend
and backend.
Limiting NOTIFY payloads
On Tue, Feb 9, 2010 at 3:26 PM, Josh Berkus wrote:
> On 2/9/10 11:50 AM, Greg Stark wrote:
>> Secondly, I think it's printing the total buffer usage for that node
>> across the whole query -- not the average per iteration. I agree that
>> the average is probably more confusing but it's what we do
Greg Stark writes:
> I already have a patch to do this but it's a bit grotty -- do we want
> to have a generic format string in snprintf in case we need it
> somewhere else other than explain.c?
No. Custom format specifiers that take arguments will confuse the heck
out of gcc's format-checking w
Boszormenyi Zoltan írta:
> Korry Douglas írta:
>
>>> I have the $SUBJECT problem loading my own
>>> module in PostgreSQL. The server is HP-UX/ia64,
>>> PostgeSQL 8.4.2 was compiled with HP CC.
>>> pl/PgSQL can be loaded fine.
>>>
>>> ...:/usr/local/pgsql/pgsql-cc-8.4/lib# ldd odbclink.so
>>>
Robert Haas writes:
> On Tue, Feb 9, 2010 at 3:26 PM, Josh Berkus wrote:
>> I'd prefer to have the average; it's very confusing to have an explain
>> row which has the cost per iteration, but the buffer usage per node.
> The cost per iteration thing is IMO one of the most confusing parts of
> th
Jeroen Vermeulen writes:
> I think we should be careful not to over-think this. Planning isn't *that*
> costly, so apply Amdahl's Law liberally. I'm proposing some easy things we
> could do without adding much overhead or maintenance burden; I've been
> assuming that getting intimate with the pl
On Tue, Feb 9, 2010 at 5:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 9, 2010 at 3:26 PM, Josh Berkus wrote:
>>> I'd prefer to have the average; it's very confusing to have an explain
>>> row which has the cost per iteration, but the buffer usage per node.
>
>> The cost per iterat
On Tue, Feb 9, 2010 at 4:51 PM, Tom Lane wrote:
> Jeff Davis writes:
>> Looking at the documentation, it appears that all of the server
>> encodings represent 7-bit ascii characters using the same 7-bit ascii
>> representation. Is that true?
>
> Correct. We only support ASCII-superset encodings,
Federico Di Gregorio wrote:
First of all let me say that from such incredible hackers as the
PostgreSQL people I'd have expected the ability to find my email address
and maybe keep me or (even better) the psycopg mailing list in CC. That
would have avoided a lot of confusion both on the license a
On Tue, Feb 9, 2010 at 3:13 PM, Marko Tiikkaja
wrote:
> On 2010-02-08 18:42 +0200, Robert Haas wrote:
>> On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
>> wrote:
>>> Here's an updated patch. Only changes from the previous patch are
>>> fixing the above issue and a regression test for it.
>>
>>
Robert Haas writes:
> On Tue, Feb 9, 2010 at 5:07 PM, Tom Lane wrote:
>> Well, if you want to put forward a proposal to get rid of that approach
>> entirely, go ahead. But it doesn't seem like a good idea to me for
>> EXPLAIN to print some numbers according to one viewpoint and some
>> according
On Tue, Feb 9, 2010 at 5:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 9, 2010 at 5:07 PM, Tom Lane wrote:
>>> Well, if you want to put forward a proposal to get rid of that approach
>>> entirely, go ahead. But it doesn't seem like a good idea to me for
>>> EXPLAIN to print some n
On 2010-02-08 21:30 +0200, I wrote:
> This doesn't exactly work anymore since we modify the snapshot after
> calling ExecInitScan(). I'm not really familiar with this part of the
> code, so I'm asking: is there a simple enough way around this? Would
> updating scan->rs_nblocks before scanning the
On Tue, 2010-02-09 at 16:51 -0500, Tom Lane wrote:
> Limiting NOTIFY payloads to 7-bit would definitely avoid the issue.
> The question is if that's more of a pain than a benefit.
I don't see any alternative. If one backend sends a NOTIFY payload that
contains a non-ASCII character, there's a risk
I just realized that log_error_verbosity is in the wrong section in
postgresql.conf and in our manual. It is listed under "When to log"
when in fact it should be in the "What to log" section.
I also added documentation of what "terse" mode actually does. I added
"verbosity" information a few wee
Robert Haas writes:
> On Tue, Feb 9, 2010 at 5:41 PM, Tom Lane wrote:
>> A more important point is that it would be a nontrivial change, both as
>> to code and documentation, and it's too late for such in 9.0. So what
>> we ought to be confining the discussion to right now is what 9.0 should
>>
On Tue, Feb 9, 2010 at 10:42 PM, Robert Haas wrote:
>> A more important point is that it would be a nontrivial change, both as
>> to code and documentation, and it's too late for such in 9.0. So what
>> we ought to be confining the discussion to right now is what 9.0 should
>> print here.
>
> It'
Jeff Davis wrote:
On Tue, 2010-02-09 at 16:51 -0500, Tom Lane wrote:
Limiting NOTIFY payloads to 7-bit would definitely avoid the issue.
The question is if that's more of a pain than a benefit.
I don't see any alternative. If one backend sends a NOTIFY payload that
Wouldn't binary payloads b
On Tue, Feb 9, 2010 at 6:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 9, 2010 at 5:41 PM, Tom Lane wrote:
>>> A more important point is that it would be a nontrivial change, both as
>>> to code and documentation, and it's too late for such in 9.0. So what
>>> we ought to be confi
Marko Tiikkaja writes:
> On 2010-02-08 21:30 +0200, I wrote:
>> This doesn't exactly work anymore since we modify the snapshot after
>> calling ExecInitScan(). I'm not really familiar with this part of the
>> code, so I'm asking: is there a simple enough way around this? Would
>> updating scan->
On 2010-02-10 02:19 +0200, Tom Lane wrote:
> Marko Tiikkaja writes:
>> Does this sound completely unacceptable?
>
> You still haven't explained why it's a good idea to change the snapshot
> after the executor has started. Right at the moment I'm prepared to
> reject the patch on that ground alon
On Tue, 2010-02-09 at 19:02 -0500, Andrew Chernow wrote:
> Wouldn't binary payloads be an alternative? NOTE: I may have missed this
> discussion. Sorry if it has already been covered.
The Notify struct has a "char *" field, which can't hold embedded NULL
bytes, so it can't really be binary. But
Robert Haas writes:
> On Tue, Feb 9, 2010 at 6:33 PM, Tom Lane wrote:
>> Not in the least. Fixing EXPLAIN to consistently print totals would
>> involve changes in (at least) the treatment of estimated costs, and very
>> possibly some changes in the Instrumentation support as well.
> As far as I
(2010/02/09 21:18), KaiGai Kohei wrote:
> (2010/02/09 20:16), Takahiro Itagaki wrote:
>>
>> KaiGai Kohei wrote:
>>
I don't think this is necessarily a good idea. We might decide to treat
both things separately in the future and it having them represented
separately in the dump would
On Tue, 9 Feb 2010, Mark Mielke wrote:
In a current commercial app we have that uses JDBC and prepared plans for
just about everything, it regularly ends up with execution times of 30+
milliseconds when a complete plan + execute would take less than 1
millisecond.
PostgreSQL planning is pr
On Wed, Feb 10, 2010 at 12:32 AM, Tom Lane wrote:
> The reason that EXPLAIN prints things the way it does is so that actual
> costs/times are comparable to estimated costs.
Oh, that was a thought I had along the way but forgot to mention in my
email: since the buffer usage isn't related to the co
Jeff Davis wrote:
Also, the query starts out as text, so we need a way to interpret the
text in an encoding-independent way.
So, I think ASCII is the natural choice here.
It's not worth hanging up this facility over this issue, ISTM. If we
want something more that ASCII then a base64 o
On Tue, Feb 9, 2010 at 11:34 PM, Andrew Chernow wrote:
> If you really want libpq to manage this, I think you need to expose the
> probe interval and timeouts.
Agreed.
Previously I was making the patch that exposes them as conninfo
options so that the standby can detect a network outage ASAP in
Greg Stark writes:
> On Wed, Feb 10, 2010 at 12:32 AM, Tom Lane wrote:
>> The reason that EXPLAIN prints things the way it does is so that actual
>> costs/times are comparable to estimated costs.
> Oh, that was a thought I had along the way but forgot to mention in my
> email: since the buffer u
Marko Tiikkaja writes:
> On 2010-02-10 02:19 +0200, Tom Lane wrote:
>> You still haven't explained why it's a good idea to change the snapshot
>> after the executor has started. Right at the moment I'm prepared to
>> reject the patch on that ground alone.
> The patch only touches the snapshot's
Andrew Dunstan writes:
> Jeff Davis wrote:
>> So, I think ASCII is the natural choice here.
> It's not worth hanging up this facility over this issue, ISTM. If we
> want something more that ASCII then a base64 or hex encoded string could
> possibly meet the need in the first instance.
Yeah, th
Tom Lane wrote:
Andrew Dunstan writes:
Jeff Davis wrote:
So, I think ASCII is the natural choice here.
It's not worth hanging up this facility over this issue, ISTM. If we
want something more that ASCII then a base64 or hex encoded string could
possibly meet the need in
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> >Andrew Dunstan writes:
> >>Jeff Davis wrote:
> >>>So, I think ASCII is the natural choice here.
> >
> >>It's not worth hanging up this facility over this issue, ISTM.
> >>If we want something more that ASCII then a base64 or hex
> >>encoded string c
Alvaro Herrera writes:
> Andrew Dunstan wrote:
>> True. It's a workaround, but I think it's acceptable at this stage.
>> We need to get some experience with this facility before we can
>> refine it.
> Hmm? If we decide now that it's not going to have encoding conversion,
> we won't able to chang
Bruce Momjian wrote:
> Where are we on this patch? We should at least implement the completion
> for 'LANGUAGE' in 'DO', and use the existing pg_language query for
> completion. I am attaching a patch that does exactly this.
I don't think we need the patch except adding DO to the top-level sq
We've added some new syntax in HEAD, but psql tab-completion is out of sync.
Here is a patch to support the following syntax in tab-completion:
- top-level DO
- ALTER TABLE/INDEX/TABLESPACE SET/RESET with options
- ALTER TABLE ALTER COLUMN SET/RESET with options
- CREATE TRIGGER wi
KaiGai Kohei wrote:
> The attached patch fixed up the cleanup query as follows:
> + appendPQExpBuffer(dquery,
> + "SELECT pg_catalog.lo_unlink(oid) "
> + "FROM pg_catalog.pg_largeobject_metadata "
> + "WHERE oid = %s;\n", binfo->dobj.
Hi Andrew and all,
I am still struggling with the branch repositories. I tried to checkout from
branch repositories but got error no such repositories:
$ cvs -z3 -d
:pserver:anoncvs:passw...@anoncvs.postgresql.org:/projects/REL8_4_STABLE
co -P pgsql
/projects/REL8_4_STABLE: no such repository
We have an optimization to bulkload date in pg_restore, but the code
only works in parallel restore (--jobs >= 2). Why don't we do the
same optimization in the serial restore (--jobs = 1) ?
We checks is_parallel to decide to use BEGIN-TRUNCATE-COPY:
if (is_parallel && te->created)
but we can a
Final, I tried:
$ cvs -z3 -d :pserver:anoncvs:passw...@anoncvs.postgresql.org:/projects/cvsroot
co -r REL8_3_STABLE -P pgsql
Checked file configure.in. Around line 20, there is line:
AC_INIT([PostgreSQL], [8.3.9], [pgsql-b...@postgresql.org])
Not sure that indicates version 8.3.9?
But still, i
On Tue, Feb 9, 2010 at 8:18 PM, Tom Lane wrote:
>> Perhaps instead of looking to change the "actual" times we should look
>> at a way to include total time spent in each node.
>
> You can already get that by multiplying the displayed total time by the
> number of loops. Robert does have a point t
On Tue, Feb 9, 2010 at 10:35 PM, M Z wrote:
> Final, I tried:
>
> $ cvs -z3 -d
> :pserver:anoncvs:passw...@anoncvs.postgresql.org:/projects/cvsroot co -r
> REL8_3_STABLE -P pgsql
>
> Checked file configure.in. Around line 20, there is line:
> AC_INIT([PostgreSQL], [8.3.9], [pgsql-b...@postgresql.
1 - 100 of 113 matches
Mail list logo
