Re: [HACKERS] Why do we keep UnusedLock1 in LWLockId?
ITAGAKI Takahiro wrote: There is UnusedLock1 in LWLockId enumerations in storage/lwlock.h . | UnusedLock1,/* FreeSpaceMapLock used to be here */ I thought it is for keeping LWLockId same as 8.3 at first, but we've already split SInvalLock to SInvalReadLock and SInvalWriteLock. So the IDs are changed anyway. The idea was indeed to keep the lock numbering unchanged. Zdenek suggested that to make dtrace scripts etc. compatible across versions. You're right, we split SInvalLock in 8.4, so reserving the slot for FreeSpaceLock doesn't keep the numbers unchanged. In fact, removing that will make the rest of the lock numbers the same as in 8.3 again. I'll remove that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] statistics horribly broken for row-wise comparison
On Tue, Mar 3, 2009 at 3:33 AM, Tom Lane t...@sss.pgh.pa.us wrote: Because it would be the wrong answer, except in the uncommon case where the field values are completely independent (at least, I would expect that to be uncommon when people have multicolumn indexes on them). Actually I think it's *more* likely to be true for multicolumn indexes. If the two columns were correlated then you wouldn't need the multicolumn index since you could just use one of the columns alone. The case where people create multicolumn indexes btree indexes is usually when they have a major-minor relationship between the two columns so for each value of the major key there is a whole range of minor keys. Sure multi-column statistics would be nice though. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot standby, running xacts, subtransactions
On Mon, 2009-03-02 at 21:11 -0500, Robert Treat wrote: On Wednesday 25 February 2009 16:43:54 Simon Riggs wrote: On Wed, 2009-02-25 at 13:33 -0800, Josh Berkus wrote: You raised that as an annoyance previously because it means that connection in hot standby mode may be delayed in cases of heavy, repeated use of significant numbers of subtransactions. While most users still don't use explicit subtransactions at all, wouldn't this also affect users who use large numbers of stored procedures? If they regularly use more than 64 levels of nested EXCEPTION clauses *and* they start their base backups during heavy usage of those stored procedures, then yes. We have stored procedrues that loop over thousands of records, with begin...exception blocks in that loop, so I think we do that. AFAICT there's no way to tell if you have it wrong until you fire up the standby (ie. you can't tell at the time you make your base backup), right ? That was supposed to be a simplification for phase one, not a barrier for all time. I'm changing that now, though the effect will be that in some cases we take longer before we accept connections. The initialisation requirements are that we have full knowledge of transactions in progress before we allow snapshots to be taken. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Maintenance announcement for alderaan/barzan/minshara.postgresql.org
there will be planned maintenance tomorrow(4 March 2009) from 09:00 to 10:00 CET for the following servers and corresponding services: barzan.postgresql.org - affecting: * xindi.postgresql.org (wiki.postgresql.org) * rakhar.postgresql.org (planet.postgresql.org) * pentarus.postgresql.org (web development sandbox) alderaan.postgreql.org - affecting: * qonos.postgresql.org (git.postgresql.org) * yridian.postgresql.org (PostgreSQL EU) * endicor.postgresql.org minshara.postgresql.org - affecting: * fornax.postgresql.org (ftp.postgresql.org) * gothos.postgresql.org * wysanti.postgresql.org (static www mirror) Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_restore -m failing
hi all, After Andrew corrected the bug I found on pg_restore (-C -m misbehaving one with the other), I played again yesterday. before the end of restore, I get this : pg_restore: launching item 4202 INDEX idx_typeper_actif pg_restore: [custom archiver] could not close archive file: Argument incorrect pg_restore: *** aborted because of error pg_restore: finished item 4202 INDEX idx_typeper_actif pg_restore: [archiver] worker process failed: exit code 1 pg_restore: *** aborted because of error Any idea? this is on unixware -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: o...@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_restore -m failing
o...@pyrenet.fr wrote: hi all, After Andrew corrected the bug I found on pg_restore (-C -m misbehaving one with the other), I played again yesterday. before the end of restore, I get this : pg_restore: launching item 4202 INDEX idx_typeper_actif pg_restore: [custom archiver] could not close archive file: Argument incorrect pg_restore: *** aborted because of error pg_restore: finished item 4202 INDEX idx_typeper_actif pg_restore: [archiver] worker process failed: exit code 1 pg_restore: *** aborted because of error Any idea? this is on unixware That seems very strange. Is it repeatable. I wonder what theincorrect argument was? Maybe the memory got clobbered somewhere. Actually, while thinking about this it occurred to me that we are probably wasting a few cycles reopening the archive where we don't need to - it should only be necessary where we are restoring a data member, ISTM. I'll look at that further. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Immediate shutdown and system(3)
Dne 2.03.09 08:59, Heikki Linnakangas napsal(a): Fujii Masao wrote: On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: I'm leaning towards option 3, but I wonder if anyone sees a better solution. 4. Use the shared memory to tell the startup process about the shutdown state. When a shutdown signal arrives, postmaster sets the corresponding shutdown state to the shared memory before signaling to the child processes. The startup process check the shutdown state whenever executing system(), and determine how to exit according to that state. This solution doesn't change any existing behavior of pg_standby. What is your opinion? That would only solve the problem for pg_standby. Other programs you might use as a restore_command or archive_command like cp or rsync would still core dump on the SIGQUIT. I think that we could have two methods. Extended method will use share memory to say what child should do and standard which send appropriate signal to child. For example pg_ctl could use extended communication to better postmaster controlling. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Who's reviewing SEPostgres?
All, Who's looking at SEPostgres other than Jaime and Tom? Do we have any other reviewers? We could get this closed out faster with a couple more. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Immediate shutdown and system(3)
Zdenek Kotala wrote: Dne 2.03.09 08:59, Heikki Linnakangas napsal(a): Fujii Masao wrote: On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: I'm leaning towards option 3, but I wonder if anyone sees a better solution. 4. Use the shared memory to tell the startup process about the shutdown state. When a shutdown signal arrives, postmaster sets the corresponding shutdown state to the shared memory before signaling to the child processes. The startup process check the shutdown state whenever executing system(), and determine how to exit according to that state. This solution doesn't change any existing behavior of pg_standby. What is your opinion? That would only solve the problem for pg_standby. Other programs you might use as a restore_command or archive_command like cp or rsync would still core dump on the SIGQUIT. I think that we could have two methods. Extended method will use share memory to say what child should do and standard which send appropriate signal to child. For example pg_ctl could use extended communication to better postmaster controlling. The problem isn't in the signaling between external tools like pg_ctl and postmaster, but the signaling between postmaster and the child processes. Signal multiplexing would help by releasing some signals, but to kill a child process that can be executing an external command with system(3), we'd still want to use a signal that does the right thing for external commands, per usual Unix semantics. Also, the archiver process currently detaches itself from shared memory at start, so using shared memory doesn't seem like an improvement. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] building pg_dump doesn't work
Hi, I noticed that if you start from a clean tree, it doesn't work to build pg_dump because gram.h has not been generated yet: make -C ../../../src/backend/parser keywords.o make[1]: Entering directory `/home/alvherre/Code/CVS/pgsql/build/00head/src/backend/parser' gcc -O0 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -I/pgsql/source/00head/src/backend/parser -I../../../src/include -I/pgsql/source/00head/src/include -D_GNU_SOURCE -I/usr/include/libxml2 -c -o keywords.o /pgsql/source/00head/src/backend/parser/keywords.c -MMD -MP -MF .deps/keywords.Po /pgsql/source/00head/src/backend/parser/keywords.c:33:25: error: parser/gram.h: No such file or directory /pgsql/source/00head/src/backend/parser/keywords.c:46: error: 'ABORT_P' undeclared here (not in a function) I notice that there's a line in backend/parser that makes keywords.o depend on gram.h, but apparently it doesn't work: # Force these dependencies to be known even without dependency info built: gram.o keywords.o parser.o: $(srcdir)/gram.h The pg_dump Makefile appears to be expecting the file to be in src/include/parser. This works for src/backend/parser because it adds the current srcdir as -I to CPPFLAGS. (Actually I see, and vaguely remember, that this has been broken for a long time.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] building pg_dump doesn't work
Alvaro Herrera wrote: Hi, I noticed that if you start from a clean tree, it doesn't work to build pg_dump because gram.h has not been generated yet: make -C ../../../src/backend/parser keywords.o make[1]: Entering directory `/home/alvherre/Code/CVS/pgsql/build/00head/src/backend/parser' gcc -O0 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -I/pgsql/source/00head/src/backend/parser -I../../../src/include -I/pgsql/source/00head/src/include -D_GNU_SOURCE -I/usr/include/libxml2 -c -o keywords.o /pgsql/source/00head/src/backend/parser/keywords.c -MMD -MP -MF .deps/keywords.Po /pgsql/source/00head/src/backend/parser/keywords.c:33:25: error: parser/gram.h: No such file or directory /pgsql/source/00head/src/backend/parser/keywords.c:46: error: 'ABORT_P' undeclared here (not in a function) This patch fixes it. The fmgroids.h bits are not needed for pg_dump, but they are if you start building on the parser directory. I don't care strongly for that one, so if people don't like it I'll just go ahead with the gram.h bit, unless anyone has a better idea. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support Index: src/backend/parser/Makefile === RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/parser/Makefile,v retrieving revision 1.48 diff -c -p -r1.48 Makefile *** src/backend/parser/Makefile 4 Oct 2008 21:56:54 - 1.48 --- src/backend/parser/Makefile 3 Mar 2009 21:18:17 - *** subdir = src/backend/parser *** 10,17 top_builddir = ../../.. include $(top_builddir)/src/Makefile.global - override CPPFLAGS := -I$(srcdir) $(CPPFLAGS) - OBJS= analyze.o gram.o keywords.o parser.o parse_agg.o parse_cte.o parse_clause.o \ parse_expr.o parse_func.o parse_node.o parse_oper.o parse_relation.o \ parse_type.o parse_coerce.o parse_target.o parse_utilcmd.o scansup.o --- 10,15 *** endif *** 52,57 --- 50,63 # Force these dependencies to be known even without dependency info built: gram.o keywords.o parser.o: $(srcdir)/gram.h + keywords.o: $(top_builddir)/src/include/parser/gram.h + parse_func.o: $(top_builddir)/src/include/utils/fmgroids.h + parse_coerce.o: $(top_builddir)/src/include/utils/fmgroids.h + + $(top_builddir)/src/include/parser/gram.h: + $(MAKE) -C $(top_builddir)/src/backend ../../src/include/parser/gram.h + $(top_builddir)/src/include/utils/fmgroids.h: + $(MAKE) -C $(top_builddir)/src/backend ../../src/include/utils/fmgroids.h # gram.c, gram.h, and scan.c are in the distribution tarball, so they -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] building pg_dump doesn't work
Alvaro Herrera alvhe...@commandprompt.com writes:
Alvaro Herrera wrote:
I noticed that if you start from a clean tree, it doesn't work to build
pg_dump because gram.h has not been generated yet:
This patch fixes it.
I think this is probably going in the wrong direction. The reason
gram.h isn't already in the main include tree is that we don't *want*
all and sundry depending on it --- we have very carefully minimized
the number of files that depend on the grammar's symbol codes.
ISTM that pg_dump doesn't actually care about the symbol codes, it
just needs a list of known keywords. Can we refactor things so that
the frontend-side version of the keyword list doesn't include the
grammar symbols at all?
One idea that comes to mind is to replace the entries like
{abort, ABORT_P, UNRESERVED_KEYWORD},
with macro calls
PG_KEYWORD(abort, ABORT_P, UNRESERVED_KEYWORD),
and then the frontend build of the file could define the macro
to ignore its second argument.
The way we do it now seems to have other disadvantages too: we are
incorporating a backend .o file into pg_dump as-is, which would lead
to large problems if there were differences in say the compiler flags
needed. In fact, I thought Zdenek had been working on decoupling
that sort of thing, so I'm a bit surprised it's still like this at all.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] We will do releases soon because of bug #4680; please help test
After some discussion the pgsql-security team has decided that we must treat this bug as a security issue: http://archives.postgresql.org/pgsql-bugs/2009-02/msg00172.php because an unprivileged user can crash his backend and thereby create a denial-of-service situation. There's no point in secrecy though, since the bug is already public. Rather, this just means that we will make a set of back-branch releases shortly, whereas we probably wouldn't have done new ones for awhile otherwise. The proposed fixes for the bug are already in CVS, but what we need now is for people to study and test the fixes. This is (at least) the third time we've gone back to re-address the area of crashes caused by failures in error message translation/conversion :-(. So even though I believe we got it right this time, it could definitely do with more eyeballs. Please take a look and see if you can break it. Also, if you've got pending fixes or bug reports for back branches, now's a good time to get them sent in. We have not set a release date yet but it'll likely happen in a week or so. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] building pg_dump doesn't work
Tom Lane wrote: I think this is probably going in the wrong direction. The reason gram.h isn't already in the main include tree is that we don't *want* all and sundry depending on it --- we have very carefully minimized the number of files that depend on the grammar's symbol codes. ISTM that pg_dump doesn't actually care about the symbol codes, it just needs a list of known keywords. Hmm, I had thought that pg_dump only wanted the header file, not the keywords.o object file. I now see that I was wrong. I agree that your proposed solution is a lot better. I'll see about it. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Immediate shutdown and system(3)
Hi, On Mon, Mar 2, 2009 at 4:59 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Fujii Masao wrote: On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: I'm leaning towards option 3, but I wonder if anyone sees a better solution. 4. Use the shared memory to tell the startup process about the shutdown state. When a shutdown signal arrives, postmaster sets the corresponding shutdown state to the shared memory before signaling to the child processes. The startup process check the shutdown state whenever executing system(), and determine how to exit according to that state. This solution doesn't change any existing behavior of pg_standby. What is your opinion? That would only solve the problem for pg_standby. Other programs you might use as a restore_command or archive_command like cp or rsync would still core dump on the SIGQUIT. Right. I've just understood your intention. I also agree with option 3 if nobody complains about lack of backward compatibility of pg_standby. If no, how about using SIGUSR2 instead of SIGINT for immediate shutdown of only the archiver and the startup process. SIGUSR2 by default terminates the process. The archiver already uses SIGUSR2 for pgarch_waken_stop, so we need to reassign that function to another signal (SIGINT is suitable, I think). This solution doesn't need signal multiplexing. Thought? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Make SIGHUP less painful if pg_hba.conf is not readable
This is my first patch. I hope it's not stupid.
We ran into a little issue today where permission/ownership on
pg_hba.conf was accidentally changed to something that the postgres user
could not read. When a SIGHUP was issued, the postmaster quit. That was
kind of a bummer.
From the comment in hba.c, it appears that the desired behavior is to
have the system ignore the failure, and continue using what's already
loaded into memory. And, turns out, that's what I would like Postgres
to do as well.
So, this patch changes the error issued from load_hba() from FATAL to
WARNING if the file is not found, and returns.
Startup behavior (FATAL if pg_hba.conf can't be found) is not changed.
Tested against 8.4devel HEAD today.
Patch attached.
--
Selena Deckelmann
End Point Corporation
sel...@endpoint.com
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index a134b45..931ca86 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1307,11 +1307,14 @@ load_hba(void)
file = AllocateFile(HbaFileName, r);
/* Failure is fatal since with no HBA entries we can do nothing... */
- if (file == NULL)
- ereport(FATAL,
+ if (file == NULL)
+ {
+ ereport(WARNING,
(errcode_for_file_access(),
errmsg(could not open configuration file
\%s\: %m,
HbaFileName)));
+ return false;
+ }
tokenize_file(HbaFileName, file, hba_lines, hba_line_nums);
FreeFile(file);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Regclass and quoted table names
Hi all, It looks like the behavior of regclass is not consistent when table names are quoted. The name is returned without the quotes if the name is lower case with eventual trailing numbers, otherwise it is returned with quotes. See some examples here: tpch=# CREATE VIEW test AS SELECT * FROM customer; CREATE VIEW tpch=# CREATE VIEW test1 AS SELECT * FROM customer; CREATE VIEW tpch=# CREATE VIEW 'test2' AS SELECT * FROM customer; CREATE VIEW tpch=# CREATE VIEW testcolumnVIEW AS SELECT * FROM customer; CREATE VIEW tpch=# CREATE VIEW testcolumnview AS SELECT * FROM customer; CREATE VIEW tpch=# CREATE VIEW testcolumnVIEW2 AS SELECT * FROM customer; CREATE VIEW tpch=# CREATE VIEW 1test AS SELECT * FROM customer; CREATE VIEW tpch=# CREATE VIEW 1test2abc AS SELECT * FROM customer; CREATE VIEW tpch=# CREATE VIEW 1test2 AS SELECT * FROM customer; CREATE VIEW tpch=# select c.oid , c.oid::regclass from pg_class c where c.relname like '%test%'; oid | oid ---+-- 16410 | test 16413 | test1 16416 | 'test2' 16419 | testcolumnVIEW 16422 | testcolumnview 16425 | testcolumnview2 16428 | 1test2abc 16431 | 1test2 16434 | 1test (9 rows) Is this a bug? manu -- Emmanuel Cecchet Aster Data Systems Web: http://www.asterdata.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Regclass and quoted table names
Emmanuel Cecchet m...@asterdata.com writes: It looks like the behavior of regclass is not consistent when table names are quoted. The name is returned without the quotes if the name is lower case with eventual trailing numbers, otherwise it is returned with quotes. It's intentional that it quotes only when needed. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Make SIGHUP less painful if pg_hba.conf is not readable
Selena Deckelmann sel...@endpoint.com writes: From the comment in hba.c, it appears that the desired behavior is to have the system ignore the failure, I'm not sure how you could possibly read that comment that way. It might be sane to distinguish initial load from reload, but I think the behavior is correct as-is for initial load. Also, if we are going to do something like this, we should make sure it's consistent across all the config files. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot standby, running xacts, subtransactions
On Tuesday 03 March 2009 03:22:30 Simon Riggs wrote: On Mon, 2009-03-02 at 21:11 -0500, Robert Treat wrote: On Wednesday 25 February 2009 16:43:54 Simon Riggs wrote: On Wed, 2009-02-25 at 13:33 -0800, Josh Berkus wrote: You raised that as an annoyance previously because it means that connection in hot standby mode may be delayed in cases of heavy, repeated use of significant numbers of subtransactions. While most users still don't use explicit subtransactions at all, wouldn't this also affect users who use large numbers of stored procedures? If they regularly use more than 64 levels of nested EXCEPTION clauses *and* they start their base backups during heavy usage of those stored procedures, then yes. We have stored procedrues that loop over thousands of records, with begin...exception blocks in that loop, so I think we do that. AFAICT there's no way to tell if you have it wrong until you fire up the standby (ie. you can't tell at the time you make your base backup), right ? That was supposed to be a simplification for phase one, not a barrier for all time. Understood; I only mention it because it's usually good to know how quickly we run into some of these cases that we don't think will be common. I'm changing that now, though the effect will be that in some cases we take longer before we accept connections. The initialisation requirements are that we have full knowledge of transactions in progress before we allow snapshots to be taken. That seems pretty reasonable; hopefully people aren't setting up hot standy machines as an emergency scaling technique :-) -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Make SIGHUP less painful if pg_hba.conf is not readable
Tom Lane wrote: Selena Deckelmann sel...@endpoint.com writes: From the comment in hba.c, it appears that the desired behavior is to have the system ignore the failure, I'm not sure how you could possibly read that comment that way. Right. Sorry, poor choice of words. I meant don't die on reload, essentially. It might be sane to distinguish initial load from reload, but I think the behavior is correct as-is for initial load. Agreed. Also, if we are going to do something like this, we should make sure it's consistent across all the config files. Ok. I can do that. I'll check with some other people before I send another patch, and I'll go through the rest of the config file loads tomorrow. -selena -- Selena Deckelmann End Point Corporation sel...@endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
