On Mon, Oct 20, 2008 at 12:05 PM, Julius Stroffek
<[EMAIL PROTECTED]>wrote:
> Topics that seem to be of interest and most of them were already
> discussed at developers meeting in Ottawa are
> 1.) parallel sorts
> 2.) parallel query execution
> 3.) asynchronous I/O
> 4.) parallel COPY
> 5.) parall
On Tue, Sep 30, 2008 at 1:41 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera wrote:
> > A customer of ours has been having trouble with corrupted data for some
> > time. Of course, we've almost always blamed hardware (and we've seen
> > RAID controllers have their firmware upgraded,
On Fri, Sep 19, 2008 at 11:42 AM, Robert Treat <[EMAIL PROTECTED]
> wrote:
> On Friday 19 September 2008 00:23:34 Jeffrey Baker wrote:
> > Anyway, I have some issues. One, of course, is that the autovacuum
> should
> > not have been deadlocked or otherwise stalled like t
I have an 8.3.1 instance on Linux and since June 29th the autovacuum process
has claimed to be working on the same three tables. That's OK, I am a very
patient man, and these are very large tables. Today I started to get
transaction wraparound warnings, so I go and check it out. Turns out the
au
On Tue, Jun 24, 2008 at 3:08 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> wrote:
> >> Now, *why* it is a mistake is interesting to speculate about, but
> >> let's confirm the theory first.
>
> > Could this be related to hin
On Tue, Jun 24, 2008 at 2:38 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jeffrey Baker" <[EMAIL PROTECTED]> writes:
> > I'm quite aware of the problems of maintaining such a table and index,
> but
> > the fact is that data warehouse type tables may nev
On Tue, Jun 24, 2008 at 1:59 PM, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
> Jeffrey Baker írta:
> > The way I read it, the current btree index stores the index value and
> > the TID of every tuple having that value. When you have a table with
> > three columns, yo
The way I read it, the current btree index stores the index value and the
TID of every tuple having that value. When you have a table with three
columns, you index one of them and you get an index which is practically as
large as the table itself.
Supposing the table is generally or strictly orde
On Tue, Jun 17, 2008 at 6:31 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Jeffrey Baker escribió:
> >> The table was originally created this way:
>
> > Okay, but was it created on 8.1 or was it already created o
On Tue, Jun 17, 2008 at 2:43 PM, Alvaro Herrera <[EMAIL PROTECTED]>
wrote:
> Jeffrey Baker escribió:
> > On Tue, Jun 17, 2008 at 10:59 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >
> > > "Jeffrey Baker" <[EMAIL PROTECTED]> writes:
> > &g
On Tue, Jun 17, 2008 at 10:59 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jeffrey Baker" <[EMAIL PROTECTED]> writes:
> > It is impossible to dump (with pg_dump -Ocx) and restore (with psql) a
> > database which contains sequences in any of 8.1, 8.2, or 8.3:
&
It is impossible to dump (with pg_dump -Ocx) and restore (with psql) a
database which contains sequences in any of 8.1, 8.2, or 8.3:
[...]
--
-- Name: transaction_transaction_id_seq; Type: SEQUENCE SET; Schema:
mercado; Owner: prod
--
SELECT
pg_catalog.setval(pg_catalog.pg_get_serial_sequence('t
On Wed, Jun 4, 2008 at 11:31 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jeffrey Baker" <[EMAIL PROTECTED]> writes:
> > I have a need to find out the meaning of a backend exiting unexpectedly
> with
> > exit code 2. Leafing through the source of 8.1 I can&#
I have a need to find out the meaning of a backend exiting unexpectedly with
exit code 2. Leafing through the source of 8.1 I can't really find it.
Is there anything in postgres which would exit with code 2, or should I be
looking at libraries and junk dragged in by languages?
On Mon, Mar 24, 2008 at 9:24 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jeffrey Baker" <[EMAIL PROTECTED]> writes:
> > On Sun, Mar 23, 2008 at 8:35 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> >> If it works over TCP and not over Unix socket, it&#x
On Sun, Mar 23, 2008 at 8:35 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jeffrey Baker" <[EMAIL PROTECTED]> writes:
> > You'll note that I'm using the DBD::Pg Perl interface. So far I've
> > never seen this happen with TCP connections, only
On Sun, Mar 23, 2008 at 7:12 PM, Jeffrey Baker <[EMAIL PROTECTED]> wrote:
> Lately I've noticed that local (UNIX socket) clients using libpq4
> 8.1.9 (Debian 8.1.9-0etch1) and the same version of the server can
> hang forever waiting in poll(). The symptom is that the l
Lately I've noticed that local (UNIX socket) clients using libpq4
8.1.9 (Debian 8.1.9-0etch1) and the same version of the server can
hang forever waiting in poll(). The symptom is that the local client
waits forever, using no CPU time, until it is interrupted by some
event (such as attaching gdb o
Neil Conway wrote:
Jeffrey Baker wrote:
Would you take a patch that retained the optimized executions of plans
returning 1 tuple and also fixed the random heap problem?
Can you elaborate on what you're proposing? Obviously sorted b+-tree
output is important for a lot more than just min(
Tom Lane wrote:
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
I see that Tom has already done the infrastructure work by adding
getmulti, but getmulti isn't used by nodeIndexscan.c, only
nodeBitmapIndexscan.c. Will btree index scans be executed by creating
in-memory bitmaps in 8.1, or will some s
20 matches
Mail list logo
