Dear Magnus,
I've sent another xml file to your e-mail. Let's see if this one is Ok...
Best regards,
Jomar
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your Subscription:
http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-hacke
chris.jurado napsal(a):
Sorry for sending this directly to the hackers mailing list. But, i think it
did not belong in any other as it involves internals about the files in the
data directory.
PostgreSQL version: 8.1.2
Operating system: Windows XP/2003
The PostgreSQL service is not startin
I'm working on implementing pg_check functions. Because I want to test
whole table I need catch a error and handle it myself. I use following
construct:
PG_TRY();
{
...
ereport(ERROR, (errmsg("Error test")));
...
}
PG_CATCH();
{
errcontext("Context error");
John Smith wrote:
BTW, I found a easier way of reproducing this (see attached 2pc.sql).
It might help with debugging or verifying a fix/regression.
Thanks.
[1] The data file is reported missing in the second transaction only
if the first transaction was ended using PREPARE TRANSACTION. The
er
Bruce Momjian wrote:
Heikki, are there any TODO items here?
Hmm. You could put an entry there for "profile and optimize COPY", with
the below list of ideas as a starting point. It's more about profiling
and performance testing than coding.
--
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I'm seeing a 8.3 database whose autovacuum-initiated vacuums are being
> > cancelled and I am not sure of the cause. I am wondering if a HOT
> > cleanup round on a page could try to acquire locks on it that would
> > conflict with au
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Actually ... why are we using the lock manager to drive this at all?
Good question. It has always seemed a bit strange to me. The assumption
that we always hold the lock on temp table until end of transaction,
Brendan Jurd escribió:
> I've done up a patch per Tom's idea of combining the binary role
> attributes into a single column.
This patch seems to be missing from the queue.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom D
Alvaro Herrera wrote:
> Brendan Jurd escribi?:
> > I've done up a patch per Tom's idea of combining the binary role
> > attributes into a single column.
>
> This patch seems to be missing from the queue.
Yes because I am still processing email from two weeks ago. I was in
Europe for a week.
--
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Br
Joshua D. Drake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mon, 3 Mar 2008 20:33:08 -0500 (EST)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > Added to TODO based on this discussion:
> >
> > o Allow pg_dump to utilize multiple CPUs and I/O channels by
> > dumping m
This morning I had a postgres 8.3 install core this morning while multiple
vacuum fulls were taking place. I saved the core file, would anyone be
interested in dissecting it? I've otherwise had no issues with this machine
or pgsql install.
Gavin
> Tatsuo Ishii wrote:
> >> On Tue, Feb 19, 2008 at 3:36 AM, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> >>
> > I hope so. But the first thing I would like to do is, to implement the
> > right thing (i.e. following the standard).
> >
> > I don't see any reason that the proposal gets less performa
bruce wrote:
> Joshua D. Drake wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Mon, 3 Mar 2008 20:33:08 -0500 (EST)
> > Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > > Added to TODO based on this discussion:
> > >
> > > o Allow pg_dump to utilize multiple CPUs
> > Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> >
> > > 5. Limitation with PostgreSQL
> > >
> > > 1) we do not implement SEARCH clause and CYCLE clause. This is because
> > >we need array of rows to implement them. Note that there's no
> > >support for array of rows in PostgreSQL.
> >
> >
Gavin M. Roy wrote:
> This morning I had a postgres 8.3 install core this morning while multiple
> vacuum fulls were taking place. I saved the core file, would anyone be
> interested in dissecting it? I've otherwise had no issues with this machine
> or pgsql install.
Of course. Please post the b
Zdenek Kotala wrote:
> PG_TRY();
> {
> ...
> ereport(ERROR, (errmsg("Error test")));
> ...
> }
> PG_CATCH();
> {
> errcontext("Context error");
> EmitErrorReport();
> FlushErrorState();
> }
> PG_END_TRY();
>
> At the end I got following message:
>
> ERROR:
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <[EMAIL PROTECTED]> writes:
2. Implement better selectivity estimates for FTS.
+1 for that one ...
OK, this one might very well be the one that'd be more useful. And I can
always reuse the other idea for my thesis, after expanding it a bit.
S
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
PG_TRY();
{
...
ereport(ERROR, (errmsg("Error test")));
...
}
PG_CATCH();
{
errcontext("Context error");
EmitErrorReport();
FlushErrorState();
}
PG_END_TRY();
At the end I got following message:
ERR
On Tue, Mar 4, 2008 at 4:47 PM, Jan Urbański
<[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
> > =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <[EMAIL PROTECTED]> writes:
> >> 2. Implement better selectivity estimates for FTS.
> >
> > +1 for that one ...
>
> OK, this one might very well be the one that'd be m
Jan,
> OK, this one might very well be the one that'd be more useful.
Well, you should submit *both* once SoC opens for applications. The mentors
will decide which.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
Jan,
the problem is known and well requested. From your promotion it's not
clear what's an idea ?
Oleg
On Tue, 4 Mar 2008, Jan Urbaski wrote:
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <[EMAIL PROTECTED]> writes:
2. Implement better selectivity estimates for FTS.
+1 for that one ...
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Alvaro Herrera napsal(a):
>> Zdenek Kotala wrote:
>>> At the end I got following message:
>>>
>>> ERROR: Error test
>>> CONTEXT: Context error
>>> server sent data ("D" message) without prior row description ("T" message)
>>
>> I don't see anything wr
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Looking back, I think it was driven by the desire to tie the behavior
>> directly to things that are going to get persisted, such as locks.
>> From that standpoint your initial patch to attach a temp-check to
>> relation-drop 2PC
Oleg Bartunov wrote:
Jan,
the problem is known and well requested. From your promotion it's not
clear what's an idea ?
I guess the first approach could be to populate some more columns in
pg_statistics for tables with tsvectors. I see there are some statistics
already being gathered (pg_stat
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
At the end I got following message:
ERROR: Error test
CONTEXT: Context error
server sent data ("D" message) without prior row description ("T" message)
I don't see anything wrong wi
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> John Smith wrote:
>> [3] I am not certain how widespread they might be, but I think there
>> may be some backward compatibility concerns with the patch you are
>> proposing.
> Well, the current behavior is certainly broken, so an application
> re
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> The first one is really not related to the others --- it just proposes
> that when renaming a table or individual column, we should look for
> sequences "owned by" that column or columns, and rename them so that
> they still look like "table_column_seq".
[EMAIL PROTECTED] backup]$ cat /etc/redhat-release
CentOS release 4.4 (Final)
BINDIR = /usr/local/pgsql/bin
DOCDIR = /usr/local/pgsql/doc
INCLUDEDIR = /usr/local/pgsql/include
PKGINCLUDEDIR = /usr/local/pgsql/include
INCLUDEDIR-SERVER = /usr/local/pgsql/include/server
LIBDIR = /usr/local/pgsql/lib
"Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> (gdb) where
> #0 0x003fe362e21d in raise () from /lib64/tls/libc.so.6
> #1 0x003fe362fa1e in abort () from /lib64/tls/libc.so.6
> #2 0x0063a2e3 in errfinish ()
> #3 0x005974c4 in DeadLockReport ()
> #4 0x0059381f in L
Tom Lane wrote:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> > John Smith wrote:
> >> [3] I am not certain how widespread they might be, but I think there
> >> may be some backward compatibility concerns with the patch you are
> >> proposing.
>
> > Well, the current behavior is certainly b
I've got a patch to psql that offers a "no wider than terminal" option,
patched against cvs head. Would anyone be willing to test this before I
submit the patch?
# \pset format aligned-wrapped
# \pset border 2
# select * from distributors order by did;
Word wrap debug: rows=11 terminal=66 tota
32 matches
Mail list logo
