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: Could not open file pg_clog/05DC:
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 which
=?UTF-8?Q?Viktor_Bojovi=C4=87?= viktor.bojo...@gmail.com 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
On Wed, May 4, 2011 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
=?UTF-8?Q?Viktor_Bojovi=C4=87?= viktor.bojo...@gmail.com writes:
while restoring backup i have received these messages
WARNING: column id has type unknown
DETAIL: Proceeding with relation creation anyway.
It's most
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
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
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:
On Wed, May 4, 2011 at 10:48 AM, Mark Stosberg m...@summersault.com 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
On 05/04/2011 12:54 PM, Scott Marlowe wrote:
On Wed, May 4, 2011 at 10:48 AM, Mark Stosberg m...@summersault.com 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.
On Wed, May 4, 2011 at 11:04 AM, Mark Stosberg m...@summersault.com 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
adrien ducos adu...@hbs-research.com 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
Scott Marlowe scott.marl...@gmail.com writes:
On Wed, May 4, 2011 at 11:04 AM, Mark Stosberg m...@summersault.com 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
Tobias Schneider t.schnei...@science-computing.de 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
Tomasz Chmielewski man...@wpkg.org 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
On 04.05.2011 20:14, Kevin Grittner wrote:
Tomasz Chmielewskiman...@wpkg.org 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
Tomasz Chmielewski man...@wpkg.org 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
On Wed, May 4, 2011 at 12:37 PM, Tomasz Chmielewski man...@wpkg.org 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
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 is
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 |
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
Dump/restore of table resolved this problem.
On Wed, May 4, 2011 at 8:22 AM, Sam Stearns samtstea...@gmail.com 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 samtstea...@gmail.com wrote:
Quoting Mark Stosberg m...@summersault.com:
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
22 matches
Mail list logo
