On Sat, Sep 4, 2010 at 5:02 AM, Josh Berkus wrote:
> (a) seems easily enough solved by giving two steps: giving the DBA a way
> to check where in the replication stream each standby is (I think we
> already have this)
Yep, pg_last_xlog_receive_location would help.
> The second method would be by
OT:
OFF TOPIC:
I honestly do not mean any offence, just out of curiosity.
If you guys care about money and time why would you spend the best years of
your
life basically copying commercial products for free? Because for a person with
higher than average IQ far less than one percent of any pro
2010/9/6 Itagaki Takahiro :
> On Wed, Sep 1, 2010 at 1:29 PM, Pavel Stehule wrote:
>>> * %v also doesn't quote boolean values, but t and f are not valid.
>>> You should use true and false (or 't' and 'f') for the cases.
>>
>> you have a true - it should be fixed
>
> I found quote_literal() prints
On 03/09/10 21:50, Tom Lane wrote:
Heikki Linnakangas writes:
On 03/09/10 21:16, Tom Lane wrote:
It's probably not too unreasonable to assume that pid_t assignment is
atomic. But I'm still thinking that we have bigger problems than that
if there are really cases where SetLatch can execute at
On Wed, Sep 1, 2010 at 1:29 PM, Pavel Stehule wrote:
>> * %v also doesn't quote boolean values, but t and f are not valid.
>> You should use true and false (or 't' and 'f') for the cases.
>
> you have a true - it should be fixed
I found quote_literal() prints boolean values as 'true' or 'false'.
Michael Haggerty writes:
> Tom Lane wrote:
>> I suspect what it's doing is attributing the branch creation to the user
>> who makes the first commit on the branch for that file. In general I'd
>> expect that to give a reasonable result --- better than choosing a
>> guaranteed-to-be-wrong constant
Tom Lane wrote:
> Michael Haggerty writes:
>> CVS does not record when a branch was created or by whom. If a git
>> commit has to be created for such events, cvs2git attributes them to a
>> configurable username, which Max has set to be "pgsql". It chooses the
>> latest possible timestamp that i
Michael Haggerty writes:
> Tom Lane wrote:
>> [...] The only real gripe I can find to make is that in the cases where
>> a file is added to a back branch, the "manufactured" commit is
>> invariably blamed on committer "pgsql". Can't we arrange to blame it
>> on the person who actually added the f
Tom Lane wrote:
> Max Bowsher writes:
>> For both, see http://github.com/maxb
>
> [...] The only real gripe I can find to make is that in the cases where
> a file is added to a back branch, the "manufactured" commit is
> invariably blamed on committer "pgsql". Can't we arrange to blame it
> on t
On 9/5/2010 2:05 PM, Heikki Linnakangas wrote:
On 04/09/10 17:16, Merlin Moncure wrote:
Curious: is mulitset handling as you see it supported by the current
v3 protocol?
The manual says:
The response to a SELECT query (or other queries that return row sets, such as
EXPLAIN or SHOW) normally
Max Bowsher writes:
> On 05/09/10 03:55, Robert Haas wrote:
>>> Can you post the repo you ended up with somewhere?
> For both, see http://github.com/maxb
I took the trouble to run through a mechanical diff of this version's
REL8_3_STABLE log history versus what I get from cvs2cl. Several cvs2cl
On sön, 2010-09-05 at 11:35 -0400, Tom Lane wrote:
> Dean Rasheed writes:
> > On 5 September 2010 16:15, Tom Lane wrote:
> >> I don't recall having thought about it one way or the other. What did
> >> the check look like?
>
> > Well originally it was searching indexes rather than constraints, an
On fre, 2010-09-03 at 16:18 -0400, Tom Lane wrote:
> Part of the reason it's sat on TODO is lack of consensus about how
> such a feature ought to look/work; particularly since most of the
> discussion about it has considered that it'd go along with stored
> procedures executing outside of transacti
Heikki Linnakangas writes:
> On 04/09/10 17:16, Merlin Moncure wrote:
>> Curious: is mulitset handling as you see it supported by the current
>> v3 protocol?
> If a multiple return sets from a procedure are returned just like
> multiple return sets from multiple queries, that's already covered b
On 04/09/10 17:16, Merlin Moncure wrote:
Curious: is mulitset handling as you see it supported by the current
v3 protocol?
The manual says:
The response to a SELECT query (or other queries that return row sets, such as
EXPLAIN or SHOW) normally consists of RowDescription, zero or more DataR
On Fri, 2010-09-03 at 18:24 -0400, Tom Lane wrote:
> Now the HS case likewise appears to be set up so that the signal can
> only directly interrupt ProcWaitForSignal, so I think the core issue
> is
> whether any deadlock situations are possible. Given that this gets
> called from a low-level place
On Sat, Sep 04, 2010 at 02:42:40PM +0100, Greg Stark wrote:
> On Fri, Sep 3, 2010 at 8:30 PM, Martijn van Oosterhout
> wrote:
> >
> > rsync is not rocket science. All you need is for the receiving end to
> > send a checksum for each block it has. The server side does the same
> > checksum and for
Dean Rasheed writes:
> On 5 September 2010 16:15, Tom Lane wrote:
>> I don't recall having thought about it one way or the other. What did
>> the check look like?
> Well originally it was searching indexes rather than constraints, and
> funcdeps_check_pk() included the following check:
> if (!
On 5 September 2010 16:15, Tom Lane wrote:
> Dean Rasheed writes:
>> On 7 August 2010 03:51, Tom Lane wrote:
>> I was testing out this feature this morning and discovered that the
>> results may be non-deterministic if the PK is deferrable.
>
> Good point.
>
>> The original version of the patch
Dean Rasheed writes:
> On 7 August 2010 03:51, Tom Lane wrote:
> I was testing out this feature this morning and discovered that the
> results may be non-deterministic if the PK is deferrable.
Good point.
> The original version of the patch had that check in it, but it
> vanished from the final
Heikki Linnakangas writes:
> On 04/09/10 22:41, Tom Lane wrote:
>> So we don't need a version check unless you're worried about somebody
>> trying to run Postgres 9.x on OS X 10.2 (which was retired in 2003).
> What happens if someone does? Crash, or just wonky ps output? If it's
> the latter, s
On 7 August 2010 03:51, Tom Lane wrote:
> Peter Eisentraut writes:
>> Next version. Changed dependencies to pg_constraint, removed handling
>> of unique constraints for now, and made some enhancements so that views
>> track dependencies on constraints even in subqueries. Should be close
>> to f
On Sun, Sep 5, 2010 at 1:05 AM, Tom Lane wrote:
> Robert Haas writes:
>> I am not too sure that the distinction between implicit casts and
>> assignment casts is all that useful;
>
> We've been there and done that; it doesn't work. The current scheme
> was invented specifically because a two-way
On Fri, Sep 3, 2010 at 9:20 PM, Heikki Linnakangas
wrote:
> So we now have the same process nested twice inside a semop() call. Looking
> at the Linux signal (7) man page, it is undefined what happens if semop() is
> re-entered in a signal handler while another semop() call is happening in
> main
On 05/09/10 03:55, Robert Haas wrote:
> On Sat, Sep 4, 2010 at 9:17 AM, Max Bowsher wrote:
>>> Can you post the repo you ended up with somewhere?
>>
>> Well, it's a Bazaar repository at the moment :-)
>>
>> But, I'll re-run it targetting git, and push it somewhere. github?
>> anywhere better?
>
>
On 04/09/10 22:41, Tom Lane wrote:
I wrote:
I tried this on a PPC Mac running 10.4.11, which is the oldest Mac OS
I have handy at the moment. It worked fine. The existing coding in
ps_status.c dates from late 2001, which means that it was first tested
against OS X 10.1, and most likely we have
26 matches
Mail list logo
