Nabble - PostgreSQL - bugs

Re: BUG #5215: Error in PgAdmin

2009-12-02T18:43:40Z

On Thu, Nov 26, 2009 at 5:41 AM, Walter Willmertinger <willmis@...> wrote:

>
> The following bug has been logged online:
>
> Bug reference: 5215
> Logged by: Walter Willmertinger
> Email address: willmis@...
> PostgreSQL version: 8.4.1
> Operating system: Windows XP Prof.
> Description: Error in PgAdmin
> Details:
>
> Since we introduced 8.4.1, we had some failures of our database. The server
> remained the same, the application is the same as with our previous 8.3.x
> installation.
>
> Error 1:
> "Missing ... pg_catalog"
> pg_dump not possible
> Fixed by "COPY table to FILE ..." for each separate table
> reinstalling postgres, then restored a previous dump and run the output of
> the "COPY"

I'm not sure I understand which of the above lines were part of an
error message (and if so, what exactly you did that precipitated the
error) and which of them are your commentary.

...Robert

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5227: please add a divide operator for intervals

2009-12-02T18:35:05Z

Michał Pasternak wrote:
> 1 month / 1 day equals 30.
>

or 31 or 28 or 29...

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5227: please add a divide operator for intervals

2009-12-02T17:36:28Z

1 month / 1 day equals 30.

-----Original Message-----
From: Tom Lane [mailto:tgl@...]
Sent: Thursday, December 03, 2009 12:46 AM
To: Michal Pasternak
Cc: pgsql-bugs@...
Subject: Re: [BUGS] BUG #5227: please add a divide operator for intervals

"Michal Pasternak" <michal.dtz@...> writes:
> Please add a divide operator for INTERVAL type, if possible.

Given that intervals have multiple subfields, it's far from obvious
what division should mean. What is '1 month' / '1 day'?

> db=# SELECT EXTRACT(EPOCH FROM '15 seconds'::INTERVAL) / EXTRACT(EPOCH
FROM
> '15 seconds'::INTERVAL);

If that's the behavior you want, you already have a way to do it
(and you could wrap that up in a user-defined operator if you chose).
It loses quite a lot of information though, so I doubt we'd want
to enshrine it as the standard definition.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5227: please add a divide operator for intervals

2009-12-02T15:45:31Z

"Michal Pasternak" <michal.dtz@...> writes:
> Please add a divide operator for INTERVAL type, if possible.

Given that intervals have multiple subfields, it's far from obvious
what division should mean. What is '1 month' / '1 day'?

> db=# SELECT EXTRACT(EPOCH FROM '15 seconds'::INTERVAL) / EXTRACT(EPOCH FROM
> '15 seconds'::INTERVAL);

If that's the behavior you want, you already have a way to do it
(and you could wrap that up in a user-defined operator if you chose).
It loses quite a lot of information though, so I doubt we'd want
to enshrine it as the standard definition.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5225: create table: cast necessary for constant??

2009-12-02T15:39:44Z

"Kevin Grittner" <Kevin.Grittner@...> writes:

> Quoting from section 5.3 of "WG3:HBA-003 H2-2003-305 August, 2003
> (ISO-ANSI Working Draft) Foundation (SQL/Foundation)":
> | 13) The declared type of a <character string literal> is
> | fixed-length character string.
> Treating an otherwise unadorned set of characters between two
> apostrophes as anything except a character string literal of type
> CHARACTER with a length calculated per the above violates the
> standard. Rather than pretending otherwise, we should be prepared
> to explain the reasons for the deviation, describe what the
> PostgreSQL behavior *is*, and justify the deviation.

Sorry about that --- I had confused this case with that of a bare NULL
literal, which Postgres treats the same as an unadorned string literal
for type determination purposes. You're right that the spec treats
them differently. This is feasible for the spec's purposes because
it has such a paucity of data types. Also, I believe that the spec
expects you to explicitly mark literals that aren't to be treated
as plain strings, ie, in something like
TIMESTAMP '2009-12-02 18:28:58'
you're not really supposed to omit the word TIMESTAMP.

Postgres has a whole lot of datatypes, including user-added ones, and
most of them share the unadorned string literal as the base case for
constants. Giving preference to CHARACTER would make that machinery
a lot less pleasant to use.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

BUG #5227: please add a divide operator for intervals

2009-12-02T14:31:37Z

The following bug has been logged online:

Bug reference: 5227
Logged by: Michal Pasternak
Email address: michal.dtz@...
PostgreSQL version: 8.4
Operating system: doesn't matter
Description: please add a divide operator for intervals
Details:

Please add a divide operator for INTERVAL type, if possible.

db=# SELECT '15 seconds'::INTERVAL / '15 seconds'::INTERVAL;
ERROR: operator does not exist: interval / interval
LINE 1: SELECT '15 seconds'::INTERVAL / '15 seconds'::INTERVAL;
^
HINT: No operator matches the given name and argument type(s). You might
need to add explicit type casts.

db=# SELECT EXTRACT(EPOCH FROM '15 seconds'::INTERVAL) / EXTRACT(EPOCH FROM
'15 seconds'::INTERVAL);
?column?
----------
1
(1 row)

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: Assertion failure with a subtransaction and cursor

2009-12-02T13:59:50Z

Heikki Linnakangas <heikki.linnakangas@...> writes:
> The logical next step would be to get rid of the interXact concept
> altogether and always associate temporary files with the current
> resource owner; the caller should switch to a sufficiently long-lived
> one before calling.

That would mean having a session-lifespan resource owner, which doesn't
seem amazingly useful to me: we have no other resource types for which
that would be even a little bit sane. I'm inclined to leave the temp
file API as nearly as possible as-is. Having it attach only xact-local
files to the CurrentResourceOwner sounds fine to me.

One thought here is that my inclination would be to keep
CleanupTemporaryFiles in place and have it just look for temp files that
didn't get closed, as a debugging aid. This is comparable to the
behavior of other modules that are mostly driven by resource managers.
We didn't take out the end-of-xact checks when we added resource manager
support elsewhere, and I'm not inclined to do that here. I agree we
don't need an EOSubXact-time crosscheck, though.

Other than that quibble it looks sane from here.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: Assertion failure with a subtransaction and cursor

2009-12-02T13:46:19Z

Heikki Linnakangas wrote:

> Tom Lane wrote:
>> So as far as I can tell at the moment, temp files really are the only
>> problem, and making them be managed by resource owners instead of a
>> subxact-based release policy should fix that.
>
> Ok, good.
>
>> I can go work on that, unless you wanted to?
>
> I started hacking on that when I posted, so I can finish it.

So, here's what I got this far, which is pretty straightforward.
Temporary files not opened in the interXact mode are registered with
CurrentResourceOwner, ensuring they're cleaned up at at the end of
(sub)transaction, or when the portal is closed if it's a temporary file
related to a cursor.

