Hi,
while restoring backup i have received these messages
WARNING: column "id" has type "unknown"
DETAIL: Proceeding with relation creation anyway.
I have tried to grep schema-only dump file, but i didn't find word unknown.
When i have extracted all mentioned ID fields i didn't find any field wh
=?UTF-8?Q?Viktor_Bojovi=C4=87?= writes:
> while restoring backup i have received these messages
> WARNING: column "id" has type "unknown"
> DETAIL: Proceeding with relation creation anyway.
It's most likely a view with an output column that's an undecorated
string literal.
> I have tried to gr
On Wed, May 4, 2011 at 3:58 PM, Tom Lane wrote:
> =?UTF-8?Q?Viktor_Bojovi=C4=87?= writes:
> > while restoring backup i have received these messages
> > WARNING: column "id" has type "unknown"
> > DETAIL: Proceeding with relation creation anyway.
>
> It's most likely a view with an output colum
Hi *
We have a new web-app in our intranet and a existing database (Postgre 8). The user is login on web-app by Kerberos
(SSO). Now it's important to delegate the user ticket to database because every user has a database user. Is there a
way to authentificate via Kerberos with ProxyTicket? I h
I have 2 servers 1 for development (called dev) 1 for production (called
prod). The server for development is very basic (a dual core 2.1ghtz on
a basic 300MB hard drive with 2GB of memory (this server is not
dedicated to postgres, it also uses php, mapserver and so on).
I assigned the memory
>> 5. Finally, I'll drop the indexes on the parent table and
>> truncate it.
Luckily I noticed the problem with TRUNCATE and partitioning before my
work got to production.
TRUNCATE cascades automatically and silently to child tables, which was
not my intent.
This is mentioned here:
http://wiki.
On Wed, May 4, 2011 at 10:48 AM, Mark Stosberg wrote:
>
>>> 5. Finally, I'll drop the indexes on the parent table and
>>> truncate it.
>
> Luckily I noticed the problem with TRUNCATE and partitioning before my
> work got to production.
>
> TRUNCATE cascades automatically and silently to child tabl
On 05/04/2011 12:54 PM, Scott Marlowe wrote:
> On Wed, May 4, 2011 at 10:48 AM, Mark Stosberg wrote:
>>
5. Finally, I'll drop the indexes on the parent table and
truncate it.
>>
>> Luckily I noticed the problem with TRUNCATE and partitioning before my
>> work got to production.
>>
>> TRU
On Wed, May 4, 2011 at 11:04 AM, Mark Stosberg wrote:
> It is not as findable as it could be then. Besides scanning the page, I
> also searched for "child", "parent" and "partition", and none of those
> words are mentioned. Neither is "inherit". Pulling out "ONLY" to have
> it's own "Parameter" su
adrien ducos wrote:
[rearranged somewhat]
> The version of both databases is postgres 8.4.1
[sigh] You really should upgrade.
http://www.postgresql.org/support/versioning
http://www.postgresql.org/docs/8.4/static/release.html
> So I checked the memory on prod during my query execution
Scott Marlowe writes:
> On Wed, May 4, 2011 at 11:04 AM, Mark Stosberg wrote:
>> Further, since TRUNCATE permanently and instantly deletes mass amounts
>> of data, I would hope that it would provide "safety" by default, but
>> only truncating one table unless I specify otherwise.
The reason it w
Tobias Schneider wrote:
> We have a new web-app in our intranet and a existing database
> (Postgre 8).
Under PostgreSQL version numbering a major release number includes
the first digit past the decimal point, so you could be talking
about any of five major releases.
> The user is login on w
Tomasz Chmielewski wrote:
> On 1st May, I saw this message in my postgres log:
>
> May 2 06:52:02 db10 postgres[3590]: [29829-1] 2011-05-02 06:52:02
> SGT ERROR: could not access status of transaction 1573786613
> May 2 06:52:02 db10 postgres[3590]: [29829-2] 2011-05-02 06:52:02
> SGT DETAIL
On 04.05.2011 20:14, Kevin Grittner wrote:
> Tomasz Chmielewski wrote:
>
>> On 1st May, I saw this message in my postgres log:
>>
>> May 2 06:52:02 db10 postgres[3590]: [29829-1] 2011-05-02 06:52:02
>> SGT ERROR: could not access status of transaction 1573786613
>> May 2 06:52:02 db10 postgres
Tomasz Chmielewski wrote:
> This repeated many times:
>
> /var/log/postgresql/postgresql_log.1:May 3 18:24:49 db10
> postgres[21363]: [26999-1] 2011-05-03 18:24:49 SGT ERROR: could
> not access status of transaction 1573786613
> /var/log/postgresql/postgresql_log.1-May 3 18:24:49 db10
< post
On Wed, May 4, 2011 at 12:37 PM, Tomasz Chmielewski wrote:
> /var/log/postgresql/postgresql_log.1:May 3 18:24:49 db10 postgres[21363]:
> [26999-1] 2011-05-03 18:24:49 SGT ERROR: could not access status of
> transaction 1573786613
> /var/log/postgresql/postgresql_log.1-May 3 18:24:49 db10 post
On 04.05.2011 21:50, Scott Marlowe wrote:
> Then another pg_clog file disappeared.
>
> Is it possible there's some rogue process deleting files in pg_clog
> somehow?
I don't think.
> Have you run an fsck on this drive to make sure it's not got
> any file system errors?
Also, don't think there
On 04.05.2011 22:13, Tomasz Chmielewski wrote:
> On 04.05.2011 21:50, Scott Marlowe wrote:
>
>> Then another pg_clog file disappeared.
OK, I have:
bookstor=# SELECT * FROM core_wot_seq;
sequence_name | last_value | increment_by | max_value | min_value
| cache_value | log_cnt | is_
Hi All -
I am getting the following error while starting postgres 9.0.3. And when
it happens I could not establish new connections and the following error
messages keeps on coming up.
Are you guys aware of this problem? Is it a bug? It has happened to me
twice already. We are running this on r
Dump/restore of table resolved this problem.
On Wed, May 4, 2011 at 8:22 AM, Sam Stearns wrote:
> Does anyone else have any ideas on how to solve this problem besides
> this mysterious repair command?
>
> On Tue, May 3, 2011 at 6:33 PM, Sam Stearns wrote:
>> -- Forwarded message
Quoting Mark Stosberg :
5. Finally, I'll drop the indexes on the parent table and
truncate it.
Luckily I noticed the problem with TRUNCATE and partitioning before my
work got to production.
TRUNCATE cascades automatically and silently to child tables, which was
not my intent.
This is menti
21 matches
Mail list logo
