This is based on the Kevin's git repo at:
git://git.postgresql.org/git/users/kgrittn/postgres.git
SHA1: 729541fa5ea94d66e6f4b22fb65bfef92214cd6b
* Trivial stuff:
I get a compiler warning:
indexfsm.c: In function ‘RecordFreeIndexPage’:
indexfsm.c:55: warning: implicit declaration of
David Fetter wrote:
Where should we preserve this, other than the mailing list archives?
http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD
has most of the other trivia in this area, so I just added Alvaro's
technique to the bottom of it with
On Wed, Oct 13, 2010 at 04:23:57PM -0700, fazool mein wrote:
> Hello guys,
>
> The concept of time line makes sense to me in the case of asynchronous
> replication. But in case of synchronous replication, I am not so sure.
>
> When a standby connects to the primary, it checks if both have the sam
(2010/10/15 22:04), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
>> However, it requires the plugin modules need to know everything;
>> such as what is visible/invisible. It seems to me too closely-
>> coupled interface.
>
> I agree with Robert on this one. We'r
Itagaki Takahiro writes:
> On Wed, Sep 8, 2010 at 1:02 AM, Teodor Sigaev wrote:
>> Fixed, and slightly reworked to be more clear.
>> Attached patch is based on your patch.
> The stats page is updated only in VACUUM. ANALYZE doesn't update
> the information at all.
ANALYZE doesn't scan indexes,
On Sun, 2010-10-17 at 15:52 -0700, Greg Stark wrote:
> On Sun, Oct 17, 2010 at 12:03 PM, Joshua D. Drake
> wrote:
> > The only major distribution that I know of that ships the deprecated
> > configuration is RedHat/Fedora. I don't know when that will change.
> >
>
> If only we knew someone in Re
On Sun, Oct 17, 2010 at 12:03 PM, Joshua D. Drake
wrote:
> The only major distribution that I know of that ships the deprecated
> configuration is RedHat/Fedora. I don't know when that will change.
>
If only we knew someone in Redhat :)
iirc the issue was binary upgrades. So I suspect the answe
On Sun, Oct 17, 2010 at 12:17 PM, Tom Lane wrote:
> begin;
> alter type myenum add 'some-value';
> insert into mytab values('some-value');
> rollback;
> I think what this says is that we cannot allow any manipulations that
> involve an uncommitted enum value. Prob
On Sun, 2010-10-17 at 16:27 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > The only major distribution that I know of that ships the deprecated
> > configuration is RedHat/Fedora. I don't know when that will change.
>
> Red Hat switched to integer datetimes as of 8.4 ... just like upstrea
On 10/17/2010 03:56 PM, Tom Lane wrote:
Andrew Dunstan writes:
Making that as fast as "Is this sorted? If yes, compare the two oids" or
even acceptably slower seems likely to be a challenge. I thought about
the sort of approach you suggest initially and didn't come up with
anything that seeme
On 10/17/2010 04:40 PM, Tom Lane wrote:
At the earliest, we could consider dropping them when we drop support
for in-place upgrade from 8.3 --- not only direct upgrade, but through
multiple pg_upgrade steps. That's assuming that we think there are
no users who are depending on float timestamps
Jeff Davis writes:
> On Sun, 2010-10-17 at 16:17 -0400, Tom Lane wrote:
>> There is maybe some argument for removing the float timestamp code
>> altogether, but I think that that's probably premature. They were
>> still the default in 8.3, and we are still supporting in-place upgrade
>> from 8.3.
On Sun, 2010-10-17 at 16:17 -0400, Tom Lane wrote:
> I'm for that one. Anybody working with fractional float timestamps
> should already understand that they aren't exact. I can't see the value
> of expending any great amount of effort on this.
OK.
> There is maybe some argument for removing th
"Joshua D. Drake" writes:
> The only major distribution that I know of that ships the deprecated
> configuration is RedHat/Fedora. I don't know when that will change.
Red Hat switched to integer datetimes as of 8.4 ... just like upstream.
Please don't imagine that you can complain that Red Hat is
Andrew Dunstan writes:
> On 10/17/2010 01:20 PM, Tom Lane wrote:
>> The way I'd be inclined to design this is that altering an enum doesn't
>> change its pg_type entry at all, just add another row to pg_enum.
>> When first needing to compare values of an enum, load up the typcache
>> entry for it.
Jeff Davis writes:
> What should be done? I see a few options:
> 1. Do nothing. Floating-point timestamps aren't the default, and the bug
> reports are likely to be few and far between (but those that encounter
> the bug are likely to be very frustrated).
I'm for that one. Anybody working with
Andrew Dunstan writes:
> On 10/17/2010 03:17 PM, Tom Lane wrote:
>> I think what this says is that we cannot allow any manipulations that
>> involve an uncommitted enum value. Probably the easiest way is to make
>> the ALTER TYPE operation disallowed-inside-transaction-block. That's
>> pretty ug
Andrew Dunstan writes:
> Making that as fast as "Is this sorted? If yes, compare the two oids" or
> even acceptably slower seems likely to be a challenge. I thought about
> the sort of approach you suggest initially and didn't come up with
> anything that seemed likely to work well enough.
The
On 10/17/2010 03:17 PM, Tom Lane wrote:
Dean Rasheed writes:
On 17 October 2010 18:53, Tom Lane wrote:
We could fix that with Dean's idea of reloading the cache whenever
we see that we are being asked to compare a value we don't have in the
cache entry. However, that assumes that we even n
On 10/17/2010 02:19 PM, Dean Rasheed wrote:
That makes me think maybe the "fast" and "slow" comparisons should
both be done the same way, having a cache so that we notice
immediately if we get a new value.
Obviously that's not going to be as fast as the current "fast" method,
but the question
Tom Lane writes:
> Alvaro Herrera writes:
>> Eh, I realize now that the right way to go about this is to use SPI.
>
> Yeah, that would be one way to go about it. But IMO postgres.c should
> be solely concerned with interactions with the client.
I didn't notice it's "possible" to use SPI from wi
On Sun, 2010-10-17 at 17:54 +0200, Magnus Hagander wrote:
> So, it seems we're pretty firmly on git now, and I doubt we're ever
> going to shift back now :)
>
> That means I'd like to get the two CVS VMs shut down (that's
> cvs.postgresql.org and anoncvs.postgresql.org), so we don't have to
> atte
Dean Rasheed writes:
> On 17 October 2010 18:53, Tom Lane wrote:
>> We could fix that with Dean's idea of reloading the cache whenever
>> we see that we are being asked to compare a value we don't have in the
>> cache entry. However, that assumes that we even notice that it's not
>> in the cache
On Sun, 2010-10-17 at 10:00 -0700, David E. Wheeler wrote:
> On Oct 17, 2010, at 9:56 AM, Jeff Davis wrote:
>
> > 3. Somehow deprecate floating point timestamps or make them unusable in
> > conjunction with Range Types. I'm not sure if there is demand to keep
> > them alive or not.
>
This seems
On 10/17/2010 01:20 PM, Tom Lane wrote:
I knew I shoulda read this patch ;-). That seems a lot more invasive
than this feature justifies. And I share your qualms about whether it's
race-condition-proof. We don't have very much locking on pg_type
entries, so making a hard assumption about con
On 17 October 2010 18:53, Tom Lane wrote:
> I wrote:
>> The missing piece in this is how to determine when the typcache entry
>> has to be flushed. That should be driven by sinval signalling.
>
> On reflection that doesn't seem good enough. Immediately after someone
> else has committed an ALTER
Hi all.
Here is a proposed patch which enables cancellation of $subject. The
problematic point about doing so is that the client is not expecting any
messages from the server when its in an idle state during an transaction and
that simply suppressing that message is not enough as ready for quer
I wrote:
> The missing piece in this is how to determine when the typcache entry
> has to be flushed. That should be driven by sinval signalling.
On reflection that doesn't seem good enough. Immediately after someone
else has committed an ALTER TYPE, your typcache entry is out of date,
and won't
Dean Rasheed writes:
> On 17 October 2010 16:49, Tom Lane wrote:
>> [ scratches head... ] And where does it get that number of elements
>> from, if not by doing the same work that would allow it to fill the
>> array completely? Something seems ill-designed here.
> Hmm. That's coming from a new
On Sun, Oct 17, 2010 at 12:09:51AM -0300, Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of sáb oct 16 23:32:49 -0300 2010:
> > Alvaro Herrera writes:
> > > The intent here is to execute some code from the file directly inside
> > > the server.
> >
> > > Eh, I realize now that the right
On Sun, Oct 17, 2010 at 05:54:04PM +0200, Magnus Hagander wrote:
> So, it seems we're pretty firmly on git now, and I doubt we're ever
> going to shift back now :)
>
> That means I'd like to get the two CVS VMs shut down (that's
> cvs.postgresql.org and anoncvs.postgresql.org), so we don't have to
On Oct 17, 2010, at 9:56 AM, Jeff Davis wrote:
> 3. Somehow deprecate floating point timestamps or make them unusable in
> conjunction with Range Types. I'm not sure if there is demand to keep
> them alive or not.
+1
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
I'm working on the design for Range Types for 9.1:
http://wiki.postgresql.org/wiki/RangeTypes
But I think that floating-point timestamps may pose a problem. In this
thread:
http://archives.postgresql.org/pgsql-bugs/2010-08/msg00378.php
I pointed out that floating-point timestamps can become
On 17 October 2010 16:49, Tom Lane wrote:
> Dean Rasheed writes:
>> Hmm, it's harder than I thought. The crash is because each time it
>> finds a label it hasn't seen before it adds it to the array of cached
>> values without checking the array bounds. That array is only as big as
>> the number o
So, it seems we're pretty firmly on git now, and I doubt we're ever
going to shift back now :)
That means I'd like to get the two CVS VMs shut down (that's
cvs.postgresql.org and anoncvs.postgresql.org), so we don't have to
attempt to maintain them...
What should we do with the official old cvs r
Dean Rasheed writes:
> Hmm, it's harder than I thought. The crash is because each time it
> finds a label it hasn't seen before it adds it to the array of cached
> values without checking the array bounds. That array is only as big as
> the number of elements in the enum the first time it was call
On 10/17/2010 10:38 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 10/17/2010 05:30 AM, Dean Rasheed wrote:
I just thought of another corner case, which can lead to a crash. The
comparison code assumes that the number of elements in the enumeration
is constant during a query, but that's not n
On 17 October 2010 15:38, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 10/17/2010 05:30 AM, Dean Rasheed wrote:
>>> I just thought of another corner case, which can lead to a crash. The
>>> comparison code assumes that the number of elements in the enumeration
>>> is constant during a query, bu
Wow, that's interesting - the german version localizes different parts
of the string!
I'm going to apply the change that makes it look only at the
"Microsoft(R) Visual C++" part, and ignore "Project Builder".
//Magnus
On Fri, Oct 15, 2010 at 17:48, Hiroshi Saito wrote:
> Hi.
>
> Ahh, as for Jap
Andrew Dunstan writes:
> On 10/17/2010 05:30 AM, Dean Rasheed wrote:
>> I just thought of another corner case, which can lead to a crash. The
>> comparison code assumes that the number of elements in the enumeration
>> is constant during a query, but that's not necessarily the case.
>> ...
>> Of c
On 10/17/2010 05:30 AM, Dean Rasheed wrote:
On 16 October 2010 18:25, Dean Rasheed wrote:
Are there corner cases the author has failed to consider?
None that I could find.
Are there any assertion failures or crashes?
I just thought of another corner case, which can lead to a crash. The
co
Brendan Jurd writes:
> On 17 October 2010 09:59, Tom Lane wrote:
>> Good point. Maybe the correct fix is to remember whether each token was
>> quoted or not, so that keyword detection can be done safely after the
>> initial lexing. I still think that the current method is impossibly
>> ugly ...
On 16 October 2010 18:25, Dean Rasheed wrote:
> Are there corner cases the author has failed to consider?
>
> None that I could find.
>
> Are there any assertion failures or crashes?
>
I just thought of another corner case, which can lead to a crash. The
comparison code assumes that the number of
43 matches
Mail list logo