The logical next step would be to get rid of the interXact concept
altogether and always associate temporary files with the current
resource owner; the caller should switch to a sufficiently long-lived
one before calling. But I'm hesitant to change the signature of
OpenTemporaryFile, and tuplestore_begin_heap doesn't need the interXact
argument anymore either. Changing the signature of tuplestore_begin_heap
would certainly break user-defined set-returning C functions. So at
least in back-branches, perhaps we should leave those as dummy arguments
and elog(ERROR) if interXact is not passed in as false.

Google turned up one extra module that calls tuplestore_begin_heap with
interXact set to 'true', but frankly that one looks broken to me. It
should be using 'false':
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/python/be/src/call/pl.c?rev=1.20&content-type=text/x-cvsweb-markup

I left the cleanup of files/dirs opened with AllocateFile/Dir alone,
although it looks a bit inconsistent now that they don't use resource
owners as well.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Index: src/backend/storage/file/fd.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/storage/file/fd.c,v
retrieving revision 1.150
diff -c -r1.150 fd.c
*** src/backend/storage/file/fd.c 5 Aug 2009 18:01:54 -0000 1.150
--- src/backend/storage/file/fd.c 2 Dec 2009 21:42:01 -0000
***************
*** 55,60 ****
--- 55,61 ----
#include "storage/fd.h"
#include "storage/ipc.h"
#include "utils/guc.h"
+ #include "utils/resowner.h"

/*
***************
*** 122,140 ****

/* these are the assigned bits in fdstate below: */
#define FD_TEMPORARY (1 << 0) /* T = delete when closed */
- #define FD_XACT_TEMPORARY (1 << 1) /* T = delete at eoXact */
-
- /*
- * Flag to tell whether it's worth scanning VfdCache looking for temp files to
- * close
- */
- static bool have_xact_temporary_files = false;

typedef struct vfd
{
int fd; /* current FD, or VFD_CLOSED if none */
unsigned short fdstate; /* bitflags for VFD's state */
! SubTransactionId create_subid; /* for TEMPORARY fds, creating subxact */
File nextFree; /* link to next free VFD, if in freelist */
File lruMoreRecently; /* doubly linked recency-of-use list */
File lruLessRecently;
--- 123,134 ----

/* these are the assigned bits in fdstate below: */
#define FD_TEMPORARY (1 << 0) /* T = delete when closed */

typedef struct vfd
{
int fd; /* current FD, or VFD_CLOSED if none */
unsigned short fdstate; /* bitflags for VFD's state */
! ResourceOwner resowner; /* owner, for automatic cleanup */
File nextFree; /* link to next free VFD, if in freelist */
File lruMoreRecently; /* doubly linked recency-of-use list */
File lruLessRecently;
***************
*** 865,870 ****
--- 859,865 ----
vfdP->fileMode = fileMode;
vfdP->seekPos = 0;
vfdP->fdstate = 0x0;
+ vfdP->resowner = NULL;

return file;
}
***************
*** 876,883 ****
* There's no need to pass in fileFlags or fileMode either, since only
* one setting makes any sense for a temp file.
*
! * interXact: if true, don't close the file at end-of-transaction. In
! * most cases, you don't want temporary files to outlive the transaction
* that created them, so this should be false -- but if you need
* "somewhat" temporary storage, this might be useful. In either case,
* the file is removed when the File is explicitly closed.
--- 871,878 ----
* There's no need to pass in fileFlags or fileMode either, since only
* one setting makes any sense for a temp file.
*
! * interXact: if true, don't associate the file with CurrentResourceOwner.
! * In most cases, you don't want temporary files to outlive the transaction
* that created them, so this should be false -- but if you need
* "somewhat" temporary storage, this might be useful. In either case,
* the file is removed when the File is explicitly closed.
***************
*** 918,931 ****
/* Mark it for deletion at close */
VfdCache[file].fdstate |= FD_TEMPORARY;

! /* Mark it for deletion at EOXact */
if (!interXact)
{
! VfdCache[file].fdstate |= FD_XACT_TEMPORARY;
! VfdCache[file].create_subid = GetCurrentSubTransactionId();
!
! /* ensure cleanup happens at eoxact */
! have_xact_temporary_files = true;
}

return file;
--- 913,924 ----
/* Mark it for deletion at close */
VfdCache[file].fdstate |= FD_TEMPORARY;

! /* Associate it with the current resource owner */
if (!interXact)
{
! ResourceOwnerEnlargeFiles(CurrentResourceOwner);
! ResourceOwnerRememberFile(CurrentResourceOwner, file);
! VfdCache[file].resowner = CurrentResourceOwner;
}

return file;
***************
*** 1051,1056 ****
--- 1044,1052 ----
elog(LOG, "could not unlink file \"%s\": %m", vfdP->fileName);
}

