On Fri, 2012-05-04 at 16:12 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, May 4, 2012 at 3:49 PM, Hannu Krosing wrote:
> >> Can we at least have the xxx_to_json() functions try cast to json first
> >> and fall back to text if the cast fails.
>
> > I think the idea that you can involve
On Fri, 2012-05-04 at 15:59 -0400, Robert Haas wrote:
> On Fri, May 4, 2012 at 3:49 PM, Hannu Krosing wrote:
> > On Fri, 2012-05-04 at 09:52 -0400, Tom Lane wrote:
> >> Hannu Krosing writes:
> >> > On Wed, 2012-05-02 at 12:06 -0700, Andrew Dunstan wrote:
> >> >> So given that do we do anything ab
The new 9.2 GUC parameter temp_file_limit says it restricts temporary
file usage per session, but it doesn't say what happens if a session
needs to exceed that value --- it throws an error. Shouldn't we mention
that?
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Fri, May 04, 2012 at 06:25:24PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, May 04, 2012 at 08:45:10PM +0300, Peter Eisentraut wrote:
> >> I'm not so much opposed to removing the port. I am more concerned about
> >> the manner in which it was done. The other ports I removed wer
Bruce Momjian writes:
> On Fri, May 04, 2012 at 08:45:10PM +0300, Peter Eisentraut wrote:
>> I'm not so much opposed to removing the port. I am more concerned about
>> the manner in which it was done. The other ports I removed were known
>> to not work anyway, for years, and there were at least
On 5/3/12 2:54 PM, Josh Berkus wrote:
(2) If logical transactions had been implemented as additions to
> the WAL stream, and Slony was using that, do you think they would
> still have been usable for this recovery?
Quite possibly not.
The key advantage that I see in londiste/slony replicati
On Fri, May 04, 2012 at 08:45:10PM +0300, Peter Eisentraut wrote:
> On tor, 2012-05-03 at 17:39 +0100, Peter Geoghegan wrote:
> > On 3 May 2012 17:21, Bruce Momjian wrote:
> > > I think I was the only user left; I have never heard from a BSD/OS user
> > > in the past 5-7 years.
> >
> > I'm incli
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Hannu Krosing
> Sent: Friday, May 04, 2012 4:40 PM
> To: Robert Haas
> Cc: Tom Lane; Andrew Dunstan; PostgreSQL-development; Merlin Moncure
> Subject: Re: [HACKERS] JS
On Fri, May 4, 2012 at 8:45 PM, Peter Eisentraut wrote:
> On tor, 2012-05-03 at 17:39 +0100, Peter Geoghegan wrote:
>> On 3 May 2012 17:21, Bruce Momjian wrote:
>> > I think I was the only user left; I have never heard from a BSD/OS user
>> > in the past 5-7 years.
>>
>> I'm inclined to agree wi
On Fri, 2012-05-04 at 15:59 -0400, Robert Haas wrote:
> On Fri, May 4, 2012 at 3:49 PM, Hannu Krosing wrote:
> > On Fri, 2012-05-04 at 09:52 -0400, Tom Lane wrote:
> >> Hannu Krosing writes:
> >> > On Wed, 2012-05-02 at 12:06 -0700, Andrew Dunstan wrote:
> >> >> So given that do we do anything ab
Robert Haas writes:
> On Fri, May 4, 2012 at 3:49 PM, Hannu Krosing wrote:
>> Can we at least have the xxx_to_json() functions try cast to json first
>> and fall back to text if the cast fails.
> I think the idea that you can involve the casting machinery in this is
> misguided.
It is possible
On Fri, May 4, 2012 at 3:49 PM, Hannu Krosing wrote:
> On Fri, 2012-05-04 at 09:52 -0400, Tom Lane wrote:
>> Hannu Krosing writes:
>> > On Wed, 2012-05-02 at 12:06 -0700, Andrew Dunstan wrote:
>> >> So given that do we do anything about this now, or wait till 9.3?
>>
>> > I'd like the json suppor
On Fri, 2012-05-04 at 09:52 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > On Wed, 2012-05-02 at 12:06 -0700, Andrew Dunstan wrote:
> >> So given that do we do anything about this now, or wait till 9.3?
>
> > I'd like the json support in 9.2 updated as follows
>
> I think it's too late to be
On Fri, 2012-05-04 at 13:43 -0400, Robert Haas wrote:
> On Fri, May 4, 2012 at 12:56 PM, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> Yeah, what I've been thinking about in conjunction with similar problems
> >> is some sort of type registry, so that we could code for non-builtin
> >> types in
On 03/05/12 11:04, Jan Urbański wrote:
On 02/05/12 20:18, Peter Eisentraut wrote:
This doesn't work anymore with Python 3:
rv = plpy.execute(...)
do_something(rv[0:1])
Apparently, they changed the C API for doing slicing, or rather made one
of the two APIs for it silently do nothing. Details a
On tor, 2012-05-03 at 15:47 -0400, Bruce Momjian wrote:
> Peter, where are we on this?
I hadn't received any clear feedback, but if no one objects, I can
commit it.
> ---
>
> On Fri, Mar 30, 2012 at 08:16:59PM +0300, Peter E
On tor, 2012-05-03 at 17:39 +0100, Peter Geoghegan wrote:
> On 3 May 2012 17:21, Bruce Momjian wrote:
> > I think I was the only user left; I have never heard from a BSD/OS user
> > in the past 5-7 years.
>
> I'm inclined to agree with Bruce. While it's not reasonable to assume
> that the lack o
On Fri, May 4, 2012 at 12:56 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Yeah, what I've been thinking about in conjunction with similar problems
>> is some sort of type registry, so that we could code for non-builtin
>> types in certain cases. Maybe we should add that the the developers'
>>
On Fri, May 4, 2012 at 12:59 PM, Andres Freund wrote:
> In my understanding - as the person doing quite a bit of the coding atm - the
> point is to provide a very minimal *early* prototype to have a sensible basis
> for design decisions/discussions. On one side thats useful to get a feeling
> for
Hi Robert, Hi all,
On Friday, May 04, 2012 06:29:33 PM Robert Haas wrote:
> On Fri, May 4, 2012 at 11:06 AM, Greg Smith wrote:
> > The straw man argument here would require 100% transparency on everything
> > you do in regards to PostgreSQL and related software. Before doing any
> > development
Josh Berkus writes:
>> How are we handling the Monday release with everyone at PGCon? Was that
>> resolved?
> I have yet to see a confirmed date, guys. If we expect any support from
> the packagers and/or the advocacy volunteers, then people need at least
> a week's notice, probably more.
I ha
Andrew Dunstan writes:
> Yeah, what I've been thinking about in conjunction with similar problems
> is some sort of type registry, so that we could code for non-builtin
> types in certain cases. Maybe we should add that the the developers'
> meeting agenda.
Maybe. I don't want to see a json-s
Hi everybody.
First of all I have to thank you for your wonderful job! PostgreSQL rocks!
I am writing you because I am interested in understanding some specifics related
to PostgreSQL internals. More precisely, I am investigating the running time
of the different function implementation approache
>> Next week, I thought.
>
> How are we handling the Monday release with everyone at PGCon? Was that
> resolved?
I have yet to see a confirmed date, guys. If we expect any support from
the packagers and/or the advocacy volunteers, then people need at least
a week's notice, probably more.
--
On 05/04/2012 09:52 AM, Tom Lane wrote:
Hannu Krosing writes:
On Wed, 2012-05-02 at 12:06 -0700, Andrew Dunstan wrote:
So given that do we do anything about this now, or wait till 9.3?
I'd like the json support in 9.2 updated as follows
I think it's too late to be entertaining proposals fo
On Fri, May 4, 2012 at 11:06 AM, Greg Smith wrote:
> The straw man argument here would require 100% transparency on everything
> you do in regards to PostgreSQL and related software. Before doing any
> development on any code, first post here to ask for design review. And if
> someone asks you t
On 05/04/2012 09:03 AM, Robert Haas wrote:
I try pretty hard not to go off and do large amounts of work in a
vacuum. If something is more than a couple days work, I post the
design on hackers and wait for feedback before writing a line of code.
That is an excellent luxury to have. You've work
On Fri, May 4, 2012 at 10:21 AM, Tom Lane wrote:
> Robert Haas writes:
>> Originally, I thought that the patch should include some kind of
>> accounting mechanism to prevent that from happening, where we'd keep
>> track of the number of fast-path locks that were outstanding and make
>> sure to ke
Robert Haas writes:
> Originally, I thought that the patch should include some kind of
> accounting mechanism to prevent that from happening, where we'd keep
> track of the number of fast-path locks that were outstanding and make
> sure to keep that many slots free in the main lock table, but Noah
On Fri, May 4, 2012 at 9:25 AM, Tom Lane wrote:
> Robert Haas writes:
>> In 9.1, we just did this:
>
>> if (locallock->proclock == NULL || locallock->lock == NULL)
>> {
>> /*
>> * We must've run out of shared memory
On Fri, May 4, 2012 at 9:11 AM, Simon Riggs wrote:
> On 4 May 2012 13:59, Robert Haas wrote:
>> On Fri, May 4, 2012 at 3:35 AM, Simon Riggs wrote:
>>> On Thu, May 3, 2012 at 9:56 PM, Robert Haas wrote:
On Thu, May 3, 2012 at 3:20 PM, Simon Riggs wrote:
> Your two paragraphs have rough
Hannu Krosing writes:
> On Wed, 2012-05-02 at 12:06 -0700, Andrew Dunstan wrote:
>> So given that do we do anything about this now, or wait till 9.3?
> I'd like the json support in 9.2 updated as follows
I think it's too late to be entertaining proposals for such changes in
9.2. If we had concl
Robert Haas writes:
> In 9.1, we just did this:
> if (locallock->proclock == NULL || locallock->lock == NULL)
> {
> /*
> * We must've run out of shared memory while
> trying to set up this
>
On Thu, May 3, 2012 at 5:18 PM, Tom Lane wrote:
> ... btw, it appears to me that the "fast path" patch has broken things
> rather badly in LockReleaseAll. AFAICS it's not honoring either the
> lockmethodid restriction nor the allLocks restriction with respect to
> fastpath locks. Perhaps user lo
On 4 May 2012 14:01, Robert Haas wrote:
> On Fri, May 4, 2012 at 8:32 AM, Hannu Krosing wrote:
>> For logical we don't really need to uniquely identify such rows - it
>> should sufficient if we just update exactly one of the matching rows.
>>
>> The way to do this is to put all fields of the OLD.
On 4 May 2012 13:59, Robert Haas wrote:
> On Fri, May 4, 2012 at 3:35 AM, Simon Riggs wrote:
>> On Thu, May 3, 2012 at 9:56 PM, Robert Haas wrote:
>>> On Thu, May 3, 2012 at 3:20 PM, Simon Riggs wrote:
Your two paragraphs have roughly opposite arguments...
Doing it every 32 pages
On Thu, May 3, 2012 at 8:22 PM, Greg Smith wrote:
> On 05/01/2012 09:09 AM, Robert Haas wrote:
>>
>> I think we ought to be sharing and debugging designs in
>> public, not internally within 2ndQuadrant - or any other company, or
>> any other mailing list other than this one.
>
> OK. You go first.
On Fri, May 4, 2012 at 8:32 AM, Hannu Krosing wrote:
> For logical we don't really need to uniquely identify such rows - it
> should sufficient if we just update exactly one of the matching rows.
>
> The way to do this is to put all fields of the OLD.* tuple in the WHERE
> clause and then update j
On Fri, May 4, 2012 at 3:35 AM, Simon Riggs wrote:
> On Thu, May 3, 2012 at 9:56 PM, Robert Haas wrote:
>> On Thu, May 3, 2012 at 3:20 PM, Simon Riggs wrote:
>>> Your two paragraphs have roughly opposite arguments...
>>>
>>> Doing it every 32 pages would give you 30 seconds to complete the
>>> f
On Thu, 2012-05-03 at 00:58 -0500, Jim Nasby wrote:
> On 4/29/12 6:03 AM, Simon Riggs wrote:
> >> The DML-WITH-LIMIT-1 is required to do single logical updates on tables
> >> > with non-unique rows.
> >> > And as for any logical updates we will have huge performance problem
> >> > when doing UPD
On Wed, 2012-05-02 at 12:06 -0700, Andrew Dunstan wrote:
>
>
> On Wed, May 2, 2012 at 2:29 AM, Hannu Krosing
> wrote:
>
>
>
> I don't object to row_to_json() and array_to_json() functions
> being
> there as a convenience and as the two "official
On 2 May 2012 13:41, Robert Haas wrote:
> So on further reflection I'm thinking it may be best just to stick
> with a hard conflict for now and see what feedback we get from beta
> testers.
Which is what I was expecting y'all to conclude once you'd looked at
the task in more detail.
And I'm hap
On Thu, May 3, 2012 at 9:56 PM, Robert Haas wrote:
> On Thu, May 3, 2012 at 3:20 PM, Simon Riggs wrote:
>> Your two paragraphs have roughly opposite arguments...
>>
>> Doing it every 32 pages would give you 30 seconds to complete the
>> fsync, if you kicked it off when half way through the previo
43 matches
Mail list logo
