Okay. I guess so. Thanks for your help.
Regards,
Payal
On Fri, Jul 6, 2012 at 4:24 PM, Bruce Momjian wrote:
> On Fri, Jul 06, 2012 at 04:21:06PM -0400, Payal Singh wrote:
> > If something was wrong with the cluster, why did vacuumdb on new server
> run
> > successfully when I followed Craig's s
On Fri, Jul 06, 2012 at 04:21:06PM -0400, Payal Singh wrote:
> If something was wrong with the cluster, why did vacuumdb on new server run
> successfully when I followed Craig's suggestion of running vacuumdb on old
> server first, before performing the upgrade, and then ran vacuumdb on new one?
M
If something was wrong with the cluster, why did vacuumdb on new server run
successfully when I followed Craig's suggestion of running vacuumdb on old
server first, before performing the upgrade, and then ran vacuumdb on new
one?
On Fri, Jul 6, 2012 at 4:05 PM, Bruce Momjian wrote:
> On Fri, Jul
On Fri, Jul 06, 2012 at 04:03:38PM -0400, Payal Singh wrote:
> The omnipitr-backup-slave process takes online backups from the standby, and
> this is done everyday. This process connects to the master and calls a
> pg_start_backup and then looks for a restore point on the standby after that
> WAL a
The omnipitr-backup-slave process takes online backups from the standby,
and this is done everyday. This process connects to the master and calls a
pg_start_backup and then looks for a restore point on the standby after
that WAL address. So i don't think I need to shut down the server.
Also, it is
On Fri, Jul 06, 2012 at 02:22:28PM -0400, Payal Singh wrote:
> The first message in the log is probably because the backup is taken from a
> standby. I am using omnipitr-backup-slave to make the backups and then
> restoring one of those.
OK, this is what I wanted to see. Is the server running whi
On Fri, Jul 06, 2012 at 01:20:21PM -0400, Payal Singh wrote:
> Hi,
>
> I restored the backup on 9.1, made sure the database reached a consistent
> state
> and checkpointed. Then I performed the upgrade. Upgrade completed successfully
> but on running vacuumdb it gave the exact same error. The con
On Thu, Jul 05, 2012 at 06:28:31PM -0400, Tom Lane wrote:
> Payal Singh writes:
> > On Thu, Jul 5, 2012 at 12:15 PM, Craig Ringer wrote:
> >> If you start 9.1 on a copy of the backup then cleanly stop it again, does
> >> pg_upgrade then run?
>
> > Thank you. That worked.
>
> ISTM that pg_upgrad
Payal Singh writes:
> On Thu, Jul 5, 2012 at 12:15 PM, Craig Ringer wrote:
>> If you start 9.1 on a copy of the backup then cleanly stop it again, does
>> pg_upgrade then run?
> Thank you. That worked.
ISTM that pg_upgrade should check that the old cluster was shut down
cleanly, ie pg_control h
Thank you. That worked.
Regards
Payal
On Thu, Jul 5, 2012 at 12:15 PM, Craig Ringer wrote:
> On 07/05/2012 11:20 PM, Payal Singh wrote:
>
> Hello,
>
> I am trying to use pg_upgrade to upgrade data from 9.1.4 to 9.2beta2.
> Although the upgrade completed successfully, vacuumdb --all --analyze
On 07/05/2012 11:20 PM, Payal Singh wrote:
Hello,
I am trying to use pg_upgrade to upgrade data from 9.1.4 to 9.2beta2.
Although the upgrade completed successfully, vacuumdb --all
--analyze-only gives an error. I tried upgrading two binary backups of
the same production database from differen
Hi,
What platform? What does the server log says? Please refer to
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems for reporting
issues.
On Thu, May 17, 2012 at 11:52 AM, Karthik Ramasamy S <
karthik.ramas...@bahwancybertek.com> wrote:
> Hi All,
>
>
>
> We currently installed the po
On Fri, Mar 11, 2011 at 9:31 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Thu, Mar 10, 2011 at 10:37 PM, Bruce Momjian wrote:
>> > Robert Haas wrote:
>> >> On Thu, Mar 10, 2011 at 4:08 PM, Bruce Momjian wrote:
>> >> > Was this fixed?
>> >>
>> >> Not yet. ?I can probably fix it, if nobody
Robert Haas wrote:
> On Thu, Mar 10, 2011 at 10:37 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Thu, Mar 10, 2011 at 4:08 PM, Bruce Momjian wrote:
> >> > Was this fixed?
> >>
> >> Not yet. ?I can probably fix it, if nobody else wants to do it.
> >
> > Well, it has languished for five m
On Thu, Mar 10, 2011 at 10:37 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Thu, Mar 10, 2011 at 4:08 PM, Bruce Momjian wrote:
>> > Was this fixed?
>>
>> Not yet. I can probably fix it, if nobody else wants to do it.
>
> Well, it has languished for five months, so the "nobody else wants" p
Robert Haas wrote:
> On Thu, Mar 10, 2011 at 4:08 PM, Bruce Momjian wrote:
> > Was this fixed?
>
> Not yet. I can probably fix it, if nobody else wants to do it.
Well, it has languished for five months, so the "nobody else wants" part
is probably accurate. ;-)
--
Bruce Momjian htt
On Thu, Mar 10, 2011 at 4:08 PM, Bruce Momjian wrote:
> Was this fixed?
Not yet. I can probably fix it, if nobody else wants to do it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
Was this fixed?
---
Alvaro Herrera wrote:
> Excerpts from Alvaro Herrera's message of jue nov 18 15:31:16 -0300 2010:
> > Excerpts from Robert Haas's message of jue nov 18 15:11:37 -0300 2010:
> >
> > > In the current maste
On Thu, Nov 18, 2010 at 1:35 PM, Alvaro Herrera
wrote:
> Excerpts from Alvaro Herrera's message of jue nov 18 15:31:16 -0300 2010:
>> Excerpts from Robert Haas's message of jue nov 18 15:11:37 -0300 2010:
>>
>> > In the current master branch, it appears that "ALTER TABLE c INHERIT
>> > p" takes a
Excerpts from Alvaro Herrera's message of jue nov 18 15:31:16 -0300 2010:
> Excerpts from Robert Haas's message of jue nov 18 15:11:37 -0300 2010:
>
> > In the current master branch, it appears that "ALTER TABLE c INHERIT
> > p" takes a ShareUpdateExclusiveLock on the child, which seems
> > suffic
Excerpts from Robert Haas's message of jue nov 18 15:11:37 -0300 2010:
> In the current master branch, it appears that "ALTER TABLE c INHERIT
> p" takes a ShareUpdateExclusiveLock on the child, which seems
> sufficient, and an AccessShareLock on the parent, which seems like it
> might not be; thou
On Thu, Nov 18, 2010 at 10:28 AM, Jon Nelson wrote:
> On Wed, Nov 17, 2010 at 8:57 PM, Robert Haas wrote:
>> On Tue, Nov 16, 2010 at 10:48 AM, Jon Nelson
>> wrote:
>>> I have a process which runs in parallel creating tables which, as the
>>> /final/ step in the import, gets SQL much like the fo
On Wed, Nov 17, 2010 at 8:57 PM, Robert Haas wrote:
> On Tue, Nov 16, 2010 at 10:48 AM, Jon Nelson
> wrote:
>> I have a process which runs in parallel creating tables which, as the
>> /final/ step in the import, gets SQL much like the following applied:
>>
>> ALTER TABLE foo INHERIT bar;
>>
>> P
On Tue, Nov 16, 2010 at 10:48 AM, Jon Nelson wrote:
> I have a process which runs in parallel creating tables which, as the
> /final/ step in the import, gets SQL much like the following applied:
>
> ALTER TABLE foo INHERIT bar;
>
> Periodically, I get this error: tuple concurrently updated
>
> O
On 10/16/2010 08:58 PM, Robert Haas wrote:
2010/10/13 Sergey Burladyan:
IMHO you can receive question-marks here if lc_messages in postgresql.conf
do not match with locale from environment at server start, for example:
correctly translated and displayed:
$ LANG=ru_RU.UTF-8 ../bin/postgres -D d
On 4/04/2010 7:03 PM, Cedric CHAUVET wrote:
Hi
I had v8.3.0 and tried to upgrade it to v8.3.9-1.
I download and unzip. Then I double click on UPGRADE.bat.
During the installation, it stopped and pop up a window where it's written:
"An error occured during the installation of
assembly'policy.8.0.
p...@onet.eu writes:
> 2010-01-27 10:34:01 CET [3931]: [9-1] host=,user=,db= LOG: server process
> (PID 24454) was terminated by signal 11: Segmentation fault
> I have 8.4.0 version.
The *first* thing to do is update to 8.4.2 to see if the problem was
already fixed.
If not, you need to try to
On Mon, Sep 21, 2009 at 3:23 PM, Christine Penner
wrote:
> At 11:57 AM 21/09/2009, you wrote:
>>
>> What error you get when you run initdb?? (Also what exact command you
>> run?)
>
> The first time I just double clicked on the file initdb.exe. Just now I
> tried to run it through the command promp
At 11:57 AM 21/09/2009, you wrote:
What error you get when you run initdb?? (Also what exact command you run?)
The first time I just double clicked on the file initdb.exe. Just now
I tried to run it through the command prompt and go this, this is the
same stuff that was in the log file in the
On 09/21/2009 08:31 PM, Christine Penner wrote:
Hi,
I posted the following message to the General list a while ago. I am
still not able to run postgres at all.
I am trying to install Postgres 8.4. I had 8.3 installed. Because
I didn't have any important data, to make it easier I remo
"Merlin Moncure" writes:
> I _may_ have found a problem that is affecting non-greedy regex matches.
No, you didn't read the fine print in section 9.7.3.5; particularly
A branch -- that is, an RE that has no top-level | operator -- has the
same greediness as the first quantified atom in i
2009/1/5 Tomáš Dixa :
> Hello,
>
>
>
> I have problem with instalation on step 8 (on PostgreSQL Setup
> Instructions)-
>
> Initial database cluster.
>
>
>
> It´s written there – The Postere SQL data direktory must be on an NTFS
> formatted volume. If you wish
>
> to install the data direktory on an
lftsang wrote:
> Dear Sir,
>
> I tried to install PostgreSQL 8.1.15 on Freebsd 7.0. When I extracted
> the .tar.gz and inputed 'make' it shows the following error:
Did you try gmake?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulti
lftsang writes:
> I tried to install PostgreSQL 8.1.15 on Freebsd 7.0. When I extracted
> the .tar.gz and inputed 'make' it shows the following error:
> "/usr/share/mk/bsd.port.mk", line 11: Could not find
> /usr/ports/Mk/bsd.port.mk
> "Makefile", line 177: Malformed conditional (${ARCH} == spa
lftsang wrote:
Dear Sir,
I tried to install PostgreSQL 8.1.15 on Freebsd 7.0. When I extracted
the .tar.gz and inputed 'make' it shows the following error:
"/usr/share/mk/bsd.port.mk", line 11: Could not find
/usr/ports/Mk/bsd.port.mk
"Makefile", line 177: Malformed conditional (${ARCH} == s
Martin Gregorie <[EMAIL PROTECTED]> writes:
> For some reason, when my message table (see below) is dumped, blank
> lines are introduced between rows.
Nothing like that has been reported before. We have heard of dump files
getting corrupted after they've been produced --- the most common case
is
[EMAIL PROTECTED] wrote:
> select ats.id, ap.value from akh_test_suit ats
> LEFT JOIN akh_properties ap on ap.ID = ats.test_suit_type_id
> where ats.ID = 472
>
> id | value
> 472 | 472
> ID -- integer
> value -- text
>
>
> select * from akh_test_suit ats
> LEFT JOIN akh_properties ap on ap.ID
nt: Tuesday, August 26, 2008 1:15 PM
Subject: Re: [BUGS] Problem with planer
[EMAIL PROTECTED] wrote:
select ats.id, ap.value from akh_test_suit ats
LEFT JOIN akh_properties ap on ap.ID = ats.test_suit_type_id
where ats.ID = 472
id | value
472 | 472
ID -- integer
value -- text
select * from akh_t
[EMAIL PROTECTED] wrote:
select ats.id, ap.value from akh_test_suit ats
LEFT JOIN akh_properties ap on ap.ID = ats.test_suit_type_id
where ats.ID = 472
id | value
472 | 472
ID -- integer
value -- text
select * from akh_test_suit ats
LEFT JOIN akh_properties ap on ap.ID = ats.test_suit_type_id
whe
flag *D:# dй: dйfaire, dйgrossir
. > dй
flag *N:# йlision d'une nйgation
[aавeийкiоoфuh] > n' # je n'aime pas, il n'y a pas
---
"Jean-Baptiste Quenot" <[EMAIL PROTECTED]> writes:
> I'm having problem with french dictionaries. Loading an ispell affix
> file with apostrophes does not work. The file comes from the ifrench
> (french dict for ispell) debian source package at
> http://packages.debian.org/sid/ifrench
> dockee=#
shohorab hossain wrote:
Dear sir/madam,
This is to inform you that I am an oracle database user/administrator. But I am
going to join in a company where I have to administrate postgresql database. I
am new to this database system. For few days I am trying to install
postgresql-8.3.1 in RHEL4
=?iso-8859-2?Q?Wojciech_Strza=B3ka?= <[EMAIL PROTECTED]> writes:
>> To make that happen would require (at least) a full table scan. I think
>> most people are more interested in DROP COLUMN being a cheap operation
>> than in having the space be reclaimed quickly.
>> For a comparison point: large
> To make that happen would require (at least) a full table scan. I think
> most people are more interested in DROP COLUMN being a cheap operation
> than in having the space be reclaimed quickly.
> For a comparison point: large field values that don't happen to get
> toasted don't vanish immedia
=?iso-8859-2?Q?Wojciech_Strza=B3ka?= <[EMAIL PROTECTED]> writes:
> In my opinion the fact that dropping column doesn't release it's toastable
> resources is a bug.
To make that happen would require (at least) a full table scan. I think
most people are more interested in DROP COLUMN being a cheap
The first record ctid=(0,1) is obsolete, you can delete it. It is probably race
condition in VACUUM and catalog modification. Did you added or modified any user
account (e.g. password change) in related time? Please, can you let us know
exact version of PostgreSQL?
Zdenek
Kho
Hi Alvaro
On Fri, Mar 28, 2008 at 6:05 PM, Alvaro Herrera <[EMAIL PROTECTED]>
wrote:
> NikhilS escribió:
>
> > I will take a look at the pg_dump related changes if you want. We will
> need
> > changes in flagInhAttrs() and in getTableAttrs() to query the backend
> for
> > these 2 attributes for p
On Fri, Mar 28, 2008 at 4:07 AM, NikhilS <[EMAIL PROTECTED]> wrote:
> Hi Alex,
>
>
> On Fri, Mar 28, 2008 at 4:58 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> > Attached is a WIP patch I have been playing with in my spare time. It
> > should take care of the first 2. It does nothing for pg_dump
NikhilS escribió:
> P.S Alvaro, I think this patch did not reach the mailing list and was
> stalled due to size restrictions or something.
OK, it's archived now:
http://archives.postgresql.org/pgsql-patches/2008-03/msg00392.php
Thanks.
--
Alvaro Herrerahttp://www
NikhilS escribió:
> P.S Alvaro, I think this patch did not reach the mailing list and was
> stalled due to size restrictions or something.
Argh, you are right. We don't have this on the archives anywhere :-(
Probably it got stuck on Maia ...
--
Alvaro Herrerahtt
Hi Alex,
On Fri, Mar 28, 2008 at 4:58 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 27, 2008 at 5:14 AM, NikhilS <[EMAIL PROTECTED]> wrote:
> > * Add logic to disallow ADD CONSTRAINT ONLY to parent of an inheritance
> > hierarchy
> >
> > * Add logic to mark inherited constraints in t
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
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
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> NikhilS escribió:
>> Ok, I understand. But even then this could patch could be considered even if
>> it does not solve the TODO completely, no? It atleast disallows ONLY ADD
>> CONSTRAINT on the parent.
> No, because you would then feel that the TODO it
Hi,
On Thu, Mar 20, 2008 at 6:11 PM, Alvaro Herrera <[EMAIL PROTECTED]>
wrote:
> NikhilS escribió:
>
> > On Wed, Mar 19, 2008 at 8:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > > If it's a small patch, it's wrong by definition. AFAICS there is no
> way
> > > to fix this correctly that doesn't
NikhilS escribió:
> On Wed, Mar 19, 2008 at 8:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > If it's a small patch, it's wrong by definition. AFAICS there is no way
> > to fix this correctly that doesn't involve catalog changes. The point
> > of the TODO is that you have to enforce that the inh
Hi,
On Wed, Mar 19, 2008 at 8:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> NikhilS <[EMAIL PROTECTED]> writes:
> > On Fri, Mar 7, 2008 at 6:37 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >> Added to TODO:
> >> o Require all CHECK constraints to be inherited
>
> > PFA, a small patch attached wh
NikhilS <[EMAIL PROTECTED]> writes:
> On Fri, Mar 7, 2008 at 6:37 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>> Added to TODO:
>> o Require all CHECK constraints to be inherited
> PFA, a small patch attached which should fix this.
If it's a small patch, it's wrong by definition. AFAICS there i
Hi,
On Fri, Mar 7, 2008 at 6:37 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Added to TODO:
>
> > o Require all CHECK constraints to be inherited
> >
> > http://archives.postgresql.org/pgsql-bugs/2007-04/msg00026.php
>
>
PFA, a small patch attached which should fix this. I have
Remove the "docs" feature from ADDLOCAL. This will prevent error 2711
(installation package could not be opened).
I also had problems using the SERVICEDOMAIN="%COMPUTERNAME% argument - it
seems to cause MSI to report errors 1708 and 1709 and aborts the
installation.
divya shree wrote:
>
> hi
Added to TODO:
> o Require all CHECK constraints to be inherited
>
> http://archives.postgresql.org/pgsql-bugs/2007-04/msg00026.php
---
Tom Lane wrote:
> "Chris Fischer" <[EMAIL PROTECTED]> writes:
> > alter
Andrew Shea <[EMAIL PROTECTED]> writes:
> However the following code doesn't work even though it is very similar
> to the first query (that is, and aggregate function within a case
> statement):
> select (SELECT CASE WHEN (1=2) THEN 0 ELSE COUNT(*) END) from (
^^
> select 1 as cou
On Fri, 11 May 2007 14:47:04 +1000, Andrew Shea <[EMAIL PROTECTED]> wrote:
> The following works as expected:
>
> select (SELECT CASE WHEN (1=2) THEN 0 ELSE sum(count) END) from (
> select 1 as count union select 2 union select 3
> ) as "temp";
>
> The result is "6".
>
> The following also work
"Chris Fischer" <[EMAIL PROTECTED]> writes:
> alter table only t1 add constraint ck_col1 check (number <> 0);
The bug here is that we allow that. Continuing your example,
regression=# insert into t2 values(0);
INSERT 0 1
regression=# select * from t1;
col1
--
0
(1 row)
which sure looks
Rob Schall <[EMAIL PROTECTED]> writes:
> I have to queries. One runs in about 2 seconds. The other takes upwards
> of 2 minutes. I have a temp table that is created with 2 columns. This
> table is joined with the larger database of call detail records.
> However, these 2 queries are handled very di
Adam <[EMAIL PROTECTED]> writes:
> The 'configure --enable-thread-safety' script fails when CFLAGS
> contain "-mcpu=7400", "-mcpu=970" or "-maltivec".
This has been discussed before, and the conclusion was "don't do that".
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00104.php
> I w
Adam wrote:
> Greetings,
>
> There is a problem with PostgreSQL 8.1.4 on Mac OS X (PowerPC).
>
> The 'configure --enable-thread-safety' script fails when CFLAGS
> contain "-mcpu=7400", "-mcpu=970" or "-maltivec". With these flags,
> the GCC compiler enables AltiVec instructions for the PowerP
Tom Lane wrote:
> julien <[EMAIL PROTECTED]> writes:
> > The INSTALL file mention the command "kill `cat
> > /usr/local/pgsql/data/postmaster.pid`" but the pid file contain the pid
> > but not only, it also contain data directory and some numbers (memory
> > usage ?, database characteristic ?)
>
julien <[EMAIL PROTECTED]> writes:
> The INSTALL file mention the command "kill `cat
> /usr/local/pgsql/data/postmaster.pid`" but the pid file contain the pid
> but not only, it also contain data directory and some numbers (memory
> usage ?, database characteristic ?)
Hm, I wonder why this docu
Mario <[EMAIL PROTECTED]> writes:
> I have a problem with connection if the postgresql 8.1.3
> Comand Line: postmaster -S -o -i -D data (Unix - Solaris OS)
^
-i is not a valid switch to use within -o. I think you probably meant
for -i to be a postmaster swit
Tom Lane wrote:
> Chris Dunlop <[EMAIL PROTECTED]> writes:
> > One way or the other, I think either allowing the inherited
> > constraints to be dropped, or the inability of pg_dump to
> > correctly dump the resulting schema, should be considered a bug
> > rather than a lacking feature, as the curr
On Wed, Feb 22, 2006 at 10:11:51AM -0500, Tom Lane wrote:
> Chris Dunlop <[EMAIL PROTECTED]> writes:
>> E.g. using the script below, the 'bar.f1' column in the 'new'
>> database ends up with a 'not null' constraint that isn't present
>> in the 'orig' database.
>
>> create table foo (f1 integer n
Chris Dunlop <[EMAIL PROTECTED]> writes:
> One way or the other, I think either allowing the inherited
> constraints to be dropped, or the inability of pg_dump to
> correctly dump the resulting schema, should be considered a bug
> rather than a lacking feature, as the current situation results
> in
Chris Dunlop <[EMAIL PROTECTED]> writes:
> E.g. using the script below, the 'bar.f1' column in the 'new'
> database ends up with a 'not null' constraint that isn't present
> in the 'orig' database.
> create table foo (f1 integer not null);
> create table bar () inherits(foo);
> alter table b
On Wed, 2005-10-12 at 19:28 -0400, Tom Lane wrote:
> Oliver Elphick writes:
> > On Wed, 2005-10-12 at 17:45 -0400, Tom Lane wrote:
> >> Hm. Could we see the actual pg_attribute data for both this table and
> >> its parent?
>
> > Here you are:
>
> Thanks. Nothing particularly strange-looking th
On Wed, Oct 12, 2005 at 07:28:37PM -0400, Tom Lane wrote:
> Oliver Elphick writes:
> > On Wed, 2005-10-12 at 17:45 -0400, Tom Lane wrote:
> >> Hm. Could we see the actual pg_attribute data for both this table and
> >> its parent?
>
> > Here you are:
>
> Thanks. Nothing particularly strange-loo
Oliver Elphick writes:
> On Wed, 2005-10-12 at 17:45 -0400, Tom Lane wrote:
>> Hm. Could we see the actual pg_attribute data for both this table and
>> its parent?
> Here you are:
Thanks. Nothing particularly strange-looking there though. Do you want
to try tracing through COPY with a debugge
On Wed, 2005-10-12 at 17:45 -0400, Tom Lane wrote:
> Oliver Elphick writes:
> > ... in this particular case, the column
> > order was wrong. I should add that the table inherits from another one,
> > but the swapped columns are a long way into the extra columns specific
> > to this table.
>
> Hm
Oliver Elphick writes:
> ... in this particular case, the column
> order was wrong. I should add that the table inherits from another one,
> but the swapped columns are a long way into the extra columns specific
> to this table.
Hm. Could we see the actual pg_attribute data for both this table
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Wed, Oct 12, 2005 at 08:23:15PM +0100, Oliver Elphick wrote:
>> I actually use CURRENT_DATE; that is what the system turns it into.
> Ah yes, I see that now. I generally use now(), so I hadn't noticed
> that CURRENT_DATE and CURRENT_TIMESTAMP become '
On Wed, Oct 12, 2005 at 08:17:23PM +0100, Oliver Elphick wrote:
> On Wed, Oct 12, 2005 at 12:19:41PM -0600, Michael Fuhr wrote:
> > Could you post the table definitions?
>
> Here it is:
I created the tables you posted (sans foreign key constraints because
you didn't include the referenced tables
On Wed, Oct 12, 2005 at 08:23:15PM +0100, Oliver Elphick wrote:
> On Wed, 2005-10-12 at 12:13 -0600, Michael Fuhr wrote:
> > On another note, regarding the following:
> >
> > > invdate | date | not null default
> > > ('now'::text)::date
> > > taxpoint | date
On Wed, 2005-10-12 at 12:37 -0600, Michael Fuhr wrote:
> On Wed, Oct 12, 2005 at 12:19:41PM -0600, Michael Fuhr wrote:
> > On Wed, Oct 12, 2005 at 07:08:20PM +0100, Oliver Elphick wrote:
> > > I should add that the table inherits from another one, but the
> > > swapped columns are a long way into t
On Wed, Oct 12, 2005 at 12:19:41PM -0600, Michael Fuhr wrote:
> On Wed, Oct 12, 2005 at 07:08:20PM +0100, Oliver Elphick wrote:
> > I should add that the table inherits from another one, but the
> > swapped columns are a long way into the extra columns specific to
> > this table.
>
> Could you pos
On Wed, Oct 12, 2005 at 07:08:20PM +0100, Oliver Elphick wrote:
> I should add that the table inherits from another one, but the
> swapped columns are a long way into the extra columns specific to
> this table.
Could you post the table definitions?
--
Michael Fuhr
---(en
On Wed, Oct 12, 2005 at 09:09:05AM +0100, Oliver Elphick wrote:
> Pg 8.0.3 (Debian package) on AMD64, linux 2.6.12
>
> I am importing a table using COPY. The data is tab-delimited. COPY
> seems to be putting the data for one field into the preceding field,
> which should contain the empty string
On Wed, 2005-10-12 at 13:52 -0400, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > Pg 8.0.3 (Debian package) on AMD64, linux 2.6.12
> > I am importing a table using COPY. The data is tab-delimited. COPY
> > seems to be putting the data for one field into the preceding field,
> >
Oliver Elphick <[EMAIL PROTECTED]> writes:
> Pg 8.0.3 (Debian package) on AMD64, linux 2.6.12
> I am importing a table using COPY. The data is tab-delimited. COPY
> seems to be putting the data for one field into the preceding field,
> which should contain the empty string.
Can't reproduce that
On Wed, 2005-10-12 at 09:09 +0100, Oliver Elphick wrote:
> Pg 8.0.3 (Debian package) on AMD64, linux 2.6.12
>
> I am importing a table using COPY. The data is tab-delimited. COPY
> seems to be putting the data for one field into the preceding field,
> which should contain the empty string.
To f
"Ing. Jhon Carrillo - Caracas, Venezuela" <[EMAIL PROTECTED]> writes:
> creating template1 database in /var/lib/pgsql/data/base/1 ... FATAL: XX000:
> failed to initialize lc_messages to ""
What PG version is this exactly, what platform are you running it on,
and what locale environment are you ru
Hi,
On Tue, 20 Sep 2005, Ing. Jhon Carrillo - Caracas, Venezuela wrote:
i have a problem when i run the initdb file, do you know anything?
bash-2.05b$ /usr/lib/postgresql/bin/initdb -D /var/lib/pgsql/data
The files belonging to this database system will be owned by user
"postgres".
This user
ell
- Original Message -
From: "Kevin Grittner" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
Sent: Monday, August 01, 2005 12:31 PM
Subject: Re: [BUGS] problem odbc 8.0 with EOModeler
It looks like this is being treated on the server as t
? (i don't need to add additional quotes for
other odbc data sources)
When query against numerical columns, things works quite well
- Original Message -
From: "Kevin Grittner" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
Sent: Monday,
s for
other odbc data sources)
When query against numerical columns, things works quite well
- Original Message -
From: "Kevin Grittner" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
Sent: Monday, August 01, 2005 12:31 PM
Subject: Re: [BUGS] probl
really indicate that EOModeler and postgresql-odbc can not communicate
correctly. in other words, postgresql-odbc has special API's that not make
sense to
EOModeler.
- Original Message -
From: "Kevin Grittner" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>;
Sent: Monday, A
ot make
sense to
EOModeler.
- Original Message -
From: "Kevin Grittner" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>;
Sent: Monday, August 01, 2005 8:25 AM
Subject: Re: [BUGS] problem odbc 8.0 with EOModeler
Is the column name "Elim" or "elim"? If
Is the column name "Elim" or "elim"? If the former, try putting quotes around
it, as required by the ANSI and ISO standards for mixed case identifiers. Some
database products fail to comply with the standards in this respect.
PostgreSQL comes close, although it treats unquoted identifers as a
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think you could create a btree operator class to make it all work.
Hm. Given that we've managed to build a general opclass for arrays,
I suppose it should be possible for records too. Hardly trivial though.
A closely related point is fixing row com
1 - 100 of 217 matches
Mail list logo
