Heikki Linnakangas writes:
> Yeah, a lot of that logic and states is completely unnecessary until we
> have a synchronous mode. Even then, it seems complex.
I hope we'll find something less complex, what I proposed is heavily
inspired from londiste (Skytools) table addition to a replication set
(
Dimitri Fontaine wrote:
Heikki Linnakangas writes:
Yeah, a lot of that logic and states is completely unnecessary until we
have a synchronous mode. Even then, it seems complex.
I hope we'll find something less complex, what I proposed is heavily
inspired from londiste (Skytools) table
On Jan 21, 2010, at 12:35 PM, David E. Wheeler wrote:
> And where do you think baby powder comes from? Sheesh.
You won the thread!
eric
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On tor, 2010-01-21 at 17:06 -0500, Robert Haas wrote:
> But let me ask this. For which
> release were you hoping to make this change? If 9.0, then it seems to
> me that you've missed the deadline, which - according to my
> understanding of the agreed-upon schedule - was six days ago.
By that log
Peter Eisentraut wrote:
But I don't think that should mean everyone has to drop everything when
the clock strikes midnight and must now only look at things that the
magic commitfest page has pre-approved.
Well, we used to have the idea of a feature freeze ... is that going to
apply at t
Why does warn; in plperl log as NOTICE in Postgres?
On a related note, what's the logic behind perl DEBUG logging as DEBUG2 instead
of DEBUG1 or DEBUG5? Still seems kind of odd, but at least nowhere near as
surprising as warn becoming NOTICE...
--
Jim C. Nasby, Database Architect
On Jan 21, 2010, at 3:05 PM, Andrew Dunstan wrote:
> Well, we used to have the idea of a feature freeze ... is that going to apply
> at the end of the commitfest?
>
> I generally agree that we need to have a bit of wiggle room at this stage -
> small and non-controversial items can be allowed t
On Fri, Jan 22, 2010 at 12:29 AM, Andrew Chernow wrote:
>
>>> 9.0.
>>>
>>
>> You don't have a code-name. All the cool kids have code-names for their
>> projects.
>>
>>
> Black Dog
>
> yup, I'm a zeppelin fan :)
>
+1
:)
--
Regards,
Michael Paquier
NIPPON TELEGRAPH AND
TELEPHONE CORPORATION
NTT
Andrew Dunstan writes:
> Peter Eisentraut wrote:
>> But I don't think that should mean everyone has to drop everything when
>> the clock strikes midnight and must now only look at things that the
>> magic commitfest page has pre-approved.
> Well, we used to have the idea of a feature freeze ...
Tom Lane wrote:
> If you want an example of something I *do* have a process problem
> with, it's Kevin Grittner's attempts to get people to put a
> significant number of cycles into thinking about true
> serializability.
> Right now is not the time for that to be happening. I've been
> politely
One other point about this, before anyone asks: we will of course have
to go through the source code and docs to s/8.5/9.0/. The plan is to do
that between the conclusion of the current commitfest and the release of
the final alpha version (which will therefore call itself 9.0alpha4 not
8.5alpha4)
Tom Lane wrote:
> If you want an example of something I *do* have a process problem
> with, it's Kevin Grittner's attempts
Hmmm Plural? I've made exactly one post on the subject since
the CF started, unless you count review of Markus's dtester code,
which he posted before the CF but didn
Jim Nasby wrote:
Why does warn; in plperl log as NOTICE in Postgres?
On a related note, what's the logic behind perl DEBUG logging as DEBUG2 instead
of DEBUG1 or DEBUG5? Still seems kind of odd, but at least nowhere near as
surprising as warn becoming NOTICE...
Where would you like the
On Thursday 21. January 2010 10.37.41 Dave Page wrote:
> In an attempt to pre-empt the normally drawn-out discussions about
> what the next version of PostgreSQL will be numbered. the core team
> have discussed the issue and following a lenghty debate lasting
> literally a few minutes decided that
(2010/01/21 19:42), Takahiro Itagaki wrote:
>
> KaiGai Kohei wrote:
>
>>> I'm not sure whether we need to make groups for each owner of large objects.
>>> If I remember right, the primary issue was separating routines for dump
>>> BLOB ACLS from routines for BLOB COMMENTS, right? Why did you mak
On Thu, January 21, 2010 5:53 pm, Andreas Joseph Krogh wrote:
> On Thursday 21. January 2010 10.37.41 Dave Page wrote:
>> In an attempt to pre-empt the normally drawn-out discussions about
>> what the next version of PostgreSQL will be numbered. the core team
>> have discussed the issue and follow
"Kevin Grittner" writes:
> Tom Lane wrote:
>> If you want an example of something I *do* have a process problem
>> with, it's Kevin Grittner's attempts
> Hmmm Plural? I've made exactly one post on the subject since
> the CF started, unless you count review of Markus's dtester code,
> whic
On Thu, Jan 21, 2010 at 7:11 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> If you want an example of something I *do* have a process problem
>>> with, it's Kevin Grittner's attempts
>
>> Hmmm Plural? I've made exactly one post on the subject since
>> the CF started,
Andrew Dunstan writes:
> Jim Nasby wrote:
>> Why does warn; in plperl log as NOTICE in Postgres?
> Where would you like the warning to go? This has been this way for
> nearly 5 years, it's not new (and before that the warning didn't go
> anywhere).
I think he's suggesting that it ought to tran
"Larry Rosenman" writes:
> On Thu, January 21, 2010 5:53 pm, Andreas Joseph Krogh wrote:
>> Care to shed some light on what features (yes, we users care about
>> features) warrant this major version-bump? Is there a link somewhere?
> AFAIR, it was stated if Hot Standby AND Streaming Replication h
Tom Lane wrote:
> What I do think is that the quoted code snippet has no business being
> outside the planner proper. It'd be better to put it in planner.c
> or someplace like that.
Ah, I see. My concern was the dummy planner approach is using internal
functions of planner. It would be better
On Thu, Jan 21, 2010 at 5:35 PM, Peter Eisentraut wrote:
> On tor, 2010-01-21 at 17:06 -0500, Robert Haas wrote:
>> But let me ask this. For which
>> release were you hoping to make this change? If 9.0, then it seems to
>> me that you've missed the deadline, which - according to my
>> understand
Tom Lane wrote:
Andrew Dunstan writes:
Jim Nasby wrote:
Why does warn; in plperl log as NOTICE in Postgres?
Where would you like the warning to go? This has been this way for
nearly 5 years, it's not new (and before that the warning didn't go
anywhere).
I think h
On 01/11/2010 07:43 PM, Takahiro Itagaki wrote:
> There is a memory leak in dblink when we cancel a query during
> returning tuples. It could leak a PGresult because memory used
> by it is not palloc'ed one. I wrote a patch[1] before, but I've
> badly used global variables to track the resource.
>
On 01/21/2010 04:46 AM, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
>> Magnus Hagander wrote:
>>> 2010/1/17 Heikki Linnakangas :
We could replace the blocking PQexec() calls with PQsendQuery(), and use
the emulated version of select() to wait.
>>> Hmm. That would at least theor
Robert Haas wrote:
> people get bogged down and don't have time to finish the work.
Ok, I moved this patch to the next commit fest for 9.1 alpha 1.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On Jan 21, 2010, at 4:02 PM, Eric B. Ridge wrote:
> On Jan 21, 2010, at 12:35 PM, David E. Wheeler wrote:
>
>> And where do you think baby powder comes from? Sheesh.
>
> You won the thread!
Heh, who's the wise guy that posted the second comment on
http://www.betanews.com/article/EU-clears-Oracl
Tom Lane wrote:
> Now your original posts back in December were okay, since you were
> just letting people know that you intended to work on this over a
> long period. But IIRC you've made more than one post with actual
> code in it that you seemed to be hoping people would review, and
> that I
"Kevin Grittner" writes:
> Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> So add me to the list of people who think that if
>>> these are going to be recurring, we should look at moving from
>>> cvs to git as soon as 9.0 is released.
>>
>> The gating factor is not release schedule; it is the s
On Jan 21, 2010, at 4:55 PM, Andrew Dunstan wrote:
> *shrug* I don't have a strong opinion about it, and it's pretty easy to
> change, if there's a consensus we should. I have certainly found over the
> years that perl warnings from some modules can be annoyingly verbose, which
> is probably wh
On Thu, Jan 21, 2010 at 2:25 PM, Pavel Stehule wrote:
> 2010/1/21 Robert Haas :
>> On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule
>> wrote:
>>> add to state structure field like lexer_error. This field will be
>>> checked before execution
>>> it could be ugly for metacommands, there will be lot
The attached patch is a revised version.
List of updates:
- cleanup: getBlobs() was renamed to getBlobOwners()
- cleanup: BlobsInfo was renamed to BlobOwnerInfo
- bugfix: pg_get_userbyid() in SQLs were replaced by username_subquery which
constins a right subquery to obtain a username for
Joe Conway wrote:
> +#ifdef WIN23
> ^
> I assume you meant WIN32 here ;-)
Yeah. I admit I haven't tested this on Windows, I just commented out
those #ifdef's and tested on Linux. Will need to verify that this
actually solves the problem on Windows before committing.
> +#define PQexec(
On 01/21/2010 10:33 PM, Heikki Linnakangas wrote:
> Joe Conway wrote:
>> I have not been really following this thread, but why can't we put the
>> "#ifdef WIN32" and special definition of these functions into libpq. I
>> don't understand why we need special treatment for dblink.
>
> The problem is
2010/1/22 Robert Haas :
> On Thu, Jan 21, 2010 at 2:25 PM, Pavel Stehule
> wrote:
>> 2010/1/21 Robert Haas :
>>> On Thu, Jan 21, 2010 at 12:53 PM, Pavel Stehule
>>> wrote:
add to state structure field like lexer_error. This field will be
checked before execution
it could be ugly
Joe Conway wrote:
> OK, so now I see why we want this fixed for dblink and walreceiver, but
> doesn't this approach leave every other WIN32 libpq client out in the
> cold? Is there nothing that can be done for the general case, or is it a
> SMOP?
The problem only applies to libpq calls from the ba
101 - 136 of 136 matches
Mail list logo
