2009/9/19 Pavel Stehule :
> 2009/9/18 Selena Deckelmann :
>> Hi!
>>
>> John Naylor and I reviewed this patch. John created two test cases to
>> demonstrated issues described later in this email. I've attached
>> those for reference.
>>
>> On Thu, Aug 27, 2009 at 8:04 PM, Pavel Stehule
>> wrote:
2009/9/7 Itagaki Takahiro :
> Here is a patch to implement the following items in our ToDo list:
> * Add CREATE TABLE LIKE ... INCLUDING COMMENTS
> * Have CREATE TABLE LIKE copy column storage parameters
>
Hello Itagaki-san,
I am doing an initial review of your patch. I applied the version
lab
Andrew Dunstan wrote:
>
> Alvaro Herrera wrote:
>
> >Try installcheck-parallel, which should be a bit better. It's probably
> >not yet good enough though because it always runs the same tests
> >concurrently.
>
> It is also quite easy to set up your own schedule.
... except you have to be caref
Alvaro Herrera wrote:
Simon Riggs wrote:
What I find amazing is that it passed the test where I put it doing make
installcheck in an infinite loop for a long time. I guess that means the
regression tests hardly touch the concurrency code at all, which now I
think about it makes sense but I
Tom Lane wrote:
Joshua Tolley writes:
Having just sent two messages to the discussion about the wrong patch, I'll
apologize, and shut up now :)
No need to apologize --- this really is, and should be, all one
conversation. I think the main problem I've got with applying either
patch
Joshua Tolley writes:
> Having just sent two messages to the discussion about the wrong patch, I'll
> apologize, and shut up now :)
No need to apologize --- this really is, and should be, all one
conversation. I think the main problem I've got with applying either
patch is that I don't believe w
On Fri, Sep 25, 2009 at 05:04:45PM -0400, Robert Haas wrote:
> On Fri, Sep 25, 2009 at 4:58 PM, Joshua Tolley wrote:
> > On Fri, Sep 25, 2009 at 03:19:36PM -0400, Tom Lane wrote:
> >> However, I don't think I actually believe the premise of this patch,
> >> which is that sending log information to
On Fri, Sep 25, 2009 at 5:27 PM, Joshua Tolley wrote:
> On Fri, Sep 25, 2009 at 04:18:08PM -0400, Robert Haas wrote:
>> > I would even more like to have some things send to CSV and some things
>> > sent to text.
>>
>> This patch won't help, then.
>
> No, it won't, but as said before, it lays the g
On Fri, Sep 25, 2009 at 05:04:45PM -0400, Robert Haas wrote:
> On Fri, Sep 25, 2009 at 4:58 PM, Joshua Tolley wrote:
> > On Fri, Sep 25, 2009 at 03:19:36PM -0400, Tom Lane wrote:
> >> However, I don't think I actually believe the premise of this patch,
> >> which is that sending log information to
On Fri, Sep 25, 2009 at 5:01 PM, Magnus Hagander wrote:
> On Fri, Sep 25, 2009 at 22:57, Andrew Dunstan wrote:
>>
>> Magnus Hagander wrote:
>>>
>>> On Fri, Sep 25, 2009 at 22:17, Andrew Dunstan wrote:
>>>
Magnus Hagander wrote:
>
> I definitely want both text and CSV outpu
On Fri, Sep 25, 2009 at 04:18:08PM -0400, Robert Haas wrote:
> > I would even more like to have some things send to CSV and some things
> > sent to text.
>
> This patch won't help, then.
No, it won't, but as said before, it lays the groundwork, namely letting the
syslogger know things about the l
On Fri, Sep 25, 2009 at 4:29 PM, Magnus Hagander wrote:
> On Fri, Sep 25, 2009 at 22:26, Robert Haas wrote:
>> On Fri, Sep 25, 2009 at 4:13 PM, Magnus Hagander wrote:
>>> On Fri, Sep 25, 2009 at 05:18, Robert Haas wrote:
On Mon, Sep 14, 2009 at 4:14 PM, Tom Lane wrote:
> Magnus Hagand
[ argh, hit send a bit too fast ]
Magnus Hagander writes:
> Also, how often does it actually happen that "random libraries linked
> into the backend emit messages on stderr"? Is this really something
> that we need to pay so much attention to, rather than just let them go
> on stderr and have the
On 9/26/09, Tom Lane wrote:
> Maybe it doesn't "need" to know, but I think it would be disastrous from
> a maintenance standpoint to not keep the two sets of flex rules in
> strict correspondence. It would soon become unclear whether or how to
> apply changes in the backend lexer to psql.
Pat
Magnus Hagander writes:
> Well, from how I read the first complaint here, running with
> logging_collector on is simply broken from the crash perspective, no?
> I mean, don't we have the same problem *today*,
No, we don't. But we would if we accept the proposed patch.
re
On Fri, Sep 25, 2009 at 22:57, Andrew Dunstan wrote:
>
> Magnus Hagander wrote:
>>
>> On Fri, Sep 25, 2009 at 22:17, Andrew Dunstan wrote:
>>
>>>
>>> Magnus Hagander wrote:
>>>
I definitely want both text and CSV output - which I can't have today.
>>>
>>> Sure you can. What makes y
On Fri, Sep 25, 2009 at 4:58 PM, Joshua Tolley wrote:
> On Fri, Sep 25, 2009 at 03:19:36PM -0400, Tom Lane wrote:
>> However, I don't think I actually believe the premise of this patch,
>> which is that sending log information to both stderr and syslog is
>> a useful thing to do
>
> Actually the t
Peter Eisentraut writes:
> On Fri, 2009-09-25 at 15:39 -0400, Tom Lane wrote:
>> Also, it failed to update psql's scanner to match.
> Why does the psql scanner need to know about this? Doesn't it just need
> to know the difference between backslash-quote and backslash-something
> else?
Maybe it
On Fri, Sep 25, 2009 at 4:33 PM, Magnus Hagander wrote:
> On Fri, Sep 25, 2009 at 22:18, Robert Haas wrote:
>> On Fri, Sep 25, 2009 at 4:06 PM, Magnus Hagander wrote:
>>> Other than if you're logging all your queries (or over time, where
>>> is very small), I've never seen a system with perfor
On Fri, 2009-09-25 at 16:30 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > What I find amazing is that it passed the test where I put it doing make
> > installcheck in an infinite loop for a long time. I guess that means the
> > regression tests hardly touch the concurrency code at all,
"shakahsha...@gmail.com" writes:
> From pg_dump/pg_restore section (9.2 of the Todo page on the
> PostgreSQL Wiki), is the following item
> "Add comments to output indicating version of pg_dump and of the
> database server"
> simply asking for a change to the pg_dump header from:
I think so, bu
On Fri, Sep 25, 2009 at 03:19:36PM -0400, Tom Lane wrote:
> However, I don't think I actually believe the premise of this patch,
> which is that sending log information to both stderr and syslog is
> a useful thing to do
Actually the thing I want is to be able to send some stuff to syslog, and som
Magnus Hagander wrote:
On Fri, Sep 25, 2009 at 22:17, Andrew Dunstan wrote:
Magnus Hagander wrote:
I definitely want both text and CSV output - which I can't have today.
Sure you can. What makes you think you can't?
How do i do that? When I enable csv logging, it cha
Simon Riggs wrote:
> What I find amazing is that it passed the test where I put it doing make
> installcheck in an infinite loop for a long time. I guess that means the
> regression tests hardly touch the concurrency code at all, which now I
> think about it makes sense but I still find that very
Robert Haas escribió:
> $ With that, it's no longer necessary to restart your server just to
> $ reconfigure the logging, and it also takes away a confusing parameter
> $ (really "log_destination=stderr, logging_collector=on" is *not* a logical
> $ way to say "log to file"). Instead, it adds a log
On Fri, 2009-09-25 at 15:39 -0400, Tom Lane wrote:
> pet...@postgresql.org (Peter Eisentraut) writes:
> > Log Message:
> > ---
> > Unicode escapes in E'...' strings
>
> > Author: Marko Kreen
>
> This patch has broken the no-backup property of the scanner,
Fixed.
> Also, it failed to up
Marko Kreen writes:
> On 9/25/09, Tom Lane wrote:
>> This patch has broken the no-backup property of the scanner, which
>> is an absolutely unacceptable penalty for such a second-order feature.
>> Please fix or revert.
> How do I find out the state of said property?
Per the comment at the head
While researching the RelationCacheInitializePhase2 unpleasantness,
I happened across this long-ago discussion:
http://archives.postgresql.org/pgsql-bugs/2004-12/msg00128.php
in which we established the coding rule that formrdesc() must construct
completely-correct TupleDescs for the relations it b
On Fri, Sep 25, 2009 at 22:18, Robert Haas wrote:
> On Fri, Sep 25, 2009 at 4:06 PM, Magnus Hagander wrote:
>> Other than if you're logging all your queries (or over time, where
>> is very small), I've never seen a system with performance issues
>> from logging. I'm sure others may have, but no
On Fri, Sep 25, 2009 at 22:17, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>>
>> I definitely want both text and CSV output - which I can't have today.
>>
>>
>
> Sure you can. What makes you think you can't?
How do i do that? When I enable csv logging, it changes the log format
to csv, and
On Fri, Sep 25, 2009 at 22:26, Robert Haas wrote:
> On Fri, Sep 25, 2009 at 4:13 PM, Magnus Hagander wrote:
>> On Fri, Sep 25, 2009 at 05:18, Robert Haas wrote:
>>> On Mon, Sep 14, 2009 at 4:14 PM, Tom Lane wrote:
Magnus Hagander writes:
> First, the patch removes the logging_collecto
On Fri, Sep 25, 2009 at 4:13 PM, Magnus Hagander wrote:
> On Fri, Sep 25, 2009 at 05:18, Robert Haas wrote:
>> On Mon, Sep 14, 2009 at 4:14 PM, Tom Lane wrote:
>>> Magnus Hagander writes:
First, the patch removes the logging_collector parameter and basically
assumes that logging_colle
On 9/25/09, Tom Lane wrote:
> pet...@postgresql.org (Peter Eisentraut) writes:
> > Log Message:
> > ---
> > Unicode escapes in E'...' strings
>
> > Author: Marko Kreen
>
> This patch has broken the no-backup property of the scanner, which
> is an absolutely unacceptable penalty for
On Fri, Sep 25, 2009 at 4:06 PM, Magnus Hagander wrote:
> On Fri, Sep 25, 2009 at 21:19, Tom Lane wrote:
>> "Joshua D. Drake" writes:
>>> On Mon, 2009-09-14 at 09:43 +0900, Itagaki Takahiro wrote:
We have a tip that log_line_prefix is not required for syslog
in the documentation, but w
Magnus Hagander wrote:
I definitely want both text and CSV output - which I can't have today.
Sure you can. What makes you think you can't?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
On Fri, Sep 25, 2009 at 05:18, Robert Haas wrote:
> On Mon, Sep 14, 2009 at 4:14 PM, Tom Lane wrote:
>> Magnus Hagander writes:
>>> First, the patch removes the logging_collector parameter and basically
>>> assumes that logging_collector is always on.
>>
>> I don't find that to be a good idea, a
On Fri, Sep 25, 2009 at 21:19, Tom Lane wrote:
> "Joshua D. Drake" writes:
>> On Mon, 2009-09-14 at 09:43 +0900, Itagaki Takahiro wrote:
>>> We have a tip that log_line_prefix is not required for syslog
>>> in the documentation, but we'd better to have independent setttings
>>> if we set log_dest
pet...@postgresql.org (Peter Eisentraut) writes:
> Log Message:
> ---
> Unicode escapes in E'...' strings
> Author: Marko Kreen
This patch has broken the no-backup property of the scanner, which
is an absolutely unacceptable penalty for such a second-order feature.
Please fix or revert.
"Joshua D. Drake" writes:
> On Mon, 2009-09-14 at 09:43 +0900, Itagaki Takahiro wrote:
>> We have a tip that log_line_prefix is not required for syslog
>> in the documentation, but we'd better to have independent setttings
>> if we set log_destination to 'stderr, syslog'.
> IMO we should just mak
>From pg_dump/pg_restore section (9.2 of the Todo page on the
PostgreSQL Wiki), is the following item
"Add comments to output indicating version of pg_dump and of the
database server"
simply asking for a change to the pg_dump header from:
--
-- PostgreSQL database dump
--
to something like:
-
On Mon, 2009-09-14 at 09:43 +0900, Itagaki Takahiro wrote:
> Here is a patch to add a GUC parameter "syslog_line_prefix".
> It adds prefixes to syslog and eventlog. We still have
> "log_line_prefix", that will be used only for stderr logs.
>
> We have a tip that log_line_prefix is not required for
On Fri, Sep 25, 2009 at 12:13 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>
>> On the other hand, I don't think this is the right way to do it. The
>> patch proposes the following mapping of logging destinations to GUCs:
>>
>> stderr -> log_line_prefix (same as now)
>> csvlog -> not applica
On Fri, Sep 25, 2009 at 09:29:24AM +0300, Peter Eisentraut wrote:
> On Thu, 2009-09-24 at 20:36 -0400, Tom Lane wrote:
> > BTW, are port numbers still limited to 16 bits in IPv6?
>
> Port numbers are in TCP, not in IP.
I'd checked that it should work with IPv6, but I hadn't realized that
it was b
On Fri, 2009-09-25 at 15:50 +0300, Heikki Linnakangas wrote:
> Hang on, isn't this 180 degrees backwards?
A witty riposte escapes me; yes, the if test is !correct.
What I find amazing is that it passed the test where I put it doing make
installcheck in an infinite loop for a long time. I guess
Robert Haas escribió:
> On the other hand, I don't think this is the right way to do it. The
> patch proposes the following mapping of logging destinations to GUCs:
>
> stderr -> log_line_prefix (same as now)
> csvlog -> not applicable (same as now)
> syslog -> syslog_line_prefix
> eventlog -> s
On Fri, Sep 25, 2009 at 4:56 PM, Peter Eisentraut wrote:
> On Fri, 2009-09-25 at 16:47 +0100, Dave Page wrote:
>> > I think you have an old version of docbook-xsl.
>>
>> It's the latest available for CentOS 4.6:
>>
>> [buildf...@bf-linux ~]$ rpm -q -a |grep docbook
>> docbook-utils-0.6.14-4
>> doc
On Fri, 2009-09-25 at 16:47 +0100, Dave Page wrote:
> > I think you have an old version of docbook-xsl.
>
> It's the latest available for CentOS 4.6:
>
> [buildf...@bf-linux ~]$ rpm -q -a |grep docbook
> docbook-utils-0.6.14-4
> docbook-style-xsl-1.65.1-2
> docbook-style-dsssl-1.78-4
> docbook-dt
Hi Jeff,
On Tue, Sep 22, 2009 at 8:06 PM, Jeff Davis wrote:
> I think you mean that the planning time is in milliseconds, not seconds.
>
The planning time is actually in seconds. Even without our feature,
planning takes a few seconds since the optimizer deals with hundreds
or even thousands of c
On Fri, Sep 25, 2009 at 4:28 PM, Peter Eisentraut wrote:
> On Fri, 2009-09-25 at 11:31 +0100, Dave Page wrote:
>> I'm hacking up our build framework to allow us to build installers for
>> the upcoming alpha2 release. When I install the Linux port, I'm seeing
>> the following failure:
>>
>> Writing
On Fri, 2009-09-25 at 11:31 +0100, Dave Page wrote:
> I'm hacking up our build framework to allow us to build installers for
> the upcoming alpha2 release. When I install the Linux port, I'm seeing
> the following failure:
>
> Writing dblink_build_sql_insert.1 for
> refentry(contrib-dblink-build-
Robert,
Here is the new version of the patch that applies to CVS HEAD as of this
morning.
Emmanuel
On Fri, Sep 18, 2009 at 12:14 AM, Emmanuel Cecchet wrote:
Here is a new version of error logging and autopartitioning in COPY based on
the latest COPY patch that provides the new syntax fo
On Fri, Sep 25, 2009 at 1:05 AM, Andrew Gierth
wrote:
>> "Euler" == Euler Taveira de Oliveira writes:
>
> Euler> Ops... forgot to remove it from other test. It seems much
> Euler> better but far from the ideal. :( I've never taken a look at
> Euler> the pl/pgsql code but it could be nice i
In XidInMVCCSnapshot:
> if (snapshot->takenDuringRecovery)
> {
> /*
>* If the snapshot contains full subxact data, the fastest way
> to check
>* things is just to compare the given XID against both subxact
> XIDs and
>* top
Marko Kreen wrote:
On 9/25/09, to...@tuxteam.de wrote:
On Thu, Sep 24, 2009 at 09:42:32PM +0300, Peter Eisentraut wrote:
> Good idea. This could also check for other invalid things like
> byte-order marks in UTF-8.
But watch out. Microsoft apps do like to insert a BOM at the beginning
Simon Riggs wrote:
> Definitely need to cope with them for Hot Standby. My point was general
> one to say that behaviour is very non-useful for users with prepared
> transactions. It just causes manual effort by a DBA each time the system
> is shutdown.
The transaction manager is supposed to recon
I'm hacking up our build framework to allow us to build installers for
the upcoming alpha2 release. When I install the Linux port, I'm seeing
the following failure:
Writing dblink_build_sql_insert.1 for refentry(contrib-dblink-build-sql-insert)
Writing dblink_build_sql_delete.1 for refentry(contri
On Fri, 2009-09-25 at 13:23 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2009-09-23 at 17:45 +0300, Heikki Linnakangas wrote:
> >> XactClearRecoveryTransactions() when we see a shutdown checkpoint, which
> >> clears all recovery locks. But doesn't that prematurely clear all lo
Hi,
On Fri, Sep 25, 2009 at 7:10 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> On Thu, Sep 24, 2009 at 7:57 PM, Heikki Linnakangas
>> wrote:
> - I know I said we should have just asynchronous replication at first,
> but looking ahead, how would you do synchronous?
As the pre
On Fri, 2009-09-25 at 13:14 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2009-09-23 at 19:07 +0300, Heikki Linnakangas wrote:
> >
> >> Rather than keep the numHeldLocks counters per-proc in proc array, I
> >> think it would be simpler to have a single (or one per lock partiti
Simon Riggs wrote:
> On Wed, 2009-09-23 at 17:45 +0300, Heikki Linnakangas wrote:
>> XactClearRecoveryTransactions() when we see a shutdown checkpoint, which
>> clears all recovery locks. But doesn't that prematurely clear all locks
>> belonging to prepared transactions as well?
>
> Much better to
On Fri, 2009-09-25 at 11:49 +0300, Heikki Linnakangas wrote:
> Looking at the startup sequence now.
>
> I see that you modified ExtendSUBTRANS so that it doesn't wipe out
> previously set values if it's called with out-of-order xids. I guess
> that works, although I think it can leave pages unzer
Simon Riggs wrote:
> On Wed, 2009-09-23 at 19:07 +0300, Heikki Linnakangas wrote:
>
>> Rather than keep the numHeldLocks counters per-proc in proc array, I
>> think it would be simpler to have a single (or one per lock partition)
>> counter in shared memory in lock.c. It's just an optimization to
Fujii Masao wrote:
> On Thu, Sep 24, 2009 at 7:57 PM, Heikki Linnakangas
> wrote:
- I know I said we should have just asynchronous replication at first,
but looking ahead, how would you do synchronous?
>>> As the previous patch did, I'm going to make walsender read the latest
>>> XLOG fr
On Thu, Sep 24, 2009 at 7:57 PM, Heikki Linnakangas
wrote:
>> Anyway, I'll change walreceiver to retry connecting to the primary
>> after an error occurs in PQstartXLogStreaming()/PQgetXLogData()/
>> PQputXLogRecPtr(). Should we set an upper limit of the number of
>> the retries?
>
> I don't think
On Wed, 2009-09-23 at 17:45 +0300, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
> > Simon Riggs wrote:
> >> On Wed, 2009-09-23 at 11:13 +0300, Heikki Linnakangas wrote:
> >>> I note that we don't emit RunningXacts after a shutdown checkpoint. So
> >>> if recovery starts at a shutdown chec
On Wed, 2009-09-23 at 19:07 +0300, Heikki Linnakangas wrote:
> Rather than keep the numHeldLocks counters per-proc in proc array, I
> think it would be simpler to have a single (or one per lock partition)
> counter in shared memory in lock.c. It's just an optimization to make it
> faster to find
On Thu, 2009-09-24 at 13:33 +0300, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
> > The problem becomes a lot easier if we accept that it's OK to have a
> > lock included in the running-xacts snapshot and also appear in a
> > XLOG_RELATION_LOCK record later. The standby should handle that
On 9/25/09, to...@tuxteam.de wrote:
> On Thu, Sep 24, 2009 at 09:42:32PM +0300, Peter Eisentraut wrote:
> > Good idea. This could also check for other invalid things like
> > byte-order marks in UTF-8.
>
> But watch out. Microsoft apps do like to insert a BOM at the beginning
> of the text. N
Looking at the startup sequence now.
I see that you modified ExtendSUBTRANS so that it doesn't wipe out
previously set values if it's called with out-of-order xids. I guess
that works, although I think it can leave pages unzeroed if it's called
with a large enough gap between xids, so that the pre
69 matches
Mail list logo