I am installing 8.1.4 on a Windows XP SP2 virtual machine (VMWare). It seems
that if I specify BASEDIR= in my command line, and is NOT the
default install path, I get the error "internal account lookup failure"
immediately after the postgres user account is created. If I leave the
BASEDIR stateme
Ronald Kuczek <[EMAIL PROTECTED]> writes:
> Thanks for the answer. It seems to be something else:
> [EMAIL
> PROTECTED]:/usr/src/postgres/backend/utils/mb/conversion_procs/euc_jis_2004_and_shift_jis_2004>
>
Is that actually a correct transcription of the path? Because it's
bogus: it should be
Tom Lane wrote:
I seem to recall we found that some tar versions have a limit on total
pathname length? The tarball was actually OK but it got extracted
incorrectly. However the OP seems to be running a reasonably current
Linux so it's hard to believe he's got that problem.
Alvaro Herrera wrote:
Well, there should be a Makefile in there at the very least. I'll
assume you'll just omitted pasting that part. What happens if you cd
into that directory and run "make"?
Makefile is not present and my unit says :
make: *** No targets specified and no makefile found.
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Hmm, further down the thread, he says several people have seen this
problem:
Yes, it is possible to find more reports about it:
http://www.thescripts.com/forum/thread782006.html
http://www.sql.ru/forum/actualthread.aspx?tid=535381
Hi Al
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What we haven't quite figured out is why the file wasn't present on the
> tarball he downloaded. Is it possible that a borked tarball was
> uploaded somewhere?
I seem to recall we found that some tar versions have a limit on total
pathname length? The
Ronald Kuczek wrote:
> Hi Alvaro,
> Thanks for the answer. It seems to be something else:
> [EMAIL
> PROTECTED]:/usr/src/postgres/backend/utils/mb/conversion_procs/euc_jis_2004_and_shift_jis_2004>
>
> ls -al
> total 16
> drwxr-xr-x 2 postgres users 4096 Mar 27 19:58 .
> drwxr-xr-x 3 postgres
Mark Steben wrote:
> [Mark Steben] Sorry for pressing the point, just making sure I
>
> understand what you're saying.
>
>So, the only way to ensure that a vacuum full will clean out
> an
>
>Empty table is to run it on a stand-alone server?
No
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > Hmm, further down the thread, he says several people have seen this
> > problem:
>
> Yes, it is possible to find more reports about it:
>
> http://www.thescripts.com/forum/thread782006.html
> http://www.sql.ru/forum/actualthread.aspx?tid=535381
Alvaro Herrera wrote:
> Hmm, further down the thread, he says several people have seen this
> problem:
Yes, it is possible to find more reports about it:
http://www.thescripts.com/forum/thread782006.html
http://www.sql.ru/forum/actualthread.aspx?tid=535381
--
Alvaro Herrera Valdivia, Chil
Tom Lane wrote:
> Zdenek Kotala <[EMAIL PROTECTED]> writes:
> > Ronald Kuczek napsal(a):
> >> make[3]: Entering directory
> >> `/usr/src/postgres/postgresql-8.3.1/src/backend/utils/mb/conversion_procs/ut
> >> f8_and_shift_jis_2004'
> >> make[3]: *** No rule to make target `utf8_and_shift_jis_2004.o
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Ronald Kuczek napsal(a):
make[3]: Entering directory
`/usr/src/postgres/postgresql-8.3.1/src/backend/utils/mb/conversion_procs/ut
f8_and_shift_jis_2004'
make[3]: *** No rule to make target `utf8_and_shift_jis_2004.o', needed by
`
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Ronald Kuczek napsal(a):
>> make[3]: Entering directory
>> `/usr/src/postgres/postgresql-8.3.1/src/backend/utils/mb/conversion_procs/ut
>> f8_and_shift_jis_2004'
>> make[3]: *** No rule to make target `utf8_and_shift_jis_2004.o', needed by
>> `libutf8_and
Ronald Kuczek napsal(a):
The following bug has been logged online:
Bug reference: 4068
Logged by: Ronald Kuczek
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Open SuSE 10.3
Description:Failed to compile 8.3.1
Details:
Compilation fro
Taiki Yamaguchi <[EMAIL PROTECTED]> writes:
> yamaguti=# select distinct max(j) from t1;
> ERROR: could not find pathkey item to sort
Fixed in HEAD and 8.3. Thanks for the report!
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
The following bug has been logged online:
Bug reference: 4068
Logged by: Ronald Kuczek
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Open SuSE 10.3
Description:Failed to compile 8.3.1
Details:
Compilation from sources failed with error
On Thu, Mar 27, 2008 at 5:52 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> No, the above is entirely wrong. typtypmod is the typmod that goes with
> the domain's base type, not with the domain itself. You got away with
> this mistaken code before 8.3 because format_type just silently ignored
> i
Hi
Just a question..
The type was declared as follows:
CREATE DOMAIN "dt_0" AS varchar(32)
NULL;
So why does the query respond with 36?
Regards
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 10:53 AM
To: Dave Page
Cc: Eric P. Melbar
"Dave Page" <[EMAIL PROTECTED]> writes:
> On Tue, Mar 25, 2008 at 5:37 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> ... It looks to me like pgAdmin is mistakenly
>> thinking that a domain has type modifiers.
> pgAdmin is using format_type() with a query like:
> postgres=# SELECT oid, format_type(oi
Yes, I am running Windows
but why you replace CRLF with \n\n
instead of replace CRLF with only one \n ?
- Original Message -
From: "Alvaro Herrera" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, March 27, 2008 6:07 PM
Subject: Re: [BUGS] Extra empty lines PGv8.3.1
[EMAIL PROTECTED] wrote:
> Also it seem that
> #pg_dumpall > dumpfile
> #psql < dumpfile
> have such problems.
> all functions get extra empty lines in their bodies.
My guess is that you're running Windows, and there's a CRLF translation
going on somewhere, that duplicates the \n.
--
Alvaro
On Tue, Mar 25, 2008 at 5:37 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "eric melbardis" <[EMAIL PROTECTED]> writes:
> > Description:problem creating function with domain argument
>
> AFAICT this example works fine in psql. You need to take it up
> on the pgAdmin mailing list. It looks
When I saw log file:
2008-03-27 16:42:47 EET COMMAND: CREATE or REPLACE FUNCTION "public"."test"(
OUT result varchar)
AS
$BODY$
DECLARE varTasksCount integer;
BEGIN
SELECT
count( at2.completion_code_ID )
but command actually was:
CREATE or REPLACE FUNCTION "public"."test"(
OUT
NikhilS <[EMAIL PROTECTED]> writes:
> ...
> * Add logic to mark inherited constraints in the children:
> This can be achieved by introducing a new bool "coninherited" attribute in
> pg_constraint. This will be set to true on only those check constraints that
> are added to children via the inherita
NikhilS wrote:
Am important decision here is about adding a new attribute to pg_constraint
as it is the only sane way of determining inherited constraints, but that
will require an initdb. Comments?
There's no problem forcing an initdb at this point in the release cycle.
We will do that for su
Hi,
On Thu, Mar 20, 2008 at 7:36 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> More to the point, it takes a capability away from the user without
> actually solving the problem we need to solve, namely to guarantee
> consistency between parent and child constraints. You can be sure
> that there i
The following bug has been logged online:
Bug reference: 4066
Logged by: javier redolfi
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2
Operating system: debian lenny
Description:error
Details:
insert into
facturascli(idfactura,codigo,editable,fecha,nombrec
27 matches
Mail list logo