+ if (vfdP->resowner)
+ ResourceOwnerForgetFile(vfdP->resowner, file);
+
/*
* Return the Vfd slot to the free list
*/
***************
*** 1695,1718 ****
{
Index i;

- if (have_xact_temporary_files)
- {
- Assert(FileIsNotOpen(0)); /* Make sure ring not corrupted */
- for (i = 1; i < SizeVfdCache; i++)
- {
- unsigned short fdstate = VfdCache[i].fdstate;
-
- if ((fdstate & FD_XACT_TEMPORARY) &&
- VfdCache[i].create_subid == mySubid)
- {
- if (isCommit)
- VfdCache[i].create_subid = parentSubid;
- else if (VfdCache[i].fileName != NULL)
- FileClose(i);
- }
- }
- }
-
for (i = 0; i < numAllocatedDescs; i++)
{
if (allocatedDescs[i].create_subid == mySubid)
--- 1691,1696 ----
***************
*** 1732,1746 ****
* AtEOXact_Files
*
* This routine is called during transaction commit or abort (it doesn't
! * particularly care which). All still-open per-transaction temporary file
! * VFDs are closed, which also causes the underlying files to be
! * deleted. Furthermore, all "allocated" stdio files are closed.
* We also forget any transaction-local temp tablespace list.
*/
void
AtEOXact_Files(void)
{
! CleanupTempFiles(false);
tempTableSpaces = NULL;
numTempTableSpaces = -1;
}
--- 1710,1725 ----
* AtEOXact_Files
*
* This routine is called during transaction commit or abort (it doesn't
! * particularly care which). All "allocated" stdio files are closed.
* We also forget any transaction-local temp tablespace list.
*/
void
AtEOXact_Files(void)
{
! /* Clean up "allocated" stdio files and dirs. */
! while (numAllocatedDescs > 0)
! FreeDesc(&allocatedDescs[0]);
!
tempTableSpaces = NULL;
numTempTableSpaces = -1;
}
***************
*** 1749,1802 ****
* AtProcExit_Files
*
* on_proc_exit hook to clean up temp files during backend shutdown.
! * Here, we want to clean up *all* temp files including interXact ones.
*/
static void
AtProcExit_Files(int code, Datum arg)
{
! CleanupTempFiles(true);
! }
!
! /*
! * Close temporary files and delete their underlying files.
! *
! * isProcExit: if true, this is being called as the backend process is
! * exiting. If that's the case, we should remove all temporary files; if
! * that's not the case, we are being called for transaction commit/abort
! * and should only remove transaction-local temp files. In either case,
! * also clean up "allocated" stdio files and dirs.
! */
! static void
! CleanupTempFiles(bool isProcExit)
! {
! Index i;

/*
! * Careful here: at proc_exit we need extra cleanup, not just
! * xact_temporary files.
*/
! if (isProcExit || have_xact_temporary_files)
{
! Assert(FileIsNotOpen(0)); /* Make sure ring not corrupted */
! for (i = 1; i < SizeVfdCache; i++)
! {
! unsigned short fdstate = VfdCache[i].fdstate;
!
! if ((fdstate & FD_TEMPORARY) && VfdCache[i].fileName != NULL)
! {
! /*
! * If we're in the process of exiting a backend process, close
! * all temporary files. Otherwise, only close temporary files
! * local to the current transaction.
! */
! if (isProcExit || (fdstate & FD_XACT_TEMPORARY))
! FileClose(i);
! }
! }

! have_xact_temporary_files = false;
}

while (numAllocatedDescs > 0)
FreeDesc(&allocatedDescs[0]);
}
--- 1728,1755 ----
* AtProcExit_Files
*
* on_proc_exit hook to clean up temp files during backend shutdown.
! * Here, we want to clean up *all* temp files and "allocated" stdio files
! * and dirs.
*/
static void
AtProcExit_Files(int code, Datum arg)
{
! int i;

/*
! * Close all still-open temporary file VFD, which also causes the
! * underlying files to be deleted.
*/
! Assert(FileIsNotOpen(0)); /* Make sure ring not corrupted */
! for (i = 1; i < SizeVfdCache; i++)
{
! unsigned short fdstate = VfdCache[i].fdstate;

! if ((fdstate & FD_TEMPORARY) && VfdCache[i].fileName != NULL)
! FileClose(i);
}

+ /* Clean up "allocated" stdio files and dirs. */
while (numAllocatedDescs > 0)
FreeDesc(&allocatedDescs[0]);
}
Index: src/backend/utils/resowner/resowner.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/resowner/resowner.c,v
retrieving revision 1.32
diff -c -r1.32 resowner.c
*** src/backend/utils/resowner/resowner.c 11 Jun 2009 14:49:06 -0000 1.32
--- src/backend/utils/resowner/resowner.c 2 Dec 2009 21:42:01 -0000
***************
*** 72,77 ****
--- 72,82 ----
int nsnapshots; /* number of owned snapshot references */
Snapshot *snapshots; /* dynamically allocated array */
int maxsnapshots; /* currently allocated array size */
+
+ /* We have built-in support for remembering open temporary files */
+ int nfiles; /* number of owned temporary files */
+ File *files; /* dynamically allocated array */
+ int maxfiles; /* currently allocated array size */
} ResourceOwnerData;

***************
*** 105,110 ****
--- 110,116 ----
static void PrintPlanCacheLeakWarning(CachedPlan *plan);
static void PrintTupleDescLeakWarning(TupleDesc tupdesc);
static void PrintSnapshotLeakWarning(Snapshot snapshot);
+ static void PrintFileLeakWarning(File file);

/*****************************************************************************
***************
*** 316,321 ****
--- 322,335 ----
UnregisterSnapshot(owner->snapshots[owner->nsnapshots - 1]);
}

+ /* Ditto for temporary files */
+ while (owner->nfiles > 0)
+ {
+ if (isCommit)
+ PrintFileLeakWarning(owner->files[owner->nfiles - 1]);
+ FileClose(owner->files[owner->nfiles - 1]);
+ }
+
/* Clean up index scans too */
ReleaseResources_hash();
}
***************
*** 347,352 ****
--- 361,367 ----
Assert(owner->nplanrefs == 0);
Assert(owner->ntupdescs == 0);
Assert(owner->nsnapshots == 0);
+ Assert(owner->nfiles == 0);

/*
* Delete children. The recursive call will delink the child from me, so
***************
*** 377,382 ****
--- 392,399 ----
pfree(owner->tupdescs);
if (owner->snapshots)
pfree(owner->snapshots);
+ if (owner->files)
+ pfree(owner->files);

pfree(owner);
}
***************
*** 1035,1037 ****
--- 1052,1138 ----
"Snapshot reference leak: Snapshot %p still referenced",
snapshot);
}
+
+
+ /*
+ * Make sure there is room for at least one more entry in a ResourceOwner's
+ * files reference array.
+ *
+ * This is separate from actually inserting an entry because if we run out
+ * of memory, it's critical to do so *before* acquiring the resource.
+ */
+ void
+ ResourceOwnerEnlargeFiles(ResourceOwner owner)
+ {
+ int newmax;
+
+ if (owner->nfiles < owner->maxfiles)
+ return; /* nothing to do */
+
+ if (owner->files == NULL)
+ {
+ newmax = 16;
+ owner->files = (File *)
+ MemoryContextAlloc(TopMemoryContext, newmax * sizeof(File));
+ owner->maxfiles = newmax;
+ }
+ else
+ {
+ newmax = owner->maxfiles * 2;
+ owner->files = (File *)
+ repalloc(owner->files, newmax * sizeof(File));
+ owner->maxfiles = newmax;
+ }
+ }
+
+ /*
+ * Remember that a temporary file is owned by a ResourceOwner
+ *
+ * Caller must have previously done ResourceOwnerEnlargeFiles()
+ */
+ void
+ ResourceOwnerRememberFile(ResourceOwner owner, File file)
+ {
+ Assert(owner->nfiles < owner->maxfiles);
+ owner->files[owner->nfiles] = file;
+ owner->nfiles++;
+ }
+
+ /*
+ * Forget that a temporary file is owned by a ResourceOwner
+ */
+ void
+ ResourceOwnerForgetFile(ResourceOwner owner, File file)
+ {
+ File *files = owner->files;
+ int ns1 = owner->nfiles - 1;
+ int i;
+
+ for (i = ns1; i >= 0; i--)
+ {
+ if (files[i] == file)
+ {
+ while (i < ns1)
+ {
+ files[i] = files[i + 1];
+ i++;
+ }
+ owner->nfiles = ns1;
+ return;
+ }
+ }
+ elog(ERROR, "temporery file %d is not owned by resource owner %s",
+ file, owner->name);
+ }
+
+
+ /*
+ * Debugging subroutine
+ */
+ static void
+ PrintFileLeakWarning(File file)
+ {
+ elog(WARNING,
+ "Temporary file leak: File %d still referenced",
+ file);
+ }
Index: src/include/utils/resowner.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/utils/resowner.h,v
retrieving revision 1.17
diff -c -r1.17 resowner.h
*** src/include/utils/resowner.h 1 Jan 2009 17:24:02 -0000 1.17
--- src/include/utils/resowner.h 2 Dec 2009 21:42:01 -0000
***************
*** 20,25 ****
--- 20,26 ----
#define RESOWNER_H

