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 care
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.
postgres=# explain select proname from pg_proc where proname
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
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 used
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 version I can
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+ lines.
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
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
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
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
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
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
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
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
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
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
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
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
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 process
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.
Remaining to
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
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
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 an
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
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
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
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)
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 that.
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
Attached patch
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
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 broken
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:
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)
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 security
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 happened on
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.
I think you
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
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 the usual way is to call the
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
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 what in
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 chance that a
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
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
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 matters in
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
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
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
referenced table.
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 horrid idea.
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
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 fnmatch(),
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 figure out
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 maybe
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
--
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
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)
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
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 too
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() and
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 is to
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(const char
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_FNMATCH
+ extern int
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 from the
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 there: what if
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Since fnmatch and the #define's are supposed to be provided by
fnmatch.h, 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
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 uncommon in these
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Since fnmatch and the #define's are supposed to be provided by
fnmatch.h, 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
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 a
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Not really. I'd suggest making the callers do something like
#ifdef HAVE_FNMATCH
#include fnmatch.h
#else
#include port/pg_fnmatch.h
#endif
How's that actually different from the
#ifdef HAVE_FNMATCH
#include fnmatch.h
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 fnmatch.h
#else
#include port/pg_fnmatch.h
#endif
How's that actually different from the
#ifdef HAVE_FNMATCH
#include
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 value
from
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 warnings about ignoring
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 the
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 user-defined
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 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:
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 amazing.
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
(the
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
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
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
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
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.
This sounds
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, the standby cannot catch
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 back to the
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
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 for
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
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
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 generally,
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, but
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
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 run
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:
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
95 matches
Mail list logo
