Hello,
Perhaps you missed my previous message.
pg_dumpall has not -f command line option
to specify output file - it always send output
to standart output. But there is an issue with
it in Windows (I described it earlier) - function's
line endings are changed from 0D 0A to 0D 0D 0A.
Could you ple
Ivan wrote:
Hi,
> Perhaps you missed my previous message.
> pg_dumpall has not -f command line option
> to specify output file - it always send output
> to standart output. But there is an issue with
> it in Windows (I described it earlier) - function's
> line endings are changed from 0D 0A to 0D
The following bug has been logged online:
Bug reference: 2018
Logged by: Bernhard Weisshuhn
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1rc1
Operating system: Linux
Description:segfaults with some german errormessages
Details:
Some errormessages from back
The following bug has been logged online:
Bug reference: 2017
Logged by: Jolly Chen
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1RC1
Operating system: Mac OS X 10.4.3
Description:column labels ignored on selects from views
Details:
Note how the column lab
Hello Alvaro,
Thursday, November 3, 2005, 3:28:41 PM, you wrote:
AH> Ivan wrote:
AH> Hi,
>> Perhaps you missed my previous message.
>> pg_dumpall has not -f command line option
>> to specify output file - it always send output
>> to standart output. But there is an issue with
>> it in Windows (
Antti Salmela <[EMAIL PROTECTED]> writes:
> Failed CLUSTER due to insufficient disk space seems to leave temporary files
> behind at least on 7.4.7.
What was the "failure" exactly? If you ran out of disk space for the
data files, I'd have expected it to reclaim the temp files. On the
other hand,
"Jolly Chen" <[EMAIL PROTECTED]> writes:
> testdb=# select sum as s from v1;
> sum
> -
>3
> (1 row)
Good catch. 8.0 and earlier get this right, so it's a regression we
induced somewhere in 8.1 development ... wonder where?
regards, tom lane
Ivan wrote:
Hi,
> Thursday, November 3, 2005, 3:28:41 PM, you wrote:
> >> Perhaps you missed my previous message.
> >> pg_dumpall has not -f command line option
> >> to specify output file - it always send output
> >> to standart output. But there is an issue with
> >> it in Windows (I described
On Thu, Nov 03, 2005 at 10:03:16AM -0500, Tom Lane wrote:
> Antti Salmela <[EMAIL PROTECTED]> writes:
> > Failed CLUSTER due to insufficient disk space seems to leave temporary files
> > behind at least on 7.4.7.
>
> What was the "failure" exactly? If you ran out of disk space for the
> data file
"Jolly Chen" <[EMAIL PROTECTED]> writes:
> Description:column labels ignored on selects from views
Fixed --- turns out the problem was in some recently-added code to
eliminate unnecessary SubqueryScan nodes. The resnames attached
to the SubqueryScan targetlist items have to be moved down
The problem is that after a dump and reload of
a table hierarchy there are different values in
pg_attribute.attislocal.
A quick grep shows few references to attislocal.
But I cannot say for sure it is unused since it is
documented. However, I'm looking at a db diff
tool and there it does matter.
Hi Elein,
elein wrote:
> The problem is that after a dump and reload of
> a table hierarchy there are different values in
> pg_attribute.attislocal.
>
> A quick grep shows few references to attislocal.
> But I cannot say for sure it is unused since it is
> documented. However, I'm looking at a
two almost identical queries: one searches for
read in ('N','n')
and the other searches for
read in ('Y','y').
the (explain) SQL statement says that one uses the
index on the (read) field and the other does a
sequential table scan. Why!!! I can think of no
logical reason for this behav
"Rob Prowel" <[EMAIL PROTECTED]> wrote
> two almost identical queries: one searches for
>
> read in ('N','n')
>
> and the other searches for
>
> read in ('Y','y').
>
> the (explain) SQL statement says that one uses the
> index on the (read) field and the other does a
> sequential table scan. Why!
Rob Prowel wrote:
> two almost identical queries: one searches for
> read in ('N','n')
> and the other searches for
> read in ('Y','y').
>
> the (explain) SQL statement says that one uses the
> index on the (read) field and the other does a
> sequential table scan. Why!!! I can think of no
>
The following bug has been logged online:
Bug reference: 2019
Logged by: Bernhard Weisshuhn
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1rc1
Operating system: Linux Fedora Core 4 x86_64
Description:tsearch2-related coredump
Details:
We could not yet repro
16 matches
Mail list logo