#include "storage/buf.h"
+ #include "storage/fd.h"
#include "utils/catcache.h"
#include "utils/plancache.h"
#include "utils/snapshot.h"
***************
*** 129,132 ****
--- 130,140 ----
extern void ResourceOwnerForgetSnapshot(ResourceOwner owner,
Snapshot snapshot);

+ /* support for temporary file management */
+ extern void ResourceOwnerEnlargeFiles(ResourceOwner owner);
+ extern void ResourceOwnerRememberFile(ResourceOwner owner,
+ File file);
+ extern void ResourceOwnerForgetFile(ResourceOwner owner,
+ File file);
+
#endif /* RESOWNER_H */

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: Assertion failure with a subtransaction and cursor

2009-12-02T13:12:17Z

Heikki Linnakangas <heikki.linnakangas@...> writes:
> Tom Lane wrote:
>> I can go work on that, unless you wanted to?

> I started hacking on that when I posted, so I can finish it.

Sounds good. I added a bit to the ROLLBACK TO reference page to remind
us what we think the behavior is supposed to be for cursor rollback.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: Assertion failure with a subtransaction and cursor

2009-12-02T12:26:28Z

Tom Lane wrote:
> So as far as I can tell at the moment, temp files really are the only
> problem, and making them be managed by resource owners instead of a
> subxact-based release policy should fix that.

Ok, good.

> I can go work on that, unless you wanted to?

I started hacking on that when I posted, so I can finish it.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: Assertion failure with a subtransaction and cursor

2009-12-02T12:14:37Z

I wrote:
> Heikki Linnakangas <heikki.linnakangas@...> writes:
>> Hmm, I think we should track temporary files using resource owners.

> That would probably be a workable solution if temp files are the only
> problem. What I'm afraid of is that this type of problem exists
> *everywhere* that we track the need for cleanup operations using the
> assumption that subtransactions are nested.

I just spent a tedious hour digging through every function called by
AbortSubTransaction(), and came to the conclusion that this fear may be
overblown, so long as we are willing to stipulate that user-visible
side effects caused by a cursor's query are to be rolled back if they
occur during a subtransaction that is rolled back. From the user's
perspective this may make things a bit unpredictable, since it is not
always clear exactly when a side effect will occur during the execution
of a query. However it doesn't seem like it can actually break the
system.

(At least not for code in core CVS. Outside modules might be doing
unsafe things in RegisterSubXactCallback callbacks. But that's not
our responsibility to fix.)

It might be a good idea to forbid writeable CTEs in cursor queries,
because that would expose the unpredictability a lot more, and maybe
open some internal issues too -- I noted snapshot management as a likely
problem if the executor is allowed to create its own snapshots. But as
far as what's in CVS is concerned that's not an issue yet anyhow. If
we did want to allow it, we could probably make it safe by forcing all
the writable CTEs to run at cursor creation time.

So as far as I can tell at the moment, temp files really are the only
problem, and making them be managed by resource owners instead of a
subxact-based release policy should fix that. I can go work on that,
unless you wanted to?

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: Assertion failure with a subtransaction and cursor

2009-12-02T12:04:55Z

Tom Lane wrote:

> Heikki Linnakangas <heikki.linnakangas@...> writes:
> > Tom Lane wrote:
> >> Not sure what to do. The only fix that seems bulletproof at the moment
> >> is to declare that any cursor that's been touched at all in a
> >> subtransaction is marked "broken" if the subtransaction rolls back.
> >> That might be too great a loss of functionality. It would block off
> >> the controversial aspects of behavior though ...
>
> > Hmm, I think we should track temporary files using resource owners.
>
> That would probably be a workable solution if temp files are the only
> problem. What I'm afraid of is that this type of problem exists
> *everywhere* that we track the need for cleanup operations using the
> assumption that subtransactions are nested. If that's the case then we
> are looking at a very major rewrite to make things bulletproof --- much
> larger than I'd feel comfortable back-patching, especially so far back
> as 8.0. I'm thinking we might have little choice but to disable the
> functionality in back branches.

Hmm, the reason we didn't disable it is that people requested it
explicitely. In fact IIRC we had this very same discussion years ago,
except without the crashing test case. I fear that if it gets disabled,
some people will be upset.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: Assertion failure with a subtransaction and cursor

2009-12-02T10:59:08Z

Heikki Linnakangas <heikki.linnakangas@...> writes:
> Tom Lane wrote:
>> Not sure what to do. The only fix that seems bulletproof at the moment
>> is to declare that any cursor that's been touched at all in a
>> subtransaction is marked "broken" if the subtransaction rolls back.
>> That might be too great a loss of functionality. It would block off
>> the controversial aspects of behavior though ...

> Hmm, I think we should track temporary files using resource owners.

That would probably be a workable solution if temp files are the only
problem. What I'm afraid of is that this type of problem exists
*everywhere* that we track the need for cleanup operations using the
assumption that subtransactions are nested. If that's the case then we
are looking at a very major rewrite to make things bulletproof --- much
larger than I'd feel comfortable back-patching, especially so far back
as 8.0. I'm thinking we might have little choice but to disable the
functionality in back branches.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5225: create table: cast necessary for constant??

2009-12-02T09:37:53Z

Craig Ringer <craig@...> wrote:

> On 3/12/2009 12:35 AM, Tom Lane wrote:
>> You really ought to cast the 'I' to some specific type.
>
> It's usually neatest to do this by just explicitly identifying
> the intended type in the first place, eg:
>
>
> SELECT firmnr,
> werknr,
> TEXT 'I' as invper,
> invnum
> from .... ;
>
> ... which, IIRC, is the standard way to do it. I don't have a copy
> to check against to be sure.
>
> Personally, I like the fact that Pg errs on the side of caution
> here rather than guessing what you want.

We should probably have some wiki page or something to which we can
refer people when they raise this, which is bound to happen from
time to time, since the PostgreSQL behavior is a deviation from the
standard. Now, I've been persuaded that there are good reasons for
the deviation, and that workarounds for code previously written to
standard are relatively straightforward, but many people here lose
sight of the fact that it *is* a deviation when replying to someone
who's just run into it.

Quoting from section 5.3 of "WG3:HBA-003 H2-2003-305 August, 2003
(ISO-ANSI Working Draft) Foundation (SQL/Foundation)":

