Hey Robert,
I've asked pgsql-general.
Unfortunately it seems that there is no better way to do it except
parsing PQerrorMessage(). Sadly.
2010/10/17 Robert Haas robertmh...@gmail.com
On Thu, Oct 14, 2010 at 2:59 PM, Dmitriy Igrishin dmit...@gmail.com
wrote:
Is there way to determine failed
On 16 October 2010 18:25, Dean Rasheed dean.a.rash...@gmail.com 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
Brendan Jurd dire...@gmail.com writes:
On 17 October 2010 09:59, Tom Lane t...@sss.pgh.pa.us 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
On 10/17/2010 05:30 AM, Dean Rasheed wrote:
On 16 October 2010 18:25, Dean Rasheeddean.a.rash...@gmail.com 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
Andrew Dunstan and...@dunslane.net 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.
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 z-sa...@guitar.ocn.ne.jp wrote:
Hi.
On 17 October 2010 15:38, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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
On 10/17/2010 10:38 AM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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
Dean Rasheed dean.a.rash...@gmail.com 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
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
On 17 October 2010 16:49, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com 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
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
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)
To
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 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 alvhe...@commandprompt.com writes:
The intent here is to execute some code from the file directly inside
the server.
Eh, I realize now
Dean Rasheed dean.a.rash...@gmail.com writes:
On 17 October 2010 16:49, Tom Lane t...@sss.pgh.pa.us 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
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
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
On 17 October 2010 18:53, Tom Lane t...@sss.pgh.pa.us 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
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
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 the best
Dean Rasheed dean.a.rash...@gmail.com writes:
On 17 October 2010 18:53, Tom Lane t...@sss.pgh.pa.us 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
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
attempt
Tom Lane t...@sss.pgh.pa.us writes:
Alvaro Herrera alvhe...@commandprompt.com 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
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 is,
On 10/17/2010 03:17 PM, Tom Lane wrote:
Dean Rasheeddean.a.rash...@gmail.com writes:
On 17 October 2010 18:53, Tom Lanet...@sss.pgh.pa.us 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
Andrew Dunstan and...@dunslane.net 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
Andrew Dunstan and...@dunslane.net 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
Jeff Davis pg...@j-davis.com 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
Andrew Dunstan and...@dunslane.net 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
Joshua D. Drake j...@commandprompt.com 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
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 the
Jeff Davis pg...@j-davis.com 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
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
On 10/17/2010 03:56 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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
On Sun, 2010-10-17 at 16:27 -0400, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com 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 ...
On Sun, Oct 17, 2010 at 12:17 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sun, Oct 17, 2010 at 12:03 PM, Joshua D. Drake j...@commandprompt.com
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
On Sun, 2010-10-17 at 15:52 -0700, Greg Stark wrote:
On Sun, Oct 17, 2010 at 12:03 PM, Joshua D. Drake j...@commandprompt.com
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
Itagaki Takahiro itagaki.takah...@gmail.com writes:
On Wed, Sep 8, 2010 at 1:02 AM, Teodor Sigaev teo...@sigaev.ru 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
(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're not
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 same
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
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
44 matches
Mail list logo
