Tom Lane escribió:
> Alvaro Herrera writes:
> > I think having schemapg.h be autogenerated is a good idea, so I stripped
> > that from Robert Haas' patch. Here's the result. This should be
> > relatively uncontroversial since, well, the controversial stuff has been
> > stripped. The one problem
Thanks a lot for all of your pieces of advice.
I modified the name of the page as well as I deleted the parts linked to the
-P option.
It just consisted in deleting the right parts.
Here is the lighted version.
--
Michael Paquier
NTT OSSC
postgresql-8.4.0-pgbenchshell2.0.patch
Description: Bi
On Wed, Aug 12, 2009 at 6:44 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> I think having schemapg.h be autogenerated is a good idea, so I stripped
>> that from Robert Haas' patch. Here's the result. This should be
>> relatively uncontroversial since, well, the controversial stuff has been
>>
Alvaro Herrera writes:
> However I'm guessing that what actually happens is that heap_update is
> returning HeapTupleSelfUpdated instead, which the code states as
> /* nothing to do */.
Yeah.
> I imagine this is so because of some old fiddling to get semantics just
> right for obscure corner cas
Dean Rasheed writes:
> I spotted another error message which could use improvement:
> ...
> The attached patch to transformFkeyCheckAttrs() makes the former case
> generate a similar error to the latter.
Ah, you caught me being lazy ;-). I had actually considered doing this
while reviewing the d
Alvaro Herrera writes:
> I think having schemapg.h be autogenerated is a good idea, so I stripped
> that from Robert Haas' patch. Here's the result. This should be
> relatively uncontroversial since, well, the controversial stuff has been
> stripped. The one problem is that it introduces more c
On 8/12/09 11:13 AM, Peter Eisentraut wrote:
> On Wednesday 12 August 2009 19:27:06 Josh Berkus wrote:
>>> Can you export DocBook from that?
>> Not without writing some custom perl code, no.
>>
>> Should we stick your release notes on git somewhere? I'd like to expand
>> the and add a couple of th
Tom Lane wrote:
> Stefan Kaltenbrunner writes:
> > the "surprise" here was that the delete is getting silently surpressed
> > even though the original Qual still holds and afaik should result in the
> > row deleted.
>
> The delete from foo acts first (since you put it in a BEFORE trigger).
> Af
Pierre Frédéric Caillaud escribió:
> But when I see a big red button, I just press it to see what happens.
> Ugly hacks are useful to know how fast the thing can go ; then the
> interesting part is to reimplement it cleanly, trying to reach the
> same performance...
Right -- now that you've shown
I think having schemapg.h be autogenerated is a good idea, so I stripped
that from Robert Haas' patch. Here's the result. This should be
relatively uncontroversial since, well, the controversial stuff has been
stripped. The one problem is that it introduces more complex code than
it removes dull
Stefan Kaltenbrunner writes:
> the "surprise" here was that the delete is getting silently surpressed
> even though the original Qual still holds and afaik should result in the
> row deleted.
The delete from foo acts first (since you put it in a BEFORE trigger).
After the trigger comes back, th
>> We don't touch datatype APIs
>> lightly, because it affects too much code.
>>
>> regards, tom lane
>
> I definitely agree with that.
Actually, let me clarify:
When I modified the datatype API, I was feeling uneasy, like "I shouldn't
really touch this".
But
* Alvaro Herrera (alvhe...@commandprompt.com) wrote:
> No, that's for the workers. The launcher needs all the entries anyway.
> (I'm assuming it will be able to check visibility of tuples, correct?
> Hmm, it will need to run transactions in order to do that ...)
I realize I'm jumping into the mid
I attached conservative version of patch which only reorder #define to
avoid cross including half from readline and half from editline.
Zdenek
Tom Lane píše v čt 06. 08. 2009 v 18:13 -0400:
> Zdenek Kotala writes:
> > It seems to me that editline never distributed history.h file and
> >
Alvaro Herrera writes:
> No, that's for the workers. The launcher needs all the entries anyway.
> (I'm assuming it will be able to check visibility of tuples, correct?
> Hmm, it will need to run transactions in order to do that ...)
No, you don't need to be in a transaction to check visibility.
On Wednesday 12 August 2009 19:27:06 Josh Berkus wrote:
> > Can you export DocBook from that?
>
> Not without writing some custom perl code, no.
>
> Should we stick your release notes on git somewhere? I'd like to expand
> the and add a couple of things.
I say just take the file and edit it.
--
Tom Lane wrote:
> Alvaro Herrera writes:
> > (BTW I assume there is going to be an index on OID
> > available on pg_database after the shared relcache initialization?)
>
> Yeah. That's not in the patch I sent last night, but the OID index has
> to become nailed too in order to allow removing Fi
Robert Haas wrote:
> I have also long argued that "Synchronous Replication" should really
> be called "Streaming Replication".
+1
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
On Wed, Aug 12, 2009 at 19:08, Fujii Masao wrote:
> Hi,
>
> On Tue, Aug 11, 2009 at 3:10 AM, Magnus Hagander wrote:
>> I have reproduced this. The problem is:
>> (void) signal(SIGUSR1, sighandler);
>> (void) signal(SIGINT, sighandler); /* deprecated, use SIGUSR1 */
>>
>>
>> None
Hi,
a customer of us complained a behavioural difference
between ESQL/C and ECPG. They check sqlca.sqlcode
almost everywhere in their application currently under
porting to PostgreSQL. Somewhere in their code
however there was a place where a statement error
was ignored and the error was reported
Hi,
On Tue, Aug 11, 2009 at 3:10 AM, Magnus Hagander wrote:
> I have reproduced this. The problem is:
> (void) signal(SIGUSR1, sighandler);
> (void) signal(SIGINT, sighandler); /* deprecated, use SIGUSR1 */
>
>
> None of these signals exist on WIN32. I think the only reason it
>
Alvaro Herrera writes:
> Are you going to commit the current patch? We can remove the hacks that
> support autovacuum later. I was thinking that InitPostgres could be
> split in two, with the first half ending just after
> RelationCacheInitializePhase2. Then workers could figure out their
> dat
> Can you export DocBook from that?
Not without writing some custom perl code, no.
Should we stick your release notes on git somewhere? I'd like to expand
the and add a couple of things.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-h
On Wed, 2009-08-12 at 18:07 +0200, Andrew Dunstan wrote:
>
> Csaba Nagy wrote:
> > On Wed, 2009-08-12 at 17:11 +0200, Andrew Dunstan wrote:
> Well, the right solution would actually be NOT to use CDATA but to
> replace a literal linefeed with the XML numeric escape
, but I
> really don't think
On 08/12/2009 12:04 PM, Suno Ano wrote:
can anybody tell me, is there a roadmap with regards to
http://www.postgres-r.org ?
I would love to see it become production-ready asap.
Even a breakdown of what is left to do might be useful in case any of us
want to pick at it. :-)
Cheers,
mark
Hello,
can anybody tell me, is there a roadmap with regards to
http://www.postgres-r.org ?
I would love to see it become production-ready asap.
pgpy65IJnozC6.pgp
Description: PGP signature
Mark Mielke wrote:
> To further confuse things, the "temperature" might apply to only a
> particular aspect of the solution. For example, "hot swappable disk
> drives" are drives that probably do sit on a shelf until they are
> needed, and the "hot" aspect only implies that the server does not n
Csaba Nagy wrote:
On Wed, 2009-08-12 at 17:11 +0200, Andrew Dunstan wrote:
That will just make things worse. And it will break if the XML includes
any expression that contains a line break.
Then escape the expressions using CDATA or such... I'm sure it would be
possible to make sure
Le mercredi 12 août 2009, Greg Stark a écrit :
> On Wed, Aug 12, 2009 at 3:07 PM, Cédric
>
> Villemain wrote:
> > I wonder if POSIX_FADV_RANDOM and POSIX_FADV_SEQUENTIAL are still
> > innacurate for postgreSQL ?
> >
> > I find
> > «A related problem is that the smgr uses the same FD to access the s
On Wed, 2009-08-12 at 17:41 +0200, Andrew Dunstan wrote:
>
> Csaba Nagy wrote:
> > Then why you bother calling it "machine readable" at all ? Would you
> > really read your auto-explain output on the DB server ? I doubt that's
> > the common usage scenario, I would expect that most people would le
Merlin Moncure escribió:
> 2009/8/12 Pierre Frédéric Caillaud :
> >
> >
> >> If you do as much damage to the I/O function API as the other patch
> >> did, it will probably be rejected.
> >
> > You mean, as the COPY patch in my previous message, or as another
> > patch ?
> > (I just se
While working on some code I ran into a problem where some DELETE
requests would get seamingly ignored after a while I managed to boil it
down to:
CREATE TABLE foo (a INT PRIMARY KEY, b int);
CREATE TABLE bar (x int PRIMARY KEY, a int references foo(a) ON DELETE
SET NULL);
INSERT INTO foo VA
Tom Lane wrote:
> Alvaro Herrera writes:
> > Hmm, to what database would it connect?
>
> Well, it wouldn't. As of the patch I'm working on, it's okay to have
> PGPROC entries showing zero in databaseId. Normally they'd be backends
> that weren't done starting yet, but I see no reason the AV la
2009/8/12 Pierre Frédéric Caillaud :
>
>
>> If you do as much damage to the I/O function API as the other patch
>> did, it will probably be rejected.
>
> You mean, as the COPY patch in my previous message, or as another
> patch ?
> (I just search the archives and found one about CopyR
Csaba Nagy wrote:
Then why you bother calling it "machine readable" at all ? Would you
really read your auto-explain output on the DB server ? I doubt that's
the common usage scenario, I would expect that most people would let a
tool extract/summarize it and definitely process it somewhere else
On Wed, 2009-08-12 at 17:31 +0200, Csaba Nagy wrote:
> On Wed, 2009-08-12 at 17:11 +0200, Andrew Dunstan wrote:
> > That will just make things worse. And it will break if the XML includes
> > any expression that contains a line break.
>
> Then escape the expressions using CDATA or such... I'm sur
On Wed, 12 Aug 2009 09:42:00 -0400
Andrew Dunstan wrote:
> One thing I have noticed that we should talk about is that the
> explain XML output doesn't contain the query that is being explained.
> That's unfortunate - it means that any logfile processor will need to
> extract the statement from the
Alvaro Herrera writes:
> Tom Lane wrote:
>> Well, I meant pseudo-backend in the sense of "just like an AV worker".
>> We might not want it to show in pg_stat_activity, but otherwise I think
>> it'd be the same.
> Hmm, to what database would it connect?
Well, it wouldn't. As of the patch I'm wor
On Wed, 2009-08-12 at 17:11 +0200, Andrew Dunstan wrote:
> That will just make things worse. And it will break if the XML includes
> any expression that contains a line break.
Then escape the expressions using CDATA or such... I'm sure it would be
possible to make sure it's one line and rely on t
On Wed, Aug 12, 2009 at 3:07 PM, Cédric
Villemain wrote:
>
> I wonder if POSIX_FADV_RANDOM and POSIX_FADV_SEQUENTIAL are still innacurate
> for postgreSQL ?
>
> I find
> «A related problem is that the smgr uses the same FD to access the same
> relation no matter how many scans are in progress. Thin
Alvaro Herrera wrote:
Andrew Dunstan escribió:
STATEMENT: SELECT 1 AS one;
LOG: duration: 0.008 ms plan:
Result
0.00
0.01
1
0
I think what this says is that auto-explain should not be sending its
output to the regular logfile, but somewhere else.
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Is there a real downside to promoting the launcher to be a
> >> pseudo-backend?
>
> > Aside from the fact that we don't have any pseudo-backend yet, I don't
> > see any ...
>
> Well, I meant pseudo-backend in the sense of "just li
Andrew Dunstan escribió:
> STATEMENT: SELECT 1 AS one;
> LOG: duration: 0.008 ms plan:
>
> Result
> 0.00
> 0.01
> 1
> 0
>
I think what this says is that auto-explain should not be sending its
output to the regular logfile, but somewhere else. The format you sh
Greg Stark wrote:
> I'm not actually certain we can handle streaming synchronous mode to
> a standby slave. Does the slave need to have connections enabled to
> handle feeding wal sync status to the master?
I thought there were major concerns about the interaction of those
read-only queries w
Csaba Nagy wrote:
On Wed, 2009-08-12 at 15:42 +0200, Andrew Dunstan wrote:
Have you actually looked at a logfile with this in it? A simple
stylesheet won't do at all. What you get is not an XML document but a
text document with little bits of XML embedded in it. So you would need
a progra
On Wed, 2009-08-12 at 16:51 +0200, Csaba Nagy wrote:
> I argue that a sufficiently complicated explain output will never be
> easily navigated in a text browser, however much you would like it. If
> you do a where clause with 100 nested ANDs (which occasionally happens
> here), I don't think you'll
On Wed, 2009-08-12 at 15:42 +0200, Andrew Dunstan wrote:
> Have you actually looked at a logfile with this in it? A simple
> stylesheet won't do at all. What you get is not an XML document but a
> text document with little bits of XML embedded in it. So you would need
> a program to parse that f
If you do as much damage to the I/O function API as the other patch
did, it will probably be rejected.
You mean, as the COPY patch in my previous message, or as another patch
?
(I just search the archives and found one about CopyReadLine, but that's
probably not what you are talki
On Wed, Aug 12, 2009 at 10:01 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Another design issue is this: The root node of an XML document is
>> ideally a distinguished element that can't occur within itself.
>> auto-explain doesn't seem to be doing this.
>
> Huh? I get (for "explain 2+2")
>
>
Hello,
I wonder if POSIX_FADV_RANDOM and POSIX_FADV_SEQUENTIAL are still innacurate
for postgreSQL ?
I find
«A related problem is that the smgr uses the same FD to access the same
relation no matter how many scans are in progress. Think about a complex query
that is doing both a seqscan and a
Andrew Dunstan writes:
> Another design issue is this: The root node of an XML document is
> ideally a distinguished element that can't occur within itself.
> auto-explain doesn't seem to be doing this.
Huh? I get (for "explain 2+2")
http://www.postgresql.org/2009/explain";>
Alvaro Herrera writes:
> Well, the rule here is simple too (set cinoptions=(0 if you're
> Vim-enabled). It's only function prototypes that are a bit weird, and
> once you understand how it works it's trivial to reproduce.
Yeah. What I normally do if I'm actually trying to reproduce pgindent's
h
On Wed, Aug 12, 2009 at 9:38 AM, Alvaro
Herrera wrote:
> Robert Haas escribió:
>> On Wed, Aug 12, 2009 at 12:27 AM, Tom Lane wrote:
>
>> > Ah. That's a bit idiosyncratic to pgindent. What it does for a
>> > function definition makes sense, I think: it lines up all the
>> > parameters to start in
On Wed, Aug 12, 2009 at 9:35 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Tom Lane escribió:
>>> Um, sorry, no reason to do which?
>
>> No reason not to leave prototypes alone in the AWK code. Isn't the
>> style emitted by indent good enough already? The comment that ctags
>> needs it is prob
On Wed, Aug 12, 2009 at 9:42 AM, Andrew Dunstan wrote:
> Csaba Nagy wrote:
>>
>> On Tue, 2009-08-11 at 23:58 +0200, Andrew Dunstan wrote:
>>
>>>
>>> Well, I don't think that the fact that we are producing machine-readable
>>> output means we can just ignore the human side of it. It is more than lik
=?utf-8?Q?Pierre_Fr=C3=A9d=C3=A9ric_Caillau?= =?utf-8?Q?d?=
writes:
> I've been examining the code path for COPY FROM too, and I think it is
> possible to get the same kind of speedups on COPY FROM that the patch in
> the previous message did for COPY TO, that is to say perhaps 2-3x faster
> in B
Csaba Nagy wrote:
On Tue, 2009-08-11 at 23:58 +0200, Andrew Dunstan wrote:
Well, I don't think that the fact that we are producing machine-readable
output means we can just ignore the human side of it. It is more than
likely that such output will be read by both machines and humans.
Obvio
Alvaro Herrera writes:
> Tom Lane wrote:
>> Is there a real downside to promoting the launcher to be a
>> pseudo-backend?
> Aside from the fact that we don't have any pseudo-backend yet, I don't
> see any ...
Well, I meant pseudo-backend in the sense of "just like an AV worker".
We might not wan
Robert Haas escribió:
> On Wed, Aug 12, 2009 at 12:27 AM, Tom Lane wrote:
> > Ah. That's a bit idiosyncratic to pgindent. What it does for a
> > function definition makes sense, I think: it lines up all the
> > parameters to start in the same column:
> That is truly bizarre. +1 from me for doi
Tom Lane wrote:
> What was sort of in the back of my mind was to have every n'th AV worker
> examine pg_database and report back to the launcher (probably through
> shared memory) with an indication of the next few databases that should
> be vacuumed and when. Not sure how inefficient that might
Alvaro Herrera writes:
> Tom Lane escribió:
>> Um, sorry, no reason to do which?
> No reason not to leave prototypes alone in the AWK code. Isn't the
> style emitted by indent good enough already? The comment that ctags
> needs it is probably outdated (I know my ctags, the Exuberant one,
> does
On Wed, Aug 12, 2009 at 12:27 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 11, 2009 at 10:08 PM, Tom Lane wrote:
>>> If that's not it, you'd need to mention details.
>
>> Well, one thing I've noticed is that when a function prototype wraps
>> around to the next line, you often change t
Tom Lane escribió:
> Alvaro Herrera writes:
> > The reason this is like this is that the indent binary modifies the
> > prototype exactly like the function definition, and then the awk program
> > that's used in the pipeline "pulls up" the second line:
>
> > # Move prototype names to the same li
On Tue, Aug 11, 2009 at 11:19:18PM -0400, Robert Haas wrote:
> On Tue, Aug 11, 2009 at 9:44 PM, Greg Stark wrote:
> > On Tue, Aug 11, 2009 at 10:13 PM, Robert Haas wrote:
> >> On Tue, Aug 11, 2009 at 4:07 PM, Josh Berkus wrote:
> >>> So really, the "streaming replication" patch should be called "ho
On Wed, Aug 12, 2009 at 4:19 AM, Robert Haas wrote:
> On Tue, Aug 11, 2009 at 9:44 PM, Greg Stark wrote:
>> No! This is *not* what "hot standby" means, at least not in the Oracle world.
>
> I'm perplexed by this. For example: http://en.wikipedia.org/wiki/Hot_standby
Well that just links to "Hot S
While looking at this report
http://archives.postgresql.org/pgsql-bugs/2009-08/msg00083.php
I spotted another error message which could use improvement:
CREATE TABLE foo(a int PRIMARY KEY DEFERRABLE);
CREATE TABLE bar(a int REFERENCES foo(a));
ERROR: there is no unique constraint matching give
Yeah, the patch I think breaks things isn't included in 8.3.7 - it
will be in 8.3.8 though...
//Magnus
On Wed, Aug 12, 2009 at 11:08, wader2 wrote:
> I can't compile nor read source, but can tell you that
> pg_standby.exe in 8.3.7 works fine.
>
> Magnus Hagander wrote:
>>
>> On Mon, Aug 10, 2009
I can't compile nor read source, but can tell you that
pg_standby.exe in 8.3.7 works fine.
Magnus Hagander wrote:
On Mon, Aug 10, 2009 at 20:44, Tom Lane wrote:
Magnus Hagander writes:
If I just move those two lines into the #ifndef WIN32 block just
around it, it compiles and doesn't crash on
For future reference, and since this keeps appearing every few months:
The
license of LZO is not acceptable for inclusion or use with PostgreSQL.
You
need to find a different library if you want to pursue this further.
Yes, I know about the license... I used LZO for tests, but since my
Replying to myself...
I've been examining the code path for COPY FROM too, and I think it is
possible to get the same kind of speedups on COPY FROM that the patch in
the previous message did for COPY TO, that is to say perhaps 2-3x faster
in BINARY mode and 10-20% faster in TEXT mode (these figu
On Tuesday 11 August 2009 13:05:39 Pierre Frédéric Caillaud wrote:
> Well, here is the patch. I've included a README, which I paste here.
> If someone wants to play with it (after the CommitFest...) feel free to
> do so.
> While it was an interesting thing to try, I don't think it
On Tue, 2009-08-11 at 23:58 +0200, Andrew Dunstan wrote:
> Well, I don't think that the fact that we are producing machine-readable
> output means we can just ignore the human side of it. It is more than
> likely that such output will be read by both machines and humans.
> Obviously, we need to
On Wednesday 12 August 2009 03:34:22 Josh Berkus wrote:
> On 8/11/09 3:27 PM, Peter Eisentraut wrote:
> > OK, since there was no clear consensus or volunteer for preparing release
> > notes for alpha 1, I have started something. Let me know what you think.
>
> Actually, the "consensus" was that Br
73 matches
Mail list logo