| 13) The declared type of a <character string literal> is
| fixed-length character string. The length of a <character
| string literal> is the number of <character representation>s
| that it contains. Each <quote symbol> contained in <character
| string literal> represents a single <quote> in both the value
| and the length of the <character string literal>. The two
| <quote>s contained in a <quote symbol> shall not be separated
| by any <separator>.
|
| NOTE 72 * <character string literal>s are allowed to be
| zero-length strings (i.e., to contain no characters) even
| though it is not permitted to declare a <data type> that is
| CHARACTER with <length> 0 (zero).

Treating an otherwise unadorned set of characters between two
apostrophes as anything except a character string literal of type
CHARACTER with a length calculated per the above violates the
standard. Rather than pretending otherwise, we should be prepared
to explain the reasons for the deviation, describe what the
PostgreSQL behavior *is*, and justify the deviation.

-Kevin

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5226: Limit operator slows down

2009-12-02T09:00:27Z

On Wed, Dec 2, 2009 at 11:42 AM, Craig Ringer
<craig@...> wrote:

> On 2/12/2009 10:35 PM, aftab wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference: 5226
>> Logged by: aftab
>> Email address: akhangd@...
>> PostgreSQL version: 8.3.8
>> Operating system: Centos 5
>> Description: Limit operator slows down
>> Details:
>>
>> S1="SELECT *
>> FROM position WHERE
>> position.POSITION_STATE_ID=2 AND
>> position.TARGET_ID=18
>> ORDER BY position.ID DESC
>> ";
>> S2="SELECT *
>> FROM position WHERE
>> position.POSITION_STATE_ID=2 AND
>> position.TARGET_ID=18
>> ORDER BY position.ID DESC
>> LIMIT 1
>> ";
>>
>> S1 takes 0.16ms compared to S2 which takes 5 secs. Both S1 and S2 are same
>> except "LIMIT 1 " is added to S2.
>
> Please read this:
>
> http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
>
> then re-post your question to the pgsql-general mailing list, including
> appropriate EXPLAIN ANALYZE output for both queries, etc.

Or pgsql-performance.

...Robert

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5225: create table: cast necessary for constant??

2009-12-02T08:46:56Z

On 3/12/2009 12:35 AM, Tom Lane wrote:

> "Kurt wagner"<kurt.wagnerextern@...> writes:
>> During migration from Informix to Postgres I came across following issue:
>> create temp table temp1 as
>> SELECT firmnr,
>> werknr,
>> 'I' as invper,
>> invnum
>> from .... ;
>
> You really ought to cast the 'I' to some specific type.

It's usually neatest to do this by just explicitly identifying the
intended type in the first place, eg:

SELECT firmnr,
werknr,
TEXT 'I' as invper,
invnum
from .... ;

... which, IIRC, is the standard way to do it. I don't have a copy to
check against to be sure.

Personally, I like the fact that Pg errs on the side of caution here
rather than guessing what you want.

--
Craig Ringer

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5226: Limit operator slows down

2009-12-02T08:42:38Z

On 2/12/2009 10:35 PM, aftab wrote:

>
> The following bug has been logged online:
>
> Bug reference: 5226
> Logged by: aftab
> Email address: akhangd@...
> PostgreSQL version: 8.3.8
> Operating system: Centos 5
> Description: Limit operator slows down
> Details:
>
> S1="SELECT *
> FROM position WHERE
> position.POSITION_STATE_ID=2 AND
> position.TARGET_ID=18
> ORDER BY position.ID DESC
> ";
> S2="SELECT *
> FROM position WHERE
> position.POSITION_STATE_ID=2 AND
> position.TARGET_ID=18
> ORDER BY position.ID DESC
> LIMIT 1
> ";
>
> S1 takes 0.16ms compared to S2 which takes 5 secs. Both S1 and S2 are same
> except "LIMIT 1 " is added to S2.

Please read this:

http://wiki.postgresql.org/wiki/Guide_to_reporting_problems

then re-post your question to the pgsql-general mailing list, including
appropriate EXPLAIN ANALYZE output for both queries, etc.

--
Craig Ringer

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5225: create table: cast necessary for constant??

2009-12-02T08:35:01Z

"Kurt wagner" <kurt.wagnerextern@...> writes:
> During migration from Informix to Postgres I came across following issue:
> create temp table temp1 as
> SELECT firmnr,
> werknr,
> 'I' as invper,
> invnum
> from .... ;

You really ought to cast the 'I' to some specific type. The above code
is illegal per SQL standard. You can get away with it in certain
contexts in Postgres, but when you are creating a table or view and
don't know exactly what might be done with the column, it's much better
to ensure it's of the intended type. We aren't going to make it default
to text or whatever because it's not always clear that that's what's
intended --- consider

'1.2' as invper,
'2009-11-23' as invper,

Most likely text was not what the writer had in mind in such cases.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5224: After upgrading from vista to windows 7, postgres services are missing

2009-12-02T08:12:54Z

On 2/12/2009 11:57 PM, Sriram Gopalan wrote:
> Please consider this issue as resolved. Reinstallation seems to have
> fixed it.
>
> The service is running, as noted before and I am able to connect and use
> the database. My syntax was wrong in the previous email.

Ah, OK. Please disregard my previous mail then.

Thanks for letting us know rather than just going quiet when the problem
was fixed. It's nice to know when things work out, and it helps others
who search for answers later.

--
Craig Ringer

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5224: After upgrading from vista to windows 7, postgres services are missing

2009-12-02T08:11:42Z

On 2/12/2009 11:51 PM, Sriram Gopalan wrote:
> 1. After I reinstalled the latest version of postgresql, I do see a
> service called postgresql-8.4.
> 2. It is started automatically.

Yes, but is it *running* ? The service manager shows the current status
(running or stopped) separately to the startup settings. Check if it's
running.

Also: If you look in Task Manager, are there any "postgres.exe"
processes shown? (You'll need to show all users' tasks, since they run
under a different user account to yours).

> psql: could not connect to server: Cannot assign requested address
> (0x00002741/1
> 0049)
> Is the server running on host "localhost" and accepting
> TCP/IP connections on port test?

er ... what? "port test" ? Did you mean to specify a port number and
just put the wrong thing in the wrong field, or did you really intend to
tell psql to connect to the port "test" (via servicename->port
translation presumably)?

What port is PostgreSQL listening on? Check postgresql.conf. The default
is 5432. Try connecting to PostgreSQL by port number.

As for the error message:

0x00002741 appears to be a name service error, which makes sense if the
system is trying to look up the service name to get a port number and
failing. Say, if it's deeply confused by being fed a non-numeric string
for a port number.

Specifically, it's:

Windows Error 0x00002741 - 10049
The requested address is not valid in its context.
WSAEADDRNOTAVAIL

