I think we should avoid the #define's like below which uses a local
variable. I guess the same #define is used elsewhere in the code as well. If
the code is rearranged or the variable name is changed, the code would
break.
The use of malloc should also be avoided (unless the memory subsystem is no
Alex Hunsaker wrote
>
> Uhh sounds like you are describing hot standby (currently in the works
> for 8.4) see:
>
Yep. That's exactly what I'm talking about. Thanks for the links!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Thu, Nov 20, 2008 at 21:45, Philip Warner <[EMAIL PROTECTED]> wrote:
>
> Sounds somewhat evil, I know, but I was wondering if it was even
> remotely possible with the current design?
>
> The reason: we are contemplating using pg_standy to create a
> warm-standby. It would be a bonus if we would
Euler Taveira de Oliveira escreveu:
> [Sorry for the delay. I'm preparing the final patch and in a day or so
> I'll post it.]
>
Here is the patch that replace pg_autovaccum catalog with reloptions. I
refactored the reloptions.c to support multiple parameters and made the
action of adding a new op
On Fri, Aug 1, 2008 at 13:31, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Something that's bothering me is that PGSSLKEY is inconsistent with the
> sslkey conninfo parameter. PGSSLKEY specifies an engine (basically a
> driver for specialized hardware AFAICT) from which the key is to be
> loaded, b
KaiGai Kohei wrote:
> >> Please consider SELinux/SE-PostgreSQL requires various kind of objects
> >> (including database objects) to be labeled properly at the initial state.
> >> If it allows clients to turn on row-level security feature, it means many
> >> "unlabeled" tuples appear suddenly. In g
Sounds somewhat evil, I know, but I was wondering if it was even
remotely possible with the current design?
The reason: we are contemplating using pg_standy to create a
warm-standby. It would be a bonus if we would run read-only queries
against this DB to take some of the load off or production s
This bug has not been fixed, but it is on the TODO list:
o Prevent query cancel packets from being replayed by an attacker,
especially when using SSL
I am going to consider this item closed meaning I am not going to track
that it is fixed for 8.4; it is just documented on our T
KaiGai Kohei <[EMAIL PROTECTED]> writes:
> It is unclear for me when the CommtiFest:Nov is finished, but it is sure
> we don't have enough days.
This commitfest goes until it's done. I knew at the beginning that we'd
not be done at the end of November. The original schedule allowed two
months fo
Please consider SELinux/SE-PostgreSQL requires various kind of objects
(including database objects) to be labeled properly at the initial state.
If it allows clients to turn on row-level security feature, it means many
"unlabeled" tuples appear suddenly. In generally, these have to be labeled
befo
On Fri, Nov 21, 2008 at 12:15 AM, Pavan Deolasee
<[EMAIL PROTECTED]> wrote:
>
>
> On Thu, Nov 20, 2008 at 8:36 PM, Heikki Linnakangas
> <[EMAIL PROTECTED]> wrote:
>>
>> That seems like a dangerous assumption. What if the standby had fallen
>> behind before the failover? It's not safe to failover ba
On Fri, Nov 21, 2008 at 12:06 AM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
> Fujii Masao wrote:
>>
>> Hi, Heikki. Thanks for the comment!
>>
>> On Thu, Nov 20, 2008 at 11:24 PM, Heikki Linnakangas
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> Fujii Masao wrote:
In the current Synch Rep patch
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> >>> However, the toggle of row-level security feature should be controled
> >>> via a GUC option, not a discretionary option.
> >>> I'll add a "sepostgresql_row_level" option defined as bool to control
> >>> it on start up time.
Bruce Momjian wrote:
Bruce Momjian wrote:
However, the toggle of row-level security feature should be controled
via a GUC option, not a discretionary option.
I'll add a "sepostgresql_row_level" option defined as bool to control
it on start up time.
This sounds similar to BSD capability were cer
Michael Meskes wrote:
On Wed, Nov 12, 2008 at 02:28:56PM -0800, Ron Mayer wrote:
Merging of the interval style into ecpg attached.
Thanks for caring about the ecpg changes too.
Thanks for the comments. Updated the patch.
I know little enough about ecpg that I can't really tell if these cha
"Lawrence, Ramon" <[EMAIL PROTECTED]> writes:
> We propose a patch that improves hybrid hash join's performance for
> large multi-batch joins where the probe relation has skew.
> ...
> The basic idea
> is to keep build relation tuples in a small in-memory hash table that
> have join values that are
D'Arcy J.M. Cain wrote:
> So what have we decided about this suggestion. Should I submit the
> patch or just forget about it? So far some people like it and some
> people think that it is unneccessary. No one so far has suggested that
> it would harm the system or people's use of it.
Has there
Bruce Momjian wrote:
> Thanks for the review, Magnus. I have adjusted the patch to use the
> same mutex every time the counter is accessed, and adjusted the
> pqsecure_destroy() call to properly decrement in the right place.
>
> Also, I renamed the libpq global destroy function to be clearer
> (t
David Fetter escribió:
> On Wed, Nov 19, 2008 at 10:21:06PM -, David Rowley wrote:
> > Gregory Stark wrote:
> > > So based on Graeme Job's T-SQL hack over at thedailywtf.com I adapted the
> > > T-SQL code to Postgres and got this. Thought others might find it amusing.
> > >
> > That's pretty a
On Thu, Nov 20, 2008 at 02:26:14PM -0500, Andrew Dunstan wrote:
>
>
> Kenneth Marshall wrote:
>> Okay, I have had a chance to run some timing benchmarks.
>> Here are my results for the parallel pg_restore patch:
>>
>> Ken
>> --
>> Server settings:
>>
On Wed, Nov 19, 2008 at 10:21:06PM -, David Rowley wrote:
> Gregory Stark wrote:
> > So based on Graeme Job's T-SQL hack over at thedailywtf.com I adapted the
> > T-SQL code to Postgres and got this. Thought others might find it amusing.
> >
> That's pretty amazing.
>
> I think we should add
On Thu, Nov 20, 2008 at 4:11 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Robert Haas" <[EMAIL PROTECTED]> writes:
>> It looks to me like section 34.10 of the docs might benefit from some
>> sort of update in light of this patch, since the builtin array_agg now
>> does the same thing as the proposed
Magnus Hagander <[EMAIL PROTECTED]> writes:
> AFAICS, we're not doing this for any other functions though - or am I
> too tired and just looking in the wrong place? Or is that because
> they're just function definitions and not #defines?
> (I want to be sure to stick whatever new file there is in t
Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
We're definitely *not* fortify-clean, although maybe trying to become so
would be a good idea. From memory, what I have seen in past builds on
Red Hat systems is a lot of warn
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> We're definitely *not* fortify-clean, although maybe trying to become so
>>> would be a good idea. From memory, what I have seen in past builds on
>>> Red Hat systems is a lot of warnings about ignoring the return
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Not really. I'd suggest making the callers do something like
>>>
>>> #ifdef HAVE_FNMATCH
>>> #include
>>> #else
>>> #include "port/pg_fnmatch.h"
>>> #endif
>
>> How's that actually different from the
>> #ifdef H
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Not really. I'd suggest making the callers do something like
>>
>> #ifdef HAVE_FNMATCH
>> #include
>> #else
>> #include "port/pg_fnmatch.h"
>> #endif
> How's that actually different from the
> #ifdef HAVE_FNMATCH
> #include
"Robert Haas" <[EMAIL PROTECTED]> writes:
> It looks to me like section 34.10 of the docs might benefit from some
> sort of update in light of this patch, since the builtin array_agg now
> does the same thing as the proposed user-defined array_accum, only
> better. Presumably we should either pick
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Since fnmatch and the #define's are supposed to be provided by
>>> , I think you should probably put the substitute definitions
>>> in a substitute fnmatch.h, not port.h, to avoid that risk.
>
>> Do we have an exa
Bruce Momjian wrote:
> Magnus Hagander wrote:
> > >> Not sure I care enough to dive into what it would actually mean. My
> > >> guess is that it's very uncommon to use db_user_namespace in any of
> > >> these scenarios (in fact I think it's very uncommon to use it at all,
> > >> but even more uncom
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Since fnmatch and the #define's are supposed to be provided by
>> , I think you should probably put the substitute definitions
>> in a substitute fnmatch.h, not port.h, to avoid that risk.
> Do we have an example where we do that bef
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> Also, judging from the comments in the autoconf manual, you'd better
>>> use AC_FUNC_FNMATCH not just test whether the function exists.
>
>> Ok, will look at switching to that.
>
> Hmm ... actually there's still possibly an issue t
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Surely we must *not* be providing our own definitions of these symbols
>> when using a system version of fnmatch.
> That's the define that I reversed in the second patch I sent. It's
> supposed to be ifndef.
Okay.
>> Also, judging
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> *** a/src/include/port.h
>> --- b/src/include/port.h
>> ***
>> *** 393,398 extern void unsetenv(const char *name);
>> --- 393,409
>> extern void srandom(unsigned int seed);
>> #endif
>
>> + #ifdef HAVE_FNM
Magnus Hagander <[EMAIL PROTECTED]> writes:
> *** a/src/include/port.h
> --- b/src/include/port.h
> ***
> *** 393,398 extern void unsetenv(const char *name);
> --- 393,409
> extern void srandom(unsigned int seed);
> #endif
> + #ifdef HAVE_FNMATCH
> + extern int fnmatch(
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane napsal(a):
>> No, it's a really horrid idea. Nullable attributes complicate the C
>> code, and what in the world are we buying with it anyway? Just decide
>> what the field should contain and put it in there.
> The problem what we try to solve
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We're definitely *not* fortify-clean, although maybe trying to become so
>> would be a good idea. From memory, what I have seen in past builds on
>> Red Hat systems is a lot of warnings about ignoring the return value
>> from fwrite(
I wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> Attached is a patch that changes create_bitmap_subplan so that the
>> condition put into Recheck condition is never stronger than the
>> condition automatically handled by the index. Does that look right to you?
> I think this is still
On 2008-11-20, at 11:08, Grzegorz Jaskiewicz wrote:
this doesn't apply cleanly to head anymore, can you please post v21 ?
I would love to test it here :)
bollocks, it's already in cvs head - isn't it ? ... :D
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
Kenneth Marshall wrote:
Okay, I have had a chance to run some timing benchmarks.
Here are my results for the parallel pg_restore patch:
Ken
--
Server settings:
max_connections = 100 # (change requires restart)
shared_buff
Okay, I have had a chance to run some timing benchmarks.
Here are my results for the parallel pg_restore patch:
Ken
--
Server settings:
max_connections = 100 # (change requires restart)
shared_buffers = 256MB
> Allowing foreign keys to point to expression indexes seems to open a can
> of worms and I am not sure there is enough demand to warrant it.
It does open a can of worms. I've often wanting something related,
which is the ability to make a foreign key references a PARTIAL index.
...Robert
--
S
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> It looks like you are building in fortify mode? I tried that a while
>> ago and got a few more warnings. Are we trying to be fortify clean, and
>> if so, what is our approach?
>
> We're definitely *not* fortify-clean, although m
Magnus Hagander wrote:
> Peter Eisentraut wrote:
>> Magnus Hagander wrote:
>>> How do I make this work with the autoconf magic? I see there is an
>>> AC_CHECK_FNMATCH and AC_REPLACE_FNMATCH and so, but I have a feeling I
>>> need to do something different since it's libpq?
>> AC_*_FNMATCH will figu
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> How do I make this work with the autoconf magic? I see there is an
>> AC_CHECK_FNMATCH and AC_REPLACE_FNMATCH and so, but I have a feeling I
>> need to do something different since it's libpq?
>
> AC_*_FNMATCH will figure out whether you need fnm
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Heikki Linnakangas napsal(a):
Perhaps we should just add the new attid attribute to the toast table,
but mark it as nullable?
Hmm, It seems to me as a good idea.
No, it's a really hor
Zdenek Kotala wrote:
> Tom Lane napsal(a):
> > Zdenek Kotala <[EMAIL PROTECTED]> writes:
> >> Heikki Linnakangas napsal(a):
> >>> Perhaps we should just add the new attid attribute to the toast table,
> >>> but mark it as nullable?
> >
> >> Hmm, It seems to me as a good idea.
> >
> > No, it's a
David E. Wheeler wrote:
> On Nov 19, 2008, at 9:12 AM, Josh Berkus wrote:
>
> > Folks,
> >
> > Since it's too late to look at this for 8.4, can the following go on
> > the TODO list?
> >
> > Referential Integrity
> >
> > [] Allow creation of FKs targeting unique expression indexes on the
> > r
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Heikki Linnakangas napsal(a):
Perhaps we should just add the new attid attribute to the toast table,
but mark it as nullable?
Hmm, It seems to me as a good idea.
No, it's a really horrid idea. Nullable attributes complicate the
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> It looks like you are building in fortify mode? I tried that a while
> ago and got a few more warnings. Are we trying to be fortify clean, and
> if so, what is our approach?
We're definitely *not* fortify-clean, although maybe trying to become so
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm, the ~~ condition should get treated as a "filter" not a "recheck".
>> I suppose I broke this somewhere ...
> I started to look at this last night. The culprit seems to be this patch:
Yeah, it appears that I oversimplified ma
Magnus Hagander wrote:
Andrew Dunstan wrote:
Attached is my latest parallel restore patch. I think it's functionally
complete for Unix.
Many bugs have been fixed since the last patch, and the hardcoded
limitation to two table dependencies is removed. It seems fairly robust
in my recent tes
On Thu, Nov 20, 2008 at 9:03 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> I don't think you can do that. Couldn't someone else have run
> heap_page_prune between vacuum's first and second visit to the page?
>
>
>
You mean the second visit in the first pass where we again check for
HeapTupleSatisf
On Thu, 2008-11-20 at 10:33 -0500, Tom Lane wrote:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> > I wonder if we should refactor lazy_scan_heap() so that *all* the real work
> > of collecting information about dead tuples happens only in
> > heap_page_prune(). Frankly, there is only a rare cha
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas napsal(a):
>> Perhaps we should just add the new attid attribute to the toast table,
>> but mark it as nullable?
> Hmm, It seems to me as a good idea.
No, it's a really horrid idea. Nullable attributes complicate the C
code, and wha
On 2008-11-20, at 15:29, Peter Eisentraut wrote:
Well, the warning is explicitly put in there for this specific
function because you are supposed to process the return value. I'm
sure a more smarter compiler would even warn "variable is assigned a
value that is never used". ;-) (Note th
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> Heikki Linnakangas wrote:
>>> Magnus Hagander wrote:
Log Message:
---
Silence compiler warning about ignored return value. Our comment
already
clearly stated that we are aware that we're ignoring it.
>>> I think th
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Attached patch seems right to me - objections?
>
> Good catch. What gave you these warnings exactly?
Same here - the new version of gcc.
Will go ahead and apply.
//Magnus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Heikki Linnakangas wrote:
>>> I think the usual way is to call the function like:
>>> (void) function_with_return_value()
>
>> I tried that first, of course. gcc is too smart about that - it still
>> throws the warning in this case.
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> I wonder if we should refactor lazy_scan_heap() so that *all* the real work
> of collecting information about dead tuples happens only in
> heap_page_prune(). Frankly, there is only a rare chance that a tuple may
> become DEAD after the pruning happene
Bruce Momjian wrote:
> > However, the toggle of row-level security feature should be controled
> > via a GUC option, not a discretionary option.
> > I'll add a "sepostgresql_row_level" option defined as bool to control
> > it on start up time.
>
> This sounds similar to BSD capability were certain
Magnus Hagander wrote:
Heikki Linnakangas wrote:
Magnus Hagander wrote:
Log Message:
---
Silence compiler warning about ignored return value. Our comment already
clearly stated that we are aware that we're ignoring it.
I think the usual way is to call the function like:
(void) functi
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Attached patch seems right to me - objections?
Good catch. What gave you these warnings exactly?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas wrote:
>> I think the usual way is to call the function like:
>> (void) function_with_return_value()
> I tried that first, of course. gcc is too smart about that - it still
> throws the warning in this case.
I think you must have a
Magnus Hagander wrote:
How do I make this work with the autoconf magic? I see there is an
AC_CHECK_FNMATCH and AC_REPLACE_FNMATCH and so, but I have a feeling I
need to do something different since it's libpq?
AC_*_FNMATCH will figure out whether you need fnmatch(), so something
involving thos
Magnus Hagander <[EMAIL PROTECTED]> writes:
> I get the following warnings in HEAD
>
> pl_exec.c: In function ‘exec_stmt_raise’:
> pl_exec.c:2538: warning: format not a string literal and no format arguments
> pl_exec.c:2538: warning: format not a string literal and no format arguments
>
>
> Attac
On Thu, Nov 20, 2008 at 8:36 PM, Heikki Linnakangas <
[EMAIL PROTECTED]> wrote:
>
> That seems like a dangerous assumption. What if the standby had fallen
> behind before the failover? It's not safe to failover back to the original
> primary in that case. We'd need some kind of safeguards against
Heikki Linnakangas wrote:
> Magnus Hagander wrote:
>> Log Message:
>> ---
>> Silence compiler warning about ignored return value. Our comment already
>> clearly stated that we are aware that we're ignoring it.
>
> I think the usual way is to call the function like:
>
> (void) function_wi
Magnus Hagander wrote:
Log Message:
---
Silence compiler warning about ignored return value. Our comment already
clearly stated that we are aware that we're ignoring it.
I think the usual way is to call the function like:
(void) function_with_return_value()
--
Heikki Linnakangas
Fujii Masao wrote:
Hi, Heikki. Thanks for the comment!
On Thu, Nov 20, 2008 at 11:24 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
Fujii Masao wrote:
In the current Synch Rep patch, the standby cannot catch up with the
primary which has a bigger timeline.
That would only happen if you've
I get the following warnings in HEAD
pl_exec.c: In function ‘exec_stmt_raise’:
pl_exec.c:2538: warning: format not a string literal and no format arguments
pl_exec.c:2538: warning: format not a string literal and no format arguments
Attached patch seems right to me - objections?
//Magnus
Index:
Hi, Heikki. Thanks for the comment!
On Thu, Nov 20, 2008 at 11:24 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
> Fujii Masao wrote:
>>
>> In the current Synch Rep patch, the standby cannot catch up with the
>> primary which has a bigger timeline.
>
> That would only happen if you've performed
On Thu, Nov 20, 2008 at 7:50 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> (I assume you mean bgwriter, not archiver process).
>
>
Yeah, its the bgwriter, IIRC hung while taking checkpoint.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
Fujii Masao wrote:
In the current Synch Rep patch, the standby cannot catch up with the
primary which has a bigger timeline.
That would only happen if you've performed an archive recovery in the
primary. If you've done PITR in the primary, I don't think there's any
guarantee that it's even po
Andrew Dunstan wrote:
>
> Attached is my latest parallel restore patch. I think it's functionally
> complete for Unix.
>
> Many bugs have been fixed since the last patch, and the hardcoded
> limitation to two table dependencies is removed. It seems fairly robust
> in my recent testing.
>
> Remai
On Thu, 2008-11-20 at 12:03 +0530, Pavan Deolasee wrote:
> On Sat, Nov 1, 2008 at 10:02 PM, Simon Riggs <[EMAIL PROTECTED]>
> wrote:
> Hot Standby patch, including all major planned features.
>
>
> While experimenting with the patch, I noticed that sometimes the
> archiver proce
Hi,
In the current Synch Rep patch, the standby cannot catch up with the
primary which has a bigger timeline. So, whenever making the standby
catch up, a fresh base backup is required. This is obviously undesirable,
and I'd like to get rid of this restriction.
Postgres itself can recover up to a
I committed the changes to FSM truncation yesterday, that helps with the
truncation of the visibility map as well. Attached is an updated
visibility map patch.
There's two open issues:
1. The bits in the visibility map are set in the 1st phase of lazy
vacuum. That works, but it means that aft
Hi!
I want to use the fnmatch() function in libpq, to support wildcard
certificate matching. This function is part of the standard
(http://www.opengroup.org/onlinepubs/95399/functions/fnmatch.html),
but obviously not implemented on all platforms (naturally, it's missing
on win32, because that
1st) it turns out PostgreSQL allows code that is more compact than
MSQL: 19 lines instead of 46 lines
2nd) now there will be a really compelling reason for DBAs worldwide
to upgrade to 8.4; after release everyone without Mandelbrot in SQL is
just a lame noob
3rd) maybe THAT could be the final s
Heikki Linnakangas napsal(a):
It the new attribute is added to the end, the old tuples will be
compatible as is. If there's no null bitmap (or it's shorter than
expectd), attributes missing from a tuple are implicitly NULL. That's
how we support ALTER TABLE ADD COLUMN without rewriting all the
this doesn't apply cleanly to head anymore, can you please post v21 ?
I would love to test it here :)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Nov 20, 2008 at 3:38 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> I would suggest that we just remove the switch statement:
>switch (HeapTupleSatisfiesVacuum(tuple.t_data, OldestXmin, buf))
> and alter the following if test since tupgone is also removed.
> That will cause HEAPTUP
Emmanuel Cecchet wrote:
I still quite did not get what the big deal was if an ON COMMIT DELETE
ROWS temp table was created inside a transaction.
In case the transaction that created a temp table rolls back, the table
needs to be removed. Removing a temporary table belonging to another
backend
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Perhaps we should just add the new attid attribute to the toast table,
but mark it as nullable? We wouldn't need to fill it in in the
8.3->8.4 conversion but new tuples would include it.
>
In the future release that we actually need it, we'll
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
The question is if we should do toast modification now to avoid
potential future problems or if we will solve it when any on-disk
format change requires it?
Perhaps we should just add the new attid attribute to the toast table,
but mark it a
On Thu, 2008-11-20 at 15:19 +0530, Pavan Deolasee wrote:
> Do you intend to split the patch into smaller pieces ? The latest hot
> standby patch is almost 10K+ lines. Splitting that would definitely
> help the review process.
If it helps you, then I'll do it. Hang on an hour or so.
--
Simon R
On Thu, 2008-11-20 at 11:51 +0530, Pavan Deolasee wrote:
> I wonder if we should refactor lazy_scan_heap() so that *all* the real
> work of collecting information about dead tuples happens only in
> heap_page_prune(). Frankly, there is only a rare chance that a tuple
> may become DEAD after the p
On Thu, Nov 20, 2008 at 3:12 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
>
> The latest Hot Standby patch includes the latest version of
> "infrastructure changes" patch. Thanks for reviewing.
>
>
Do you intend to split the patch into smaller pieces ? The latest hot
standby patch is almost 10K+ l
On Thu, 2008-11-20 at 11:06 +0530, Pavan Deolasee wrote:
>
>
> On Mon, Nov 17, 2008 at 9:01 PM, Simon Riggs <[EMAIL PROTECTED]>
> wrote:
>
>
> It is, in a later version. Apologies if you're reviewing the
> wrong one.
>
>
>
> The most recent ve
Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> This code would only be executed if you have a man.tar.gz in the doc
> directory. If you do, it is probably an old one that indeed does not
> contain the man7 directory. So delete the man.tar.gz (and build a new
> one if you are so inclined).
I
Zdenek Kotala wrote:
The question is if we should do toast modification now to avoid
potential future problems or if we will solve it when any on-disk format
change requires it?
Perhaps we should just add the new attid attribute to the toast table,
but mark it as nullable? We wouldn't need to
Tom Lane wrote:
"Rushabh Lathia" <[EMAIL PROTECTED]> writes:
Simple select give wrong result when it uses the Bitmap Heap Scan path.
It's generally appropriate to mention which PG version you're working
with when you report a bug.
postgres=# explain select proname from pg_proc where proname
ITAGAKI Takahiro wrote:
HEAD is failed to be built on win32 mingw.
It requires manual 'mkdir man7' or so.
Are there any changes in build process?
Or am I missing something required to build?
$ make
/bin/sh.exe: man7/.timestamp: No such file or directory
$ mkdir doc/man7<- HERE
Tom Lane wrote:
"Rushabh Lathia" <[EMAIL PROTECTED]> writes:
Simple select give wrong result when it uses the Bitmap Heap Scan path.
It's generally appropriate to mention which PG version you're working
with when you report a bug.
I was on 8.4 CVS Head, Next time will sure take car
95 matches
Mail list logo
