The following bug has been logged on the website:
Bug reference: 7623
Logged by: Louis-Claude Canon
Email address: louis-claude.ca...@univ-fcomte.fr
PostgreSQL version: 9.2.1
Operating system: All
Description:
In the first paragraph of Section 13.2.1, it is first stat
Here's a cleaned up version of this patch, for HEAD. (The patches for
9.1 and 9.2 required minor conflict fixes, but nothing substantial).
The main difference from Dimitri's patch is that I added enough support
code so that AlterRelationNamespaceInternal() is always getting a valid
ObjectAddresse
The following bug has been logged on the website:
Bug reference: 7626
Logged by: Brian Dunavant
Email address: br...@omniti.com
PostgreSQL version: 9.2.1
Operating system: MacOS + Others
Description:
Running this causes the thread to use 100% CPU and never returns (or
On 10/29/2012 12:29 PM, br...@omniti.com wrote:
The following bug has been logged on the website:
Bug reference: 7626
Logged by: Brian Dunavant
Email address: br...@omniti.com
PostgreSQL version: 9.2.1
Operating system: MacOS + Others
Description:
Running this causes the th
br...@omniti.com writes:
> Running this causes the thread to use 100% CPU and never returns (or at
> least not for longer than my patience runs out).
> This returns just fine on 8.4.1 and on 9.2beta.
Hmm ... seems to be a consequence of commit
3b8968f25232ad09001bf35ab4cc59f5a501193e. I wrote in
louis-claude.ca...@univ-fcomte.fr wrote:
> In the first paragraph of Section 13.2.1, it is first stated that
> "[with] this isolation level, a SELECT query [...] never sees [...]
> changes committed during query execution by concurrent
> transactions." It is my understanding that this is untrue (a
On 10/28/2012 03:35 PM, t...@cs.ucsd.edu wrote:
> I really suggest to make the configuration file consistent in this case. But
> I understand it might not be easy. But at least I think we should print a
> better log message which pinpoints to the absolute path like
>
> FATAL: 58P01: could not cre
The following bug has been logged on the website:
Bug reference: 7627
Logged by: Edward Faulkner
Email address: edw...@clericare.com
PostgreSQL version: 9.2.1
Operating system: OSX 10.8.2
Description:
The following two queries differ only by adding "LIMIT 1", but the
edw...@clericare.com writes:
> The following two queries differ only by adding "LIMIT 1", but the one with
> the limit gets radically worse performance. I've done VACUUM FULL, VACUUM
> ANALYZE, and REINDEX DATABASE and there are no modifications since.
> EXPLAIN ANALYZE SELECT * FROM commits WHERE
Hi, Craig,
Thanks a lot for your response. Sorry to make the bug report so long... I
was a little pissed off by myself for my stupidness after spending around 2
hours on this issue.
Yes, your message is definitely better and explicit by pointing out CWD.
The only concern to me is whether or not
10 matches
Mail list logo