> 4. I believe ever since I upgraded, the pg_log logs have been empty.
> There is nothing much interesting in the prior few logs (just info
> messages about starting up and shutting down etc.)

Not even server startup messages? When is the most recent log entry?

--
Craig Ringer

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5224: After upgrading from vista to windows 7, postgres services are missing

2009-12-02T07:57:33Z

Please consider this issue as resolved. Reinstallation seems to have fixed it.

The service is running, as noted before and I am able to connect and use the database. My syntax was wrong in the previous email.

Thanks again.

Sriram

On Wed, Dec 2, 2009 at 7:51 AM, Sriram Gopalan <sriramgopalan@...> wrote:

1. After I reinstalled the latest version of postgresql, I do see a service called postgresql-8.4.
2. It is started automatically.

Please note, however, that I am still not able to connect to the database. For example, trying to use psql gives me the following error:

psql: could not connect to server: Cannot assign requested address (0x00002741/1
0049)
Is the server running on host "localhost" and accepting
TCP/IP connections on port test?

I have never seen this error before my OS upgrade.

3. I looked through the Windows Event Viewer but didn't anything related to postgres.
4. I believe ever since I upgraded, the pg_log logs have been empty. There is nothing much interesting in the prior few logs (just info messages about starting up and shutting down etc.)

Thanks for the prompt response.

Sriram

On Wed, Dec 2, 2009 at 1:07 AM, Craig Ringer <craig@...> wrote:

On 2/12/2009 12:57 PM, Sriram Gopalan wrote:

The following bug has been logged online:

Bug reference: 5224
Logged by: Sriram Gopalan
Email address: sriramgopalan@...
PostgreSQL version: 8.4.1
Operating system: Windows 7
Description: After upgrading from vista to windows 7, postgres
services are missing
Details:

I recently upgraded my machine from windows vista to window 7. I had
installed postgresql 8.4.1 on that machine and it was working great.
However, after upgrade, I cannot even see the services related to postgres.
When I try to connect, I get the message that postgres is not running and
listening to its port.

In the services control panel (start -> run ->services.msc , or via Control Panel -> Administrative Tools) can you see the postgresql service listed?

What state is it in?

Is there anything in the Windows Error Log about PostgreSQL?

Is there anything of interest at the end of the most recent log file in the "pg_log" subdirectory of the PostgreSQL data directory?

--
Craig Ringer

Re: BUG #5224: After upgrading from vista to windows 7, postgres services are missing

2009-12-02T07:51:46Z

1. After I reinstalled the latest version of postgresql, I do see a service called postgresql-8.4.

2. It is started automatically.

Please note, however, that I am still not able to connect to the database. For example, trying to use psql gives me the following error:

psql: could not connect to server: Cannot assign requested address (0x00002741/1

0049)

Is the server running on host "localhost" and accepting

TCP/IP connections on port test?

I have never seen this error before my OS upgrade.

3. I looked through the Windows Event Viewer but didn't anything related to postgres.

4. I believe ever since I upgraded, the pg_log logs have been empty. There is nothing much interesting in the prior few logs (just info messages about starting up and shutting down etc.)

Thanks for the prompt response.

Sriram

On Wed, Dec 2, 2009 at 1:07 AM, Craig Ringer <craig@...> wrote:

On 2/12/2009 12:57 PM, Sriram Gopalan wrote:

The following bug has been logged online:

Bug reference: 5224
Logged by: Sriram Gopalan
Email address: sriramgopalan@...
PostgreSQL version: 8.4.1
Operating system: Windows 7
Description: After upgrading from vista to windows 7, postgres
services are missing
Details:

I recently upgraded my machine from windows vista to window 7. I had
installed postgresql 8.4.1 on that machine and it was working great.
However, after upgrade, I cannot even see the services related to postgres.
When I try to connect, I get the message that postgres is not running and
listening to its port.

In the services control panel (start -> run ->services.msc , or via Control Panel -> Administrative Tools) can you see the postgresql service listed?

What state is it in?

Is there anything in the Windows Error Log about PostgreSQL?

Is there anything of interest at the end of the most recent log file in the "pg_log" subdirectory of the PostgreSQL data directory?

--
Craig Ringer

BUG #5226: Limit operator slows down

2009-12-02T06:35:21Z

The following bug has been logged online:

Bug reference: 5226
Logged by: aftab
Email address: akhangd@...
PostgreSQL version: 8.3.8
Operating system: Centos 5
Description: Limit operator slows down
Details:

S1="SELECT *
FROM position WHERE
position.POSITION_STATE_ID=2 AND
position.TARGET_ID=18
ORDER BY position.ID DESC
";
S2="SELECT *
FROM position WHERE
position.POSITION_STATE_ID=2 AND
position.TARGET_ID=18
ORDER BY position.ID DESC
LIMIT 1
";

S1 takes 0.16ms compared to S2 which takes 5 secs. Both S1 and S2 are same
except "LIMIT 1 " is added to S2.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

BUG #5225: create table: cast necessary for constant??

2009-12-02T04:45:15Z

The following bug has been logged online:

Bug reference: 5225
Logged by: Kurt wagner
Email address: kurt.wagnerextern@...
PostgreSQL version: 8.41
Operating system: HP-UX
Description: create table: cast necessary for constant??
Details:

During migration from Informix to Postgres I came across following issue:
create temp table temp1 as
SELECT firmnr,
werknr,
'I' as invper,
invnum
from .... ;

the next select on table temp1 returned the error
ERROR: failed to find conversion function from unknown to character [SQL
State=XX000]

I could find out that the column invper in the temp. table temp1 was defined
as data type "unknown". To me it is a bug because the column is filled by a
constant. So regardless if you estimate it as char, varchar, or text it is
still processable whereas "unknown" is the worst case and returns an error
as described above.

other DBs (e.g. db2, or Informix) can handle such cases correctly.

is it possible to fix it, please?

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5224: After upgrading from vista to windows 7, postgres services are missing

2009-12-02T01:07:06Z

On 2/12/2009 12:57 PM, Sriram Gopalan wrote:

>
> The following bug has been logged online:
>
> Bug reference: 5224
> Logged by: Sriram Gopalan
> Email address: sriramgopalan@...
> PostgreSQL version: 8.4.1
> Operating system: Windows 7
> Description: After upgrading from vista to windows 7, postgres
> services are missing
> Details:
>
> I recently upgraded my machine from windows vista to window 7. I had
> installed postgresql 8.4.1 on that machine and it was working great.
> However, after upgrade, I cannot even see the services related to postgres.
> When I try to connect, I get the message that postgres is not running and
> listening to its port.

In the services control panel (start -> run ->services.msc , or via
Control Panel -> Administrative Tools) can you see the postgresql
service listed?

What state is it in?

Is there anything in the Windows Error Log about PostgreSQL?

