This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
ITAGAKI Takahiro wrote:
> I found XLogCtlData.XLogCacheByte is already unused in CVS HEAD.
> Should we remove the var
Patch applied. Thanks.
---
Stefan Kaltenbrunner wrote:
> the attached patch makes teh following changes to the psql tab-complete
> support
>
> * adds a few missing words to some commands (like adding GIN as a valid
> ind
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Andrew Chernow wrote:
> Version 0.4 of libpq param put and PGresult get functions.
>
> Added support for inet and ci
Applied:
PAM does work authenticating against Unix system authentication
because the postgres server is started by a non-root user. In order
to enable this functionality, the root user must provide additional
permissions to the postgres user (for reading
/etc/shadow).
-
On 9/14/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
>
> HeapTupleSatisfiesAbort is bogus because it has failed to track recent
> changes in tqual.c.
Oh. I should have been aware.
Rather than fix it, though, I question why we need it at all. The only
> use of it is in heap_prune_tuplechain() and
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
ITAGAKI Takahiro wrote:
> I wrote:
>
> > I'll rewrite my patch to use
> > FSMPageData in both places so that users c
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
> Michael Paesold <[EMAIL PROTECTED]> writes:
> > Please, let's revisit this, and not postpone it wit
Jim C. Nasby wrote:
-- Start of PGP signed section.
> From
> http://developer.postgresql.org/pgdocs/postgres/routine-vacuuming.html :
>
> "Recommended practice for most sites is to schedule a database-wide
> VACUUM once a day at a low-usage time of day, supplemented by more
> frequent vacuuming of
Okay, something else (a real problem this time ;-)):
HeapTupleSatisfiesAbort is bogus because it has failed to track recent
changes in tqual.c.
Rather than fix it, though, I question why we need it at all. The only
use of it is in heap_prune_tuplechain() and ISTM that code is redundant,
wrong, or
On 9/13/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
>
>
> Never mind ... though my
> suspicions would probably not have been aroused if anyone had bothered
> to fix the comments.
>
>
Yeah, my fault. I should have fixed that. Sorry about that.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB htt
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 9/13/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> You have apparently
>> decided to redefine the WAL record format as using one-based rather than
>> zero-based item offsets, which would be fine if any of the rest of the
>> code had been changed to agr
On 9/13/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
>
>
> Yeah, I just checked the work-in-progress patch I sent you back in July.
> I refactored it to use one-based offsets for consistency, since I
> modified log_heap_clean quite heavily anyway.
>
> It's possible that I broke it in the pro
Pavan Deolasee wrote:
> On 9/13/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> You have apparently
>> decided to redefine the WAL record format as using one-based rather than
>> zero-based item offsets, which would be fine if any of the rest of the
>> code had been changed to agree ...
>>
>>
> I know He
On 9/13/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
>
> I'm curious how much the WAL-recovery aspects of this patch have been
> tested, because heap_xlog_clean seems quite broken.
There are quite a few crash recovery tests that one of our QA persons
(Dharmendra Goyal) has written. I can post them
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Please see the revised patches attached.
I'm curious how much the WAL-recovery aspects of this patch have been
tested, because heap_xlog_clean seems quite broken. You have apparently
decided to redefine the WAL record format as using one-based rather
On 9/12/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
>
>
> One change that is worh mentioning
> and discussing is that we don't follow HOT chains while fetching tuples
> during
> autoanalyze and autoanalyze would consider all such tuples as DEAD.
> In the worst case when all the tuples in the tabl
16 matches
Mail list logo