Alvaro Herrera writes:
> Excerpts from Alexey Parshin's message of lun sep 27 16:56:01 -0400 2010:
>> PostgreSQL (fresh install) fails to start.
>> The only message in the log file says:
>> FATAL: too many private dirs demanded
> Weird. A result of some gentoo patch perhaps? Please try
Is it p
On 28/09/10 15:51, Roedy Green wrote:
>
It'd also help to know:
- If you run the installer from the command line as:
postgresql-9.0.0-1-windows.exe --install_runtimes 0
does it install without error?
>>>
> I ran this using the standard Wi
On Tue, Sep 28, 2010 at 9:04 AM, Craig Ringer
wrote:
> Hopefully one of the EnterpriseDB folks will be able to look into what's
> happening here, time permitting. They're doing the Windows installer as
> a free service to the community after all. I'm toward the end of what I
> can do in terms of d
On Tue, Sep 28, 2010 at 03:28, Itagaki Takahiro
wrote:
>> Magnus Hagander writes:
>>> But how likely is that to bite us elsewhere then?
>
> Initdb works well if the link is a junction (mklink /J).
> We use junctions for tablespaces, but don't use symbolic links.
> So, there are no problems unless
On Tue, Sep 28, 2010 at 11:08, Magnus Hagander wrote:
> On Tue, Sep 28, 2010 at 03:28, Itagaki Takahiro
> wrote:
>> On Mon, Sep 27, 2010 at 11:14 PM, Tom Lane wrote:
>>> I think this is a Microsoft bug and it's their problem to fix, not ours.
>>
>> OK, but bad news is that the bug is in VC 2008,
Hi Andrew,
I have fixed this issue. Thanks for reporting.
Regards,
Dharmendra
On Sat, Sep 25, 2010 at 8:10 AM, Andrew Geery wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5677
> Logged by: Andrew Geery
> Email address: andrew.ge...@gmail.com
> Postgre
Please trace the postmaster, not pg_ctl, as Alvaro suggested
(or else add the -f flag to the strace call).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
When there is a table (or view, or sequence) of the same name in one
schema as another, and both of these schemas are in the set search_path,
only the first schema in the search path will show that name in the
output of \d[S+]. (Also \dt, \dv, etc)
PostgreSQL versions: 8.2.x, 8.3.x, 8.4.4,
Chris Ross writes:
>When there is a table (or view, or sequence) of the same name in one
> schema as another, and both of these schemas are in the set search_path,
> only the first schema in the search path will show that name in the
> output of \d[S+]. (Also \dt, \dv, etc)
That's the int
Kirill Simonov writes:
> I found a bug where a column from a LEFT OUTER JOIN sub-SELECT is not
> equal to NULL when the whole row must be NULL because the join condition
> is not satisfied.
I've applied a patch for this; it'll be in next week's update releases.
Thanks for the report!
The following bug has been logged online:
Bug reference: 5681
Logged by: Maksym Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 8.4.4
Operating system: FreeBSD 7.2
Description:Using set returning function as subrequest can result
losing rows in result s
"Maksym Boguk" writes:
> Oops... two rows where function returned zero rows just disappeared.
Yup, that's expected. This is one of many reasons why set-returning
functions in the targetlist aren't an especially good idea.
regards, tom lane
--
Sent via pgsql-bugs maili
Alexey Parshin writes:
> And then found a link /usr/share/zoneinfo/Australia/Australia to
> /usr/share/zoneinfo/Australia/Australia. Clearly, this isn't PostgreSQL
> fault. Removing that link solved it. Thanks a lot.
Ah-hah.
> A simple suggestion that would help in diagnostics: A message like 't
Sorry. My bad :)
After tracing postmaster as Alvaro suggested, I found the following fragment
(one of thousand):
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2183, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2183, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG
14 matches
Mail list logo