Is there anything of interest at the end of the most recent log file in
the "pg_log" subdirectory of the PostgreSQL data directory?

--
Craig Ringer

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5222: failed to run initdb: 1!

2009-12-02T00:51:19Z

On Wed, Dec 2, 2009 at 1:12 AM, Craig Ringer
<craig@...> wrote:

> On 2/12/2009 2:25 AM, Nicolas urtizberea wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference: 5222
>> Logged by: Nicolas urtizberea
>> Email address: nurtizberea@...
>> PostgreSQL version: 8.3.1-1
>> Operating system: Windows XP Fundamentals for Legacy Pc`s SP3
>
> Wow, really?
>
> I'm not at all sure PostgreSQL has been tested on that. It's hard to get
> hold of copies, for one thing.

Yeah, I can't even get it with my MSDN premium subscription :-(. If I
could, I'd test it....

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

BUG #5224: After upgrading from vista to windows 7, postgres services are missing

2009-12-01T20:57:13Z

The following bug has been logged online:

Bug reference: 5224
Logged by: Sriram Gopalan
Email address: sriramgopalan@...
PostgreSQL version: 8.4.1
Operating system: Windows 7
Description: After upgrading from vista to windows 7, postgres
services are missing
Details:

I recently upgraded my machine from windows vista to window 7. I had
installed postgresql 8.4.1 on that machine and it was working great.
However, after upgrade, I cannot even see the services related to postgres.
When I try to connect, I get the message that postgres is not running and
listening to its port.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5222: failed to run initdb: 1!

2009-12-01T17:12:48Z

On 2/12/2009 2:25 AM, Nicolas urtizberea wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5222
> Logged by: Nicolas urtizberea
> Email address: nurtizberea@...
> PostgreSQL version: 8.3.1-1
> Operating system: Windows XP Fundamentals for Legacy Pc`s SP3

Wow, really?

I'm not at all sure PostgreSQL has been tested on that. It's hard to get
hold of copies, for one thing. I don't know what Microsoft cut out for
XP Fundamentals, but I wouldn't be too surprised if it broke PostgreSQL
since Pg relies on proper, working service accounts and the like.

Another person reported the same issue with a version of Windows Embedded:

http://archives.postgresql.org/pgsql-bugs/2009-03/msg00028.php

... which further suggests that it might be problems caused by a limited
Windows version. Try digging through these search results to see if you
find anything useful:

http://www.google.com.au/search?q=%22The+system+cannot+find+the+file+specified%22+site%3Apostgresql.org

It'd be nice to know why this happens, since it might be easy to work
around and get Pg working on these versions of Windows. It's hard to
know what's going on, though.

It'd be helpful if you could provide a process monitor log (in native
process monitor format) of the installation process, since that might
shed some light.

--
Craig Ringer

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: psql -1 -f - busted

2009-12-01T14:34:40Z

Applied. Thanks for the report.

---------------------------------------------------------------------------

Bruce Momjian wrote:

> Robert Haas wrote:
> > On Fri, Nov 27, 2009 at 1:42 AM, Peter Eisentraut <peter_e@...> wrote:
> > > On tor, 2009-11-26 at 22:59 -0500, Robert Haas wrote:
> > >> ISTM that if you run psql with "-f -", you shouldn't expect to get an
> > >> interactive shell. ?Rather, you should expect psql to do whatever it
> > >> normally does when given -f somefilename, except using stdin rather
> > >> than the file. ?After all, you could have left out -f altogether if
> > >> you'd wanted the interactive behavior. ?But then IJWH.
> > >
> > > But by that logic, psql < file should also set interactive mode.
> >
> > Those two cases are not symmetrical. If you're reading from something
> > other than a terminal, you certainly don't want interactive mode. If
> > you ARE reading from a terminal, you might nevertheless want
> > non-interactive mode. And you CERTAINLY might want -1 when reading a
> > pipe, as when you do this:
> >
> > ssh otherhost pg_dump | psql -1 -f -
> >
> > Currently, this silently fails to deliver the expected behavior.
>
> You are right --- there is definitely something wrong with that code. I
> tried to find out why it was coded that way but that code hasn't changed
> since 2000 or 2001. My guess is that is was OK then, but when we added
> "-1" we didn't think about its placement.
>
> I think the proper, consistent fix is to check for "-" inside
> process_file(), rather than earlier. The attached patch accomplishes
> this. The code still goes into interactive mode, though:
>
> $ psql -f - test
> test=>
>
> Should that prompt not appear? Seems OK to me.
>
> --
> Bruce Momjian <bruce@...> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +

[ text/x-diff is unsupported, treating like TEXT/PLAIN ]

