Hi,
On Tue, Sep 15, 2009 at 2:54 AM, Heikki Linnakangas
wrote:
> The first thing that caught my eye is that I don't think "replication"
> should be a real database. Rather, it should by a keyword in
> pg_hba.conf, like the existing "all", "sameuser", "samerole" keywords
> that you can put into th
Magnus Hagander wrote:
> On 15 sep 2009, at 07.21, Itagaki Takahiro > I'd like to have an opposite approach -- per-backend log files.
>
> I can see each backend writing it, certainly, but keeping it in
> separate files makes it useless without post processing, which in most
> vases means u
On 15 sep 2009, at 07.21, Itagaki Takahiro > wrote:
Magnus Hagander wrote:
Second, data transfer from the backends is now in the form of
structured data, and the actual logging message is put together in
the
syslogger
I'd like to have an opposite approach -- per-backend log files.
Syslo
Tom Lane wrote:
Robert Haas writes:
Yep, we were just discussing on IRC. It seems wwwmaster.postgreql.org
is down (unpingable).
Looks like someone fixed it.
Yeah we major network breakdown starting at ~02:29 CEST which got fixed
at ~04:00 CEST.
Stefan
--
Sent via pgsql-hackers mailin
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Robert Haas writes:
commitfest.postgresql.org is updated, please submit new patches at
https://commitfest.postgresql.org/action/commitfest_view/open
Anyone else finding that logging in at commitfest.postgresql.org fails?
I get
Inter
2009/9/15 decibel :
>
> On Sep 14, 2009, at 1:02 PM, Pavel Stehule wrote:
>
>> 2009/9/14 Merlin Moncure :
>>>
>>> On Mon, Sep 14, 2009 at 1:42 PM, Pavel Stehule
>>> wrote:
>
> How is it any worse than what people can already do? Anyone who isn't
> aware
> of the dangers of SQL inje
On mån, 2009-09-14 at 21:14 -0400, Robert Haas wrote:
> [P.S. I learned my lesson - last CF the equivalent email said that the
> CF was "closed", which of course was not what I meant at all.]
Yeah, except is it just me or is this "open" terminology equally weird?
Isn't the 2009-09 fest the one tha
Magnus Hagander wrote:
> Second, data transfer from the backends is now in the form of
> structured data, and the actual logging message is put together in the
> syslogger
I'd like to have an opposite approach -- per-backend log files.
Syslogger and appending logs at only one file will be a per
Hi,
On Tue, Sep 15, 2009 at 1:06 AM, Andrew Dunstan wrote:
> One question I have is what is the level of traffic involved between the
> master and the slave. I know numbers of people have found the traffic
> involved in shipping of log files to be a pain, and thus we get things like
> pglesslog.
Hi,
On Tue, Sep 15, 2009 at 12:47 AM, Greg Smith wrote:
> Putting on my DBA hat for a minute, the first question I see people asking
> is "how do I measure how far behind the slaves are?". Presumably you can
> get that out of pg_controldata; my first question is whether that's complete
> enough
> "Tom" == Tom Lane writes:
Tom> [ probably time to move this thread to -hackers ]
Tom> There is some moderately interesting reading material in section
Tom> 4.17.4 "Domain constraints" of SQL:2008. In particular, it
Tom> appears to me that the standard goes out of its way to NOT claim
Heikki Linnakangas wrote:
> Can't we use MultiByteToWideChar() to convert directly to the required
> encoding, avoiding the double conversion?
Here is an updated version of the patch.
I use direct conversion in pgwin32_toUTF16() if a corresponding codepage
is available. If not available, I stil
[ probably time to move this thread to -hackers ]
There is some moderately interesting reading material in section
4.17.4 "Domain constraints" of SQL:2008. In particular, it appears to
me that the standard goes out of its way to NOT claim that every value
that "is of" a domain type satisfies the
On Mon, Sep 14, 2009 at 5:41 AM, Heikki Linnakangas
wrote:
> Heikki Linnakangas wrote:
>> Tom Lane wrote:
>>> It strikes me that in the cases where it wouldn't be necessary to
>>> compute junk sort-key columns, it would be because we were scanning an
>>> index that includes those values. So if th
2009/9/14 Pierre Frédéric Caillaud
>
> Replying to myself...
>
> Jeff suggested to build pages in local memory and insert them later in the
> table. This is what's used in CLUSTER for instance, I believe.
>
> It has some drawbacks though :
>
> - To insert the tuples in indexes, the tuples need ti
Robert Haas writes:
> Yep, we were just discussing on IRC. It seems wwwmaster.postgreql.org
> is down (unpingable).
Looks like someone fixed it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
2009/9/14 Pierre Frédéric Caillaud
>
> I've done a little experiment with bulk inserts.
>
> => heap_bulk_insert()
>
> Behaves like heap_insert except it takes an array of tuples (HeapTuple
> *tups, int ntups).
>
> - Grabs a page (same as heap_insert)
>
> - While holding exclusive lock, inserts as
On Mon, Sep 14, 2009 at 9:30 PM, Tom Lane wrote:
> Robert Haas writes:
>> commitfest.postgresql.org is updated, please submit new patches at
>> https://commitfest.postgresql.org/action/commitfest_view/open
>
> Anyone else finding that logging in at commitfest.postgresql.org fails?
> I get
>
> Int
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > commitfest.postgresql.org is updated, please submit new patches at
> > https://commitfest.postgresql.org/action/commitfest_view/open
>
> Anyone else finding that logging in at commitfest.postgresql.org fails?
> I get
>
> Internal S
Robert Haas writes:
> commitfest.postgresql.org is updated, please submit new patches at
> https://commitfest.postgresql.org/action/commitfest_view/open
Anyone else finding that logging in at commitfest.postgresql.org fails?
I get
Internal Server Error
The server encountered an internal error o
commitfest.postgresql.org is updated, please submit new patches at
https://commitfest.postgresql.org/action/commitfest_view/open
Initial reviewing assignments have been sent to -rrreviewers. If you
didn't get one due to an oversight on my part, please drop me a note!
Thanks,
...Robert
[P.S. I
ljb writes:
> Two possible suggested fixes to src/backend/libpq/md5.c, pg_md5_crypt():
> 1) Allocate crypt_buf to (passwd_len + 1 + salt_len)
> 2) Use memcpy(crypt_buf, passwd, passwd_len) not strcpy(crypt_buf, passwd).
> I like fix #2 better, although fix #1 avoids a weirdness with
> PQencryptPa
David Fetter wrote:
On Mon, Sep 14, 2009 at 06:55:52PM -0400, Andrew Dunstan wrote:
David Fetter wrote:
On Mon, Sep 14, 2009 at 03:14:57PM -0700, Josh Berkus wrote:
Hackers,
I've just had a feature request from a client that we come up with
a way to enable JSON input into hst
A trivial little fix for PostgreSQL-8.4.1.
Calling the libpq function PQencryptPassword(password, "") doesn't make
a lot of sense (empty string for username). But if you do, it results
in a 1-byte buffer overflow in pg_md5_encrypt(). (This is in
backend/libpq/md5.c, but it's client, not backend.)
On Mon, Sep 14, 2009 at 7:42 PM, David E. Wheeler wrote:
> On Sep 14, 2009, at 4:32 PM, Robert Haas wrote:
>
>>> What's wrong with just using a variant of the type input function? With
>>> a parameterized insert, it doesn't seem like it's really placing much of
>>> a burden on the application.
>>
On Sep 14, 2009, at 4:32 PM, Robert Haas wrote:
What's wrong with just using a variant of the type input function?
With
a parameterized insert, it doesn't seem like it's really placing
much of
a burden on the application.
Agreed, I was thinking the same thing.
And the type output functio
On Mon, Sep 14, 2009 at 6:25 PM, David E. Wheeler wrote:
>> I don't necessarily try to assign people back to the same patches - I
>> think sometimes a fresh pair of eyes is useful. But I'm not dead set
>> on changing it up, either.
>
> Yeah, but I *love* this patch! :-)
Fair enough. Sold.
...R
On Sep 14, 2009, at 7:05 PM, Jeff Davis wrote:
On Mon, 2009-09-14 at 15:14 -0700, Josh Berkus wrote:
Hackers,
I've just had a feature request from a client that we come up with
a way
to enable JSON input into hstore. This would make hstore much more
useful for software developers.
First
On Mon, Sep 14, 2009 at 06:55:52PM -0400, Andrew Dunstan wrote:
> David Fetter wrote:
>> On Mon, Sep 14, 2009 at 03:14:57PM -0700, Josh Berkus wrote:
>>> Hackers,
>>>
>>> I've just had a feature request from a client that we come up with
>>> a way to enable JSON input into hstore. This would make
On Mon, 2009-09-14 at 15:14 -0700, Josh Berkus wrote:
> Hackers,
>
> I've just had a feature request from a client that we come up with a way
> to enable JSON input into hstore. This would make hstore much more
> useful for software developers.
>
> First question: would this go in the language d
On Sep 14, 2009, at 1:02 PM, Pavel Stehule wrote:
2009/9/14 Merlin Moncure :
On Mon, Sep 14, 2009 at 1:42 PM, Pavel Stehule
wrote:
How is it any worse than what people can already do? Anyone who
isn't aware
of the dangers of SQL injection has already screwed themselves.
You're
basically
David Fetter writes:
> On Mon, Sep 14, 2009 at 03:14:57PM -0700, Josh Berkus wrote:
>> I've just had a feature request from a client that we come up with a
>> way to enable JSON input into hstore. This would make hstore much
>> more useful for software developers.
>>
>> First question: would thi
David Fetter wrote:
On Mon, Sep 14, 2009 at 03:14:57PM -0700, Josh Berkus wrote:
Hackers,
I've just had a feature request from a client that we come up with a
way to enable JSON input into hstore. This would make hstore much
more useful for software developers.
First question: would this
Latest hstore patch with provision for inplace upgrading.
--
Andrew (irc:RhodiumToad)
hstore-20090914.patch.gz
Description: hstore patch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On Mon, Sep 14, 2009 at 03:14:57PM -0700, Josh Berkus wrote:
> Hackers,
>
> I've just had a feature request from a client that we come up with a
> way to enable JSON input into hstore. This would make hstore much
> more useful for software developers.
>
> First question: would this go in the lan
On Mon, Sep 14, 2009 at 4:41 PM, David E. Wheeler wrote:
> On Sep 14, 2009, at 12:37 PM, gabrielle wrote:
>
>> All systems are go!
>>
>> Date: Sept 15
>> Time: 6pm - 9pm PDT, which is GMT -7.
>>
>> We have 6 attendees. Robert Haas is going to choose 4 patches for us.
>> Can somebody volunteer to
On Sep 14, 2009, at 3:22 PM, Robert Haas wrote:
I might be able to make it. I expect to have the hstore patch to
review (I
reviewed it last fest).
It has not been resubmitted for this CommitFest.
He told me a few hours ago that he was working to get it done. Looks
like there's about 90 m
I think the issue is that we treat TIMESTAMP WITHOUT TIME ZONE as TIMESTAMP
at GMT. We then convert it to a users local timezone within application
code.
Scott Mohekey
Systems/Application Specialist – OnTrack – Telogis, Inc.
www.telogis.com www.telogis.co.nz
+1 949 625-4115 ext. 207 (USA) +64 333
Hackers,
I've just had a feature request from a client that we come up with a way
to enable JSON input into hstore. This would make hstore much more
useful for software developers.
First question: would this go in the language driver, libpq, or the
backend? Thoughts?
--
Josh Berkus
PostgreSQL
Petr,
> It's not as easy to do the original idea of setting default privileges
> for schema for all users with CREATE privilege on schema but it can
> still be done, one just have to update default privileges every time
> somebody is granted that privilege, and DBA can still have control over
> it
On Sep 14, 2009, at 12:37 PM, gabrielle wrote:
All systems are go!
Date: Sept 15
Time: 6pm - 9pm PDT, which is GMT -7.
We have 6 attendees. Robert Haas is going to choose 4 patches for us.
Can somebody volunteer to hang out on IRC in case we have questions?
I might be able to make it. I exp
On Mon, Sep 14, 2009 at 3:31 PM, Andrew Chernow wrote:
actually, Tom said: "it's hard to be sure which way is
actually more convenient without having tried coding some likely
calling scenarios both ways."
>>> Aahhh, correct you are Daniel son :)
>>>
>>
>> ??? don't understand y
Jaime Casanova writes:
> On Mon, Sep 14, 2009 at 1:55 PM, Tom Lane wrote:
>> Exports.txt numbers do not change. Â EVER.
> i didn't find any info about it, not even in the sources... should we
> document that we need to put some functions in that file and for what
> reasons?
Every function that
actually, Tom said: "it's hard to be sure which way is
actually more convenient without having tried coding some likely
calling scenarios both ways."
Aahhh, correct you are Daniel son :)
??? don't understand you ???
From the movie "karate kid"; oopps, should be Daniel San. I was trying
to
Robert Haas writes:
> On Mon, Sep 14, 2009 at 3:25 PM, Emmanuel Cecchet wrote:
>> I have never looked at the psql code but that could be a good way to get
>> started on that. If you can point me at where to look at, I'll give it a
>> try.
> I don't know either off the top of my head, but I'll go
On Mon, Sep 14, 2009 at 2:20 PM, Andrew Chernow wrote:
> Jaime Casanova wrote:
>>
>> On Mon, Sep 14, 2009 at 1:34 PM, Andrew Chernow wrote:
>>>
>>> Jaime Casanova wrote:
i extracted the functions to connect that Heikki put on psql in his
patch for determining client_encoding from c
On Mon, Sep 14, 2009 at 1:55 PM, Tom Lane wrote:
> Jaime Casanova writes:
>> i put the new function at the end of the exports.txt file, there's a
>> reason to renumber the exports to put it at the beginning with the
>> other PQconnectdb function?
>
> Exports.txt numbers do not change. EVER.
>
i
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, and you certainly have not made
a case why we should change it. I can't see any reason why pushing
functionality ou
On Mon, Sep 14, 2009 at 3:25 PM, Emmanuel Cecchet wrote:
> Robert Haas wrote:
>>
>> On Mon, Sep 14, 2009 at 2:51 PM, Emmanuel Cecchet
>> wrote:
>>
>>>
>>> This looks good. Shoud I try to elaborate on that for the patch with
>>> error
>>> logging and autopartitioning in COPY?
>>>
>>
>> That make s
On Mon, Sep 14, 2009 at 21:56, Guillaume Smet wrote:
> Hi Magnus,
>
> On Mon, Sep 14, 2009 at 9:41 PM, Magnus Hagander wrote:
>> First, the patch removes the logging_collector parameter and basically
>> assumes that logging_collector is always on.
>
> Alvaro commited this a few days ago:
> http:/
Hi Magnus,
On Mon, Sep 14, 2009 at 9:41 PM, Magnus Hagander wrote:
> First, the patch removes the logging_collector parameter and basically
> assumes that logging_collector is always on.
Alvaro commited this a few days ago:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml?
On Mon, 2009-09-14 at 20:24 +0900, Fujii Masao wrote:
> The latest patch has overcome those problems:
Well done. I hope to look at it myself in a few days time.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
Emmanuel Cecchet wrote:
Greg Smith wrote:
On Fri, 11 Sep 2009, Emmanuel Cecchet wrote:
I guess the problem with extra or missing columns is to make sure
that you know exactly which data belongs to which column so that you
don't put data in the wrong columns which is likely to happen if
thi
On Fri, Jul 10, 2009 at 4:06 PM, Josh Berkus wrote:
> Gabrielle of PDXPUG volunteered that PUG to hold a "code sprint" in
> coordination with a commitfest sometime soon. For that event, the PDXPUG
> members would take on a dozen or so patches, compile and review them and
> submit the results.
Al
Josh Berkus wrote:
But if I understood Tom's suggestions correctly then his approach does
not solve this at all since every one of those users with CREATE TABLE
privileges would have to also set same DEFAULT PRIVILEGES and the dba
would have no say in the matter.
This latter approach benef
Robert Haas wrote:
On Mon, Sep 14, 2009 at 2:51 PM, Emmanuel Cecchet wrote:
This looks good. Shoud I try to elaborate on that for the patch with error
logging and autopartitioning in COPY?
That make sense to me. You shouldn't need to do anything else in
gram.y; whatever you want to a
Replying to myself...
Jeff suggested to build pages in local memory and insert them later in the
table. This is what's used in CLUSTER for instance, I believe.
It has some drawbacks though :
- To insert the tuples in indexes, the tuples need tids, but if you build
the page in local memory
Jaime Casanova wrote:
On Mon, Sep 14, 2009 at 1:34 PM, Andrew Chernow wrote:
Jaime Casanova wrote:
i extracted the functions to connect that Heikki put on psql in his
patch for determining client_encoding from client locale and put it in
libpq so i follow the PQconnectdbParams(* params[]) appr
On Mon, Sep 14, 2009 at 2:51 PM, Emmanuel Cecchet wrote:
> This looks good. Shoud I try to elaborate on that for the patch with error
> logging and autopartitioning in COPY?
That make sense to me. You shouldn't need to do anything else in
gram.y; whatever you want to add should just involve chan
Have you looked at the total execution time with and without the
LWLOCK_TIMING_STATS?
It didn't show any significant overhead on the little COPY test I made.
On selects, it probably does (just like EXPLAIN ANALYZE), but I didn't
test.
It is not meant to be always active, it's a #define,
Jaime Casanova writes:
> i put the new function at the end of the exports.txt file, there's a
> reason to renumber the exports to put it at the beginning with the
> other PQconnectdb function?
Exports.txt numbers do not change. EVER.
regards, tom lane
--
Sent via pgsql
On Mon, Sep 14, 2009 at 1:34 PM, Andrew Chernow wrote:
> Jaime Casanova wrote:
>>
>> i extracted the functions to connect that Heikki put on psql in his
>> patch for determining client_encoding from client locale and put it in
>> libpq so i follow the PQconnectdbParams(* params[]) approach.
>
[...
This looks good. Shoud I try to elaborate on that for the patch with
error logging and autopartitioning in COPY?
manu
Robert Haas wrote:
Here's a half-baked proof of concept for the above approach. This
probably needs more testing than I've given it, and I haven't
attempted to fix the psql pa
Greg Smith wrote:
On Fri, 11 Sep 2009, Emmanuel Cecchet wrote:
I guess the problem with extra or missing columns is to make sure
that you know exactly which data belongs to which column so that you
don't put data in the wrong columns which is likely to happen if this
is fully automated.
All
Jaime Casanova wrote:
On Thu, Sep 10, 2009 at 12:01 AM, Jaime Casanova
wrote:
On Mon, Jul 6, 2009 at 10:00 AM, Heikki
Linnakangas wrote:
Could we
have a version of PQconnectdb() with an API more suited for setting the
params programmatically? The PQsetdbLogin() approach doesn't scale as
parame
On Thu, Sep 10, 2009 at 12:01 AM, Jaime Casanova
wrote:
> On Mon, Jul 6, 2009 at 10:00 AM, Heikki
> Linnakangas wrote:
>>
>> Could we
>> have a version of PQconnectdb() with an API more suited for setting the
>> params programmatically? The PQsetdbLogin() approach doesn't scale as
>> parameters ar
Grzegorz Jaskiewicz wrote:
Anyone knows what's the latest on that patch ?
To be honest, this was the thing that I was looking forward most in
8.5 ... (and probably not only me alone).
We are also interested in integrating our autopartitioning patch for
COPY with that implementation. I can help
2009/9/14 Merlin Moncure :
> On Mon, Sep 14, 2009 at 1:42 PM, Pavel Stehule
> wrote:
>>> How is it any worse than what people can already do? Anyone who isn't aware
>>> of the dangers of SQL injection has already screwed themselves. You're
>>> basically arguing that they would put a variable insi
Fujii Masao wrote:
> Here is the latest version of Streaming Replication (SR) patch.
The first thing that caught my eye is that I don't think "replication"
should be a real database. Rather, it should by a keyword in
pg_hba.conf, like the existing "all", "sameuser", "samerole" keywords
that you ca
Heikki Linnakangas wrote:
> Kevin Grittner wrote:
>> IMO, it would be best if the status could be sent via NOTIFY.
>
> To where?
To registered listeners?
I guess I should have worded that as "it would be best if a change is
replication status could be signaled via NOTIFY" -- does that satis
On Mon, Sep 14, 2009 at 1:42 PM, Pavel Stehule wrote:
>> How is it any worse than what people can already do? Anyone who isn't aware
>> of the dangers of SQL injection has already screwed themselves. You're
>> basically arguing that they would put a variable inside of quotes, but they
>> would nev
2009/9/14 decibel :
> On Sep 14, 2009, at 12:13 AM, Pavel Stehule wrote:
>>
>> 2009/9/13 decibel :
>>>
>>> On Sep 12, 2009, at 5:54 PM, Andrew Dunstan wrote:
decibel wrote:
>
> Speaking of concatenation...
>
> Something I find sorely missing in plpgsql is the ability to pu
On Sep 14, 2009, at 1:36 AM, Greg Smith wrote:
CASE
WHEN c1.relkind='r' THEN 'table'
WHEN c1.relkind='i' THEN 'index'
WHEN c1.relkind='S' THEN 'sequence'
WHEN c1.relkind='v' THEN 'view'
WHEN c1.relkind='c' THEN 'composite'
WHEN c1.relkind='t' THEN 'TOAST'
ELSE '?'
Anyone knows what's the latest on that patch ?
To be honest, this was the thing that I was looking forward most in
8.5 ... (and probably not only me alone).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
On 14 Sep 2009, at 06:04, Tom Lane wrote:
Looks like the clang guys still have some work to do.
Thanks Tom, reported to clang dev's .
meanwhile, since quite a lot stuff went in over weekend, and since
Yesterday, new report at:
http://zlew.org/postgresql_static_check/scan-build-2009-09-1
Kevin Grittner wrote:
> Greg Smith wrote:
>> I don't think running that program going to fly for a production
>> quality integrated replication setup though. The UI admins are
>> going to want would allow querying this easily via a standard
>> database query. Most monitoring systems can issue ps
On Sep 14, 2009, at 12:13 AM, Pavel Stehule wrote:
2009/9/13 decibel :
On Sep 12, 2009, at 5:54 PM, Andrew Dunstan wrote:
decibel wrote:
Speaking of concatenation...
Something I find sorely missing in plpgsql is the ability to put
variables inside of a string, ie:
DECLARE
v_table text := .
Scott Mohekey wrote:
> What is the relationship between Timestamp and TimestampTz?
TIMESTAMP WITHOUT TIME ZONE does not identify a moment in time without
first associating it with a time zone. When Daylight Saving Time
ends, the same TIMESTAMP WITHOUT TIME ZONE values will recur, without
any
>> So the question I would ask goes more like "do you really need 32K
>> databases in one installation? Have you considered using schemas
>> instead?" Databases are, by design, pretty heavyweight objects.
>
> I agree, but at the same time, we might: a) update our documentation to
> indicate it
Greg Smith wrote:
> Putting on my DBA hat for a minute, the first question I see people
> asking is "how do I measure how far behind the slaves are?".
> Presumably you can get that out of pg_controldata; my first question
> is whether that's complete enough information? If not, what else
> sho
Peter,
> This is what the attached patch produces.
>
> Comments?
This is how other project handle transation of these kinds of strings.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
Greg Smith wrote:
This is looking really neat now, making async replication really solid
first before even trying to move on to sync is the right way to go
here IMHO.
I agree with both of those sentiments.
One question I have is what is the level of traffic involved between the
master and
On Mon, Sep 14, 2009 at 11:56 AM, Pavel Stehule wrote:
> 2009/9/14 Steve Prentice :
>> On Sep 13, 2009, at 10:22 PM, Pavel Stehule wrote:
>>
>>> 2009/9/14 Tom Lane :
Robert Haas writes:
>
> So, I guess I'm sadly left feeling that we should probably reject this
> patch. Anyo
2009/9/14 Steve Prentice :
> On Sep 13, 2009, at 10:22 PM, Pavel Stehule wrote:
>
>> 2009/9/14 Tom Lane :
>>>
>>> Robert Haas writes:
So, I guess I'm sadly left feeling that we should probably reject this
patch. Anyone want to argue otherwise?
>>>
>>> +1. I'm really hoping to get
Greg Smith wrote:
> Putting on my DBA hat for a minute, the first question I see people
> asking is "how do I measure how far behind the slaves are?". Presumably
> you can get that out of pg_controldata; my first question is whether
> that's complete enough information? If not, what else should b
This is looking really neat now, making async replication really solid
first before even trying to move on to sync is the right way to go here
IMHO. I just cleaned up the docs on the Wiki page, when this patch is
closer to being committed I officially volunteer to do the same on the
internal S
On Mon, Sep 14, 2009 at 11:02 AM, Steve Prentice wrote:
> On Sep 13, 2009, at 10:22 PM, Pavel Stehule wrote:
>
>> 2009/9/14 Tom Lane :
>>>
>>> Robert Haas writes:
So, I guess I'm sadly left feeling that we should probably reject this
patch. Anyone want to argue otherwise?
>>>
>>>
On Sep 13, 2009, at 10:22 PM, Pavel Stehule wrote:
2009/9/14 Tom Lane :
Robert Haas writes:
So, I guess I'm sadly left feeling that we should probably reject
this
patch. Anyone want to argue otherwise?
+1. I'm really hoping to get something done about the plpgsql
parsing
situation be
2009/9/14 Pierre Frédéric Caillaud
>
> A little bit of a reply to Jeff's email about WALInsertLock.
>
> This patch instruments LWLocks, it is controlled with the following
> #define's in lwlock.c :
>
> LWLOCK_STATS
> LWLOCK_TIMING_STATS
>
> It is an upgrade of current lwlocks stats.
>
Hi Pierre,
>Martijn van Oosterhout wrote:
> FWIW, I find the ability in Slony to configure triggers so they work
> or not depending on the replication role to be extremely useful.
> Absolutely a major positive feature.
Yeah, as a general rule it doesn't make sense to try to enforce
constraints on a replica
I've done a little experiment with bulk inserts.
=> heap_bulk_insert()
Behaves like heap_insert except it takes an array of tuples (HeapTuple
*tups, int ntups).
- Grabs a page (same as heap_insert)
- While holding exclusive lock, inserts as many tuples as it can on the
page.
- E
Itagaki Takahiro wrote:
> We can choose different encodings from platform-dependent one
> for database, but postgres writes serverlogs in the database encoding.
> As the result, serverlogs are filled with broken characters.
>
> The problem could occur on all platforms, however, there is a solution
A little bit of a reply to Jeff's email about WALInsertLock.
This patch instruments LWLocks, it is controlled with the following
#define's in lwlock.c :
LWLOCK_STATS
LWLOCK_TIMING_STATS
It is an upgrade of current lwlocks stats.
When active, at backend exit, it will display stats as shown
Hello Robert,
2009/9/14 Robert Haas :
> On Mon, Aug 24, 2009 at 3:19 PM, Pavel Stehule
> wrote:
>> I reworked patch to respect mentioned issues. - this patch still
>> implement mixed notation - I am thing so this notation is really
>> important. All others I respect. The behave is without change
On Sun, 2009-09-13 at 19:08 +1000, Brendan Jurd wrote:
> The September CF starts in a couple of days, so this patch is in
> danger of missing the boat.
Thanks for keeping track. I accomplished a significant amount today, so
there's still hope for 9/15.
I will most likely just focus on the core fu
On Mon, 2009-08-17 at 10:22 -0400, Tom Lane wrote:
> As always with patches that are meant to improve performance,
> some experimental evidence would be a good thing.
I haven't had time to performance test this patch yet, and it looks like
it will take a significant amount of effort to do so. I'm
On Mon, Sep 14, 2009 at 02:43, 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 sys
On Mon, Sep 14, 2009 at 02:16, Itagaki Takahiro
wrote:
>
> Tom Lane wrote:
>
>> Itagaki Takahiro writes:
>> > Can I reorder them to ERROR > WARNING > LOG ?
>>
>> No. That was an intentional decision. LOG is for stuff that we
>> really want to get logged, in most cases. ERROR is very often not
98 matches
Mail list logo