> Index: src/bin/psql/command.c
> ===================================================================
> RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v
> retrieving revision 1.211
> diff -c -c -r1.211 command.c
> *** src/bin/psql/command.c 22 Nov 2009 05:20:41 -0000 1.211
> --- src/bin/psql/command.c 30 Nov 2009 13:47:17 -0000
> ***************
> *** 1691,1698 ****
> if (!filename)
> return EXIT_FAILURE;
>
> ! canonicalize_path(filename);
> ! fd = fopen(filename, PG_BINARY_R);
>
> if (!fd)
> {
> --- 1691,1703 ----
> if (!filename)
> return EXIT_FAILURE;
>
> ! if (strcmp(filename, "-") != 0)
> ! {
> ! canonicalize_path(filename);
> ! fd = fopen(filename, PG_BINARY_R);
> ! }
> ! else
> ! fd = stdin;
>
> if (!fd)
> {
> Index: src/bin/psql/startup.c
> ===================================================================
> RCS file: /cvsroot/pgsql/src/bin/psql/startup.c,v
> retrieving revision 1.156
> diff -c -c -r1.156 startup.c
> *** src/bin/psql/startup.c 5 Apr 2009 04:19:58 -0000 1.156
> --- src/bin/psql/startup.c 30 Nov 2009 13:47:17 -0000
> ***************
> *** 225,231 ****
> /*
> * process file given by -f
> */
> ! if (options.action == ACT_FILE && strcmp(options.action_string, "-") != 0)
> {
> if (!options.no_psqlrc)
> process_psqlrc(argv[0]);
> --- 225,231 ----
> /*
> * process file given by -f
> */
> ! if (options.action == ACT_FILE)
> {
> if (!options.no_psqlrc)
> process_psqlrc(argv[0]);

>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@...)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs

--
Bruce Momjian <bruce@...> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5216: pgFouine 1.1 not working correctly, when LC_MESSAGES is "es_ES.UTF-8"

2009-12-01T13:52:38Z

Guillaume Smet escribió:

> Henrik,
>
> On Fri, Nov 27, 2009 at 4:15 AM, Henrik Pestano <hpestano@...> wrote:
> > I have a problem with the parameter LC_MESSAGES, where its value is
> > es_ES.UTF-8 (Spanish), the pgFouine 1.1 not work correctly, because csvlog
> > generates a column "duración: 0138 ms sentencia: SELECT format_type (oid,
> > 54) as typname pg_type FROM WHERE oid = 1043" and pgFouine not understand
> > the words "duración" and "sentencia". This information can be in two
> > columns.
>
> Please note that pgsql-bugs mailing list is for PostgreSQL bugs only.

Well, it begs the question: why are those spilled out as translated
words and not as their own columns? It can be construed as a Postgres
bug.

(As a note, I suggested Henrik to report this here for this reason).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

BUG #5222: failed to run initdb: 1!

2009-12-01T10:25:06Z

The following bug has been logged online:

Bug reference: 5222
Logged by: Nicolas urtizberea
Email address: nurtizberea@...
PostgreSQL version: 8.3.1-1
Operating system: Windows XP Fundamentals for Legacy Pc`s SP3
Description: failed to run initdb: 1!
Details:

The files belonging to this database system will be owned by user "SYSTEM".
This user must also own the server process.

The database cluster will be initialized with locale English_United
States.1252.
The default text search configuration will be set to "english".

creating directory C:/Program Files/PostgreSQL/8.3/data ... ok
creating subdirectories ... ok
selecting default max_connections ... The system cannot find the file
specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
10
selecting default shared_buffers/max_fsm_pages ... The system cannot find
the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
400kB/20000
creating configuration files ... ok
creating template1 database in C:/Program Files/PostgreSQL/8.3/data/base/1
... ok
initializing pg_authid ... The system cannot find the file specified.
child process exited with exit code 1
initdb: removing data directory "C:/Program Files/PostgreSQL/8.3/data"

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

bug

2009-12-01T10:16:47Z

The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale C.

fixing permissions on existing directory C:/Program Files/PostgreSQL/8.2/data ... ok
creating subdirectories ... ok
selecting default max_connections ... The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
10
selecting default shared_buffers/max_fsm_pages ... The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
400kB/20000
creating configuration files ... ok
creating template1 database in C:/Program Files/PostgreSQL/8.2/data/base/1 ... ok
initializing pg_authid ... The system cannot find the file specified.
child process exited with exit code 1
initdb: removing contents of data directory "C:/Program Files/PostgreSQL/8.2/data"

-------------------------------------------------------------------------------------------

The files belonging to this database system will be owned by user "SYSTEM".
This user must also own the server process.

The database cluster will be initialized with locale English_United States.1252.
The default text search configuration will be set to "english".

creating directory C:/Program Files/PostgreSQL/8.3/data ... ok
creating subdirectories ... ok
selecting default max_connections ... The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
10
selecting default shared_buffers/max_fsm_pages ... The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
400kB/20000
creating configuration files ... ok
creating template1 database in C:/Program Files/PostgreSQL/8.3/data/base/1 ... ok
initializing pg_authid ... The system cannot find the file specified.
child process exited with exit code 1
initdb: removing data directory "C:/Program Files/PostgreSQL/8.3/data"

-----------------------------------------------------------------

Windows xp fundamentals for legacy pc`s SP3

AMD Athlon 64 dual (5200)

1.75Gz RAM

HELP!

--
Nicolás Daniel Urtizberea

Re: BUG #5221: errors converting string to utf8

2009-12-01T07:30:12Z

Craig Ringer <craig@...> writes:
> On 1/12/2009 7:36 PM, DM wrote:
>> select convert('Vall\xe9e','LATIN1','UTF8');

> You expect the result 'VallÃ©e', right? As in the utf-8 bytes
> Vall\xc3\xa9e
> ?

The whole thing seems like an exercise in unnecessary pain anyway.
Why not just set client_encoding to LATIN1 and send your strings
as-is, letting the server deal with the encoding conversion
automatically?

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: BUG #5221: errors converting string to utf8

2009-12-01T05:03:23Z

On 1/12/2009 7:36 PM, DM wrote:

> select convert('Vall\xe9e','LATIN1','UTF8');

You expect the result 'Vallée', right? As in the utf-8 bytes

Vall\xc3\xa9e

?

> ERROR: invalid byte sequence for encoding "UTF8": 0xe965
> HINT: This error can also happen if the byte sequence does not match the
> encoding expected by the server, which is controlled by "client_encoding".

The HINT tells you what's going on here.

The error isn't being raised by convert(...). You'll get the same error
if you just:

select 'Vall\xe9e';

... because the problem is that the server is trying to treat that
literal as a string in your client_encoding, which is UTF-8, and convert
it to the server encoding.

You will note that the convert(...) function takes a 'bytea' argument
rather than 'text'. That's because PostgreSQL string literals are
expected to be valid text in the current encoding. Entering a string
literal with a byte sequence invalid in the current encoding will be
problematic. You need to supply a valid bytea value, which involves
juggling some interesting double-escaping and using octal escapes for
characters.

The octal escape for the byte 0xe9 is \351, so to correctly submit your
query to PostgreSQL you'd need to send:

select convert(E'Vall\\351e','LATIN1','UTF8');

or if you really just want to convert to the server encoding:

select convert_from(E'Vall\\351e','LATIN-1');

Here, E'' is used for the string to tell PostgreSQL to interpret
escapes, and \\351 is used as the octal escape for 0xe9. We double the
backslashes because the first backslash gets used up parsing the
literal, and we want the bytea value to actually be 'Val\351e' after
string literal parsing.

Instead, if standard_conforming_strings is on, you can omit the E'' and
use single backslashes.

Note that in 8.5 and above you could use E'Val\\xe9e' instead of the
octal form, as 8.5 understands hex escapes in bytea values.

I guess bytea is kind of ugly to use in a text-based protocol :-(
because the query string has to be valid text in the client_encoding, so
bytea values containing data not valid in the client encoding must be
escaped in the parsed query string. There's nothing much to be done
about it, though.

--
Craig Ringer

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

BUG #5221: errors converting string to utf8

2009-12-01T03:36:08Z

The following bug has been logged online:

Bug reference: 5221
Logged by: DM
Email address: dmedri@...
PostgreSQL version: 8.2 / 8.4
Operating system: linux ubuntu 9.10
Description: errors converting string to utf8
Details:

I'm using 2 version of pg (8.2, 8.4).

On 8.2:

select convert('Vall\xe9e','LATIN1','UTF8');

convert this string without any kind of error.

On 8.4:

select convert('Vall\xe9e','LATIN1','UTF8');

i receive these messages:

WARNING: nonstandard use of escape in a string literal
RIGA 1: select convert('Vall\xe9e','LATIN1','UTF8');
^
HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
ERROR: invalid byte sequence for encoding "UTF8": 0xe965
HINT: This error can also happen if the byte sequence does not match the
encoding expected by the server, which is controlled by "client_encoding".

client charset: utf8
server charset: utf8

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs