Re: [HACKERS] Temporary tables under hot standby
On Mon, May 07, 2012 at 09:04:28AM -0500, Merlin Moncure wrote: On Mon, May 7, 2012 at 8:52 AM, Michael Nolan htf...@gmail.com wrote: To cross-pollinate with another thread, if temporary tables (and insert/delete/update transactions to them) are to be supported on a slave, will the applications using those temporary tables expect to be able to use 'nextval' on inserts to temporary tables as well? That's a very good question. I'm moving it -hackers...how do non table temporary objects work? Do you have CREATE GLOBAL TEMPORARY SEQUENCE? etc. Probably so, yes. My understanding of the current proposal is that the sequence (along with the rest of the table) has to be defined in the master as a global temporary table. Yes. It seems that it wouldn't be possible or desirable to serialize sequence fetches between the master and standby servers, but I'm not sure about that. Like global temporary tables, each session has an independent copy of each global temporary sequence. nextval would have no interaction with other local backends, let alone remote ones. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] WIP Patch: Selective binary conversion of CSV file foreign tables
I would like to propose to improve parsing efficiency of contrib/file_fdw by selective parsing proposed by Alagiannis et al.[1], which means that for a CSV/TEXT file foreign table, file_fdw performs binary conversion only for the columns needed for query processing. Attached is a WIP patch implementing the feature. I evaluated the efficiency of the patch using SELECT count(*) on a CSV file foreign table of 5,000,000 records, which had the same definition as the pgbench history table. The following run is done on a single core of a 3.00GHz Intel Xeon CPU with 8GB of RAM. Configuration settings are all default. w/o the patch: 7255.898 ms w/ the patch: 3363.297 ms On reflection of [2], I think it would be better to disable this feature when the validation option is set to 'true'; file_fdw converts all columns to binary representation. So, it verifies that each tuple meets all column data types as well as all kinds of constraints. I appreciate your comments. Best regards, Etsuro Fujita [1] http://homepages.cwi.nl/~idreos/NoDBsigmod2012.pdf [2] https://commitfest.postgresql.org/action/patch_view?id=822 file_fdw_sel_bin_conv_v1.patch Description: Binary data -- 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] problem/bug in drop tablespace?
The last portion of my original post got edited out by mistake. The tests I ran were on version 9.1.3, running Fedora 14, kernel 2.6.35.14-106.fc14-i686. It seems to me that DROP TABLESPACE should check to see if there are references in the system catalog to the tablespace before dropping it, not just that the tablespace itself is empty. That way it would have thrown an error when I tried to drop the tablespace. A somewhat separate issue is what to do when a tablespace is inaccessible, such as due to a disk failure. The thread on -general that prompted my tests was a relatively easy one to suggest how to repair, because the lost tablespace only had indexes in it. But that's not exactly a -hackers issue, more of a question of better backup protocols. -- Mike Nolan
Re: [HACKERS] smart shutdown at end of transaction (was: Default mode for shutdown)
On Tue, May 8, 2012 at 12:59 AM, Robert Haas robertmh...@gmail.com wrote: On Sat, May 5, 2012 at 12:41 PM, Fujii Masao masao.fu...@gmail.com wrote: On Sat, Apr 28, 2012 at 4:00 AM, Robert Haas robertmh...@gmail.com wrote: On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us wrote: I'm not necessarily opposed to commandeering the name smart for the new behavior, so that what we have to find a name for is the old smart behavior. How about slow - allow existing sessions to finish (old smart) smart - allow existing transactions to finish (new) fast - kill active queries immediate - unclean shutdown I could live with that. Really, I'd like to have fast just be the default. But the above compromise would still be a big improvement over what we have now, assuming the new smart becomes the default. Should this new shutdown mode wait for online backup like old smart does? I think it had better not, because what happens when all the connections are gone, no new ones can be made, and yet online backup mode is still active? Yep, I agree that new mode should not. This change of the default shutdown behavior might surprise some users, so it's better to document also this in release note. Regards, -- Fujii Masao -- 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] more possible dead ports cleanup
On mån, 2012-05-07 at 10:50 -0400, Robert Haas wrote: - (Side point, the definition of endof() in the same place isn't used anywhere, and doesn't look safe to me, because it can go one past the end of memory.) That I think we could remove. I decided to keep it because it was used not so long ago, so maybe it still has value. -- 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] age(xid) on hot standby
On ons, 2012-01-18 at 14:55 -0500, Tom Lane wrote:
BTW, it strikes me that maybe the coding should work about like this:
if (!TransactionIdIsValid(age_reference_xid))
{
age_reference_xid = GetTopTransactionIdIfAny();
if (!TransactionIdIsValid(age_reference_xid))
age_reference_xid = ReadNewTransactionId();
}
... use age_reference_xid to compute result ...
and of course code somewhere to reset age_reference_xid at end of xact.
How about this patch?
diff --git i/src/backend/access/transam/xact.c w/src/backend/access/transam/xact.c
index 7f412b1..25fbd05 100644
--- i/src/backend/access/transam/xact.c
+++ w/src/backend/access/transam/xact.c
@@ -43,6 +43,7 @@
#include storage/procarray.h
#include storage/sinvaladt.h
#include storage/smgr.h
+#include utils/builtins.h
#include utils/combocid.h
#include utils/guc.h
#include utils/inval.h
@@ -1938,6 +1939,7 @@ CommitTransaction(void)
AtCommit_Notify();
AtEOXact_GUC(true, 1);
+ AtEOXact_xid();
AtEOXact_SPI(true);
AtEOXact_on_commit_actions(true);
AtEOXact_Namespace(true);
@@ -2191,6 +2193,7 @@ PrepareTransaction(void)
/* PREPARE acts the same as COMMIT as far as GUC is concerned */
AtEOXact_GUC(true, 1);
+ AtEOXact_xid();
AtEOXact_SPI(true);
AtEOXact_on_commit_actions(true);
AtEOXact_Namespace(true);
@@ -2337,6 +2340,7 @@ AbortTransaction(void)
AtEOXact_CatCache(false);
AtEOXact_GUC(false, 1);
+ AtEOXact_xid();
AtEOXact_SPI(false);
AtEOXact_on_commit_actions(false);
AtEOXact_Namespace(false);
diff --git i/src/backend/utils/adt/xid.c w/src/backend/utils/adt/xid.c
index 1829b82..9cf6256 100644
--- i/src/backend/utils/adt/xid.c
+++ w/src/backend/utils/adt/xid.c
@@ -86,22 +86,45 @@ xideq(PG_FUNCTION_ARGS)
PG_RETURN_BOOL(TransactionIdEquals(xid1, xid2));
}
+
/*
* xid_age - compute age of an XID (relative to current xact)
+ *
+ * We don't want to allocate a new transaction ID just for calling age(),
+ * because it should be avoided in an otherwise read-only transaction, and to
+ * make this work under hot standby. But calling ReadNewTransactionId() would
+ * make this function volatile (instead of stable), so we cache the reference
+ * point for the duration of the transaction.
*/
+
+static TransactionId age_reference_xid = InvalidTransactionId;
+
Datum
xid_age(PG_FUNCTION_ARGS)
{
TransactionId xid = PG_GETARG_TRANSACTIONID(0);
- TransactionId now = GetTopTransactionId();
+
+ if (!TransactionIdIsValid(age_reference_xid))
+ {
+ age_reference_xid = GetTopTransactionIdIfAny();
+ if (!TransactionIdIsValid(age_reference_xid))
+ age_reference_xid = ReadNewTransactionId();
+ }
/* Permanent XIDs are always infinitely old */
if (!TransactionIdIsNormal(xid))
PG_RETURN_INT32(INT_MAX);
- PG_RETURN_INT32((int32) (now - xid));
+ PG_RETURN_INT32((int32) (age_reference_xid - xid));
}
+void
+AtEOXact_xid(void)
+{
+ age_reference_xid = InvalidTransactionId;
+}
+
+
/*
* xidComparator
* qsort comparison function for XIDs
diff --git i/src/include/utils/builtins.h w/src/include/utils/builtins.h
index f246f11..b7906b8 100644
--- i/src/include/utils/builtins.h
+++ w/src/include/utils/builtins.h
@@ -795,6 +795,7 @@ extern Datum xidrecv(PG_FUNCTION_ARGS);
extern Datum xidsend(PG_FUNCTION_ARGS);
extern Datum xideq(PG_FUNCTION_ARGS);
extern Datum xid_age(PG_FUNCTION_ARGS);
+extern void AtEOXact_xid(void);
extern int xidComparator(const void *arg1, const void *arg2);
extern Datum cidin(PG_FUNCTION_ARGS);
extern Datum cidout(PG_FUNCTION_ARGS);
--
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] Latch for the WAL writer - further reducing idle wake-ups.
Peter Geoghegan pe...@2ndquadrant.com writes: Attached patch removes the questionable SetLatch() call, under the assumption that it's okay if the WALWriter, having entered hibernation due to sustained inactivity (10 seconds) subsequently takes up to 5 seconds (2.5 on average) to notice that it has work to do. These values may need to be tweaked. I have not bothered with making the sleep time adaptive, because it's probably too late to do that. Now that I've actually read the patch, rather than just responding to your description of it, I find myself entirely unhappy with the proposed changes in the walwriter's sleep logic. You have introduced race conditions (it is NOT okay to reset the latch somewhere below the top of the loop) and degraded the walwriter's signal response time in normal non-hibernation state, to solve a problem not in evidence; to wit that backends spend too much time signaling the walwriter. Given the location of the only existing SetLatch call for the purpose, I find that proposition more than a bit doubtful. I see little or no value in trying to keep the walwriter's procLatch set when it's not hibernating, and I definitely don't think it is worth the risk of introducing bugs when we're about to start beta. I'm intending to rip all that out and go back to the plain ResetLatch at the top of the loop, WaitLatch at the bottom design, with the hibernation logic just controlling the timeout on the WaitLatch call. 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] Latch for the WAL writer - further reducing idle wake-ups.
On 8 May 2012 22:35, Tom Lane t...@sss.pgh.pa.us wrote: Now that I've actually read the patch, rather than just responding to your description of it, I find myself entirely unhappy with the proposed changes in the walwriter's sleep logic. You have introduced race conditions (it is NOT okay to reset the latch somewhere below the top of the loop) Yes, there is some checking of flags before the potential ResetLatch() call, which may be acted on. The code there is almost identical to that of the extant bgwriter code. I was under the impression that this did not amount to a race, though it's rather late now, and I'm feeling under the weather, so I have not taken steps to verify that I have it right. Arguably, you'd want somebody's SetLatch call to be ignored if and degraded the walwriter's signal response time in normal non-hibernation state, to solve a problem not in evidence; to wit that backends spend too much time signaling the walwriter. Given the location of the only existing SetLatch call for the purpose, I find that proposition more than a bit doubtful. I do too. The elaborate logic to reduce that overhead was nothing more than a vestige of the first version. I apologise for making such a basic error. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] Latch for the WAL writer - further reducing idle wake-ups.
Peter Geoghegan pe...@2ndquadrant.com writes: On 8 May 2012 22:35, Tom Lane t...@sss.pgh.pa.us wrote: Now that I've actually read the patch, rather than just responding to your description of it, I find myself entirely unhappy with the proposed changes in the walwriter's sleep logic. You have introduced race conditions (it is NOT okay to reset the latch somewhere below the top of the loop) Yes, there is some checking of flags before the potential ResetLatch() call, which may be acted on. The code there is almost identical to that of the extant bgwriter code. Um, yes, I noticed that shortly after sending my previous message. I'm pretty unhappy about the current state of the bgwriter loop, too. I rather wonder whether that coding explains the postmaster failed to shut down errors that we've been seeing lately in the buildfarm. Not noticing a shutdown signal promptly would go a long way towards explaining that. 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] Latch for the WAL writer - further reducing idle wake-ups.
On 9 May 2012 00:21, Peter Geoghegan pe...@2ndquadrant.com wrote: Yes, there is some checking of flags before the potential ResetLatch() call, which may be acted on. The code there is almost identical to that of the extant bgwriter code. I was under the impression that this did not amount to a race, though it's rather late now, and I'm feeling under the weather, so I have not taken steps to verify that I have it right. Arguably, you'd want somebody's SetLatch call to be ignored if Sent too early. That should be: Arguably, you'd want somebody's SetLatch call to be ignored under the circumstances that that could happen in both the bgwriter, and the WALWriter within my recent patch. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- 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] age(xid) on hot standby
On 8 May 2012 20:01, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2012-01-18 at 14:55 -0500, Tom Lane wrote:
BTW, it strikes me that maybe the coding should work about like this:
if (!TransactionIdIsValid(age_reference_xid))
{
age_reference_xid = GetTopTransactionIdIfAny();
if (!TransactionIdIsValid(age_reference_xid))
age_reference_xid = ReadNewTransactionId();
}
... use age_reference_xid to compute result ...
and of course code somewhere to reset age_reference_xid at end of xact.
How about this patch?
I think we should fix this, but not with this exact patch.
We should just use MyPgXact-xid
rather than add more to the transaction path
I'll simplify the patch and commit.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
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] WIP Patch: Selective binary conversion of CSV file foreign tables
On Tue, May 08, 2012 at 08:26:02PM +0900, Etsuro Fujita wrote: I would like to propose to improve parsing efficiency of contrib/file_fdw by selective parsing proposed by Alagiannis et al.[1], Is the patch they used against 9.0 published somewhere? Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] synchronous_commit and remote_write
It seems pretty confusing that synchronous_commit = 'remote_write' means write confirmed to the remote socket, not write to the file system. Is there no better term we could some up with? remote_pipe? remote_transfer? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Latch for the WAL writer - further reducing idle wake-ups.
I've applied the walwriter/checkpointer patch, with the mentioned re-simplification of the logic. While measuring that, I noticed that the stats collector was now the biggest repeated-wakeup culprit, so I took the time to latch-ify it as well. AFAICS we no longer have anything that wakes up oftener than once every five seconds when the system is idle, so life is looking pretty good in powertop land. 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] Readme of Buffer Management seems to have wrong sentence
While going through Readme in backend\storage\buffer, I found some point misleading. Normal Buffer Replacement Strategy -- -- .. .. Each buffer header contains a usage counter, which is incremented (up to a small limit value) whenever the buffer is unpinned. (This requires only the buffer header spinlock, which would have to be taken anyway to decrement the buffer reference count, so it's nearly free.) . I have checked the code and logic according to which usage counter is increased when the buffer is pinned. Another Doubt : Why in function BufferAlloc, it needs to hold the BufFreelistLock till it pin the buffer which increases its reference count. As what I understood is BufFreelistLock is to protect StrategyControl structure and till it finds a buffer to use.
Re: [HACKERS] synchronous_commit and remote_write
On Tue, May 8, 2012 at 9:13 PM, Bruce Momjian br...@momjian.us wrote: It seems pretty confusing that synchronous_commit = 'remote_write' means write confirmed to the remote socket, not write to the file system. Is there no better term we could some up with? remote_pipe? remote_transfer? remote_accept? And then, I could envision (if it continues down this road): off local remote_accept remote_write remote_sync remote_apply (implies visible to new connections on the standby) Not saying all off these are necessarily worth it, but they are all the various stages of WAL processing on the remote... -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- 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] synchronous_commit and remote_write
On Tue, May 08, 2012 at 10:04:46PM -0400, Aidan Van Dyk wrote: On Tue, May 8, 2012 at 9:13 PM, Bruce Momjian br...@momjian.us wrote: It seems pretty confusing that synchronous_commit = 'remote_write' means write confirmed to the remote socket, not write to the file system. Is there no better term we could some up with? remote_pipe? remote_transfer? remote_accept? And then, I could envision (if it continues down this road): off local remote_accept remote_write remote_sync remote_apply (implies visible to new connections on the standby) Not saying all off these are necessarily worth it, but they are all the various stages of WAL processing on the remote... The _big_ problem with write is that we might need that someday to indicate some other kind of write, e.g. write to kernel, fsync to disk. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] WIP Patch: Selective binary conversion of CSV file foreign tables
-Original Message- From: David Fetter [mailto:da...@fetter.org] Sent: Wednesday, May 09, 2012 9:25 AM To: Etsuro Fujita Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] WIP Patch: Selective binary conversion of CSV file foreign tables On Tue, May 08, 2012 at 08:26:02PM +0900, Etsuro Fujita wrote: I would like to propose to improve parsing efficiency of contrib/file_fdw by selective parsing proposed by Alagiannis et al.[1], Is the patch they used against 9.0 published somewhere? It's not. The patch's been created by myself. I don't know their patch. Best regards, Etsuro Fujita Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] Latch for the WAL writer - further reducing idle wake-ups.
On further reflection I've realized that there's a really unpleasant consequence of the walwriter change as-committed: it breaks the former guarantee that async commits would reach disk within at most 3 times the WalWriterDelay setting. They will still get written within at most 3 walwriter cycles, but a lone async commit occurring when the writer is hibernating could see a delay much longer than before. This seems to me to be unacceptable. Probably nobody cares that much about the exact multiplier of 3, but if the delay could be an order of magnitude or two more than that, that's going to make users of async commits unhappy. So what we need here is for XLogSetAsyncXactLSN() to be able to boot the walwriter out of hibernate mode. I still don't care in the least for the original hack of using the state of the procLatch to indicate whether the walwriter is hibernating, but we can add a separate flag instead so as to avoid having every trip through XLogSetAsyncXactLSN do a SetLatch call (which would be bad anyway since it would prevent the walwriter from sleeping normally). Since XLogSetAsyncXactLSN has to take the info_lck anyway, we might as well make this new flag be protected by info_lck. The walwriter won't need to change the flag's state very often, by definition, so that end of it isn't going to cost anything noticeable. 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] synchronous_commit and remote_write
On Tue, May 8, 2012 at 10:09 PM, Bruce Momjian br...@momjian.us wrote: And then, I could envision (if it continues down this road): off local remote_accept remote_write remote_sync remote_apply (implies visible to new connections on the standby) Not saying all off these are necessarily worth it, but they are all the various stages of WAL processing on the remote... The _big_ problem with write is that we might need that someday to indicate some other kind of write, e.g. write to kernel, fsync to disk. Well, yes, but in the sequence of: remote_accept remote_write remote_sync it is much more clear... With a single remote_write, you can't tell just by itself it that is intended to be it's a write *to* the remote, or it's a write *by* the remote. But when combined with other terms, only one makes sense in all cases. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- 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] synchronous_commit and remote_write
On Tue, May 08, 2012 at 10:29:31PM -0400, Aidan Van Dyk wrote: On Tue, May 8, 2012 at 10:09 PM, Bruce Momjian br...@momjian.us wrote: And then, I could envision (if it continues down this road): off local remote_accept remote_write remote_sync remote_apply (implies visible to new connections on the standby) Not saying all off these are necessarily worth it, but they are all the various stages of WAL processing on the remote... The _big_ problem with write is that we might need that someday to indicate some other kind of write, e.g. write to kernel, fsync to disk. Well, yes, but in the sequence of: remote_accept remote_write remote_sync it is much more clear... With a single remote_write, you can't tell just by itself it that is intended to be it's a write *to* the remote, or it's a write *by* the remote. But when combined with other terms, only one makes sense in all cases. Yep. In fact, remote_write I thought meant a remote write, while it currently means a write to the remote. I like remote_accept. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Latch for the WAL writer - further reducing idle wake-ups.
Peter Geoghegan pe...@2ndquadrant.com writes: On 9 May 2012 00:21, Peter Geoghegan pe...@2ndquadrant.com wrote: Yes, there is some checking of flags before the potential ResetLatch() call, which may be acted on. The code there is almost identical to that of the extant bgwriter code. I was under the impression that this did not amount to a race, though it's rather late now, and I'm feeling under the weather, so I have not taken steps to verify that I have it right. Arguably, you'd want somebody's SetLatch call to be ignored if Sent too early. That should be: Arguably, you'd want somebody's SetLatch call to be ignored under the circumstances that that could happen in both the bgwriter, and the WALWriter within my recent patch. I don't believe that for a moment, and even if it accidentally manages to not fail in today's code, it's *way* too fragile for my taste. I believe the bgwriter code needs to be fixed similarly to the way I changed the walwriter patch, namely that there needs to be a separate flag (not the latch's isSet state) advertising whether the bgwriter is currently in hibernation mode. Now, unlike the walwriter, there isn't any convenient place to keep such a flag where it can be inspected inside an already-existing spinlock or LWLock guard. However, unlike the walwriter there is not a correctness requirement for the bgwriter to wake up promptly. So I think we could just put a bool bgwriter_sleeping in ProcGlobal and accept the possibility of other processes sometimes seeing stale values. Thoughts? 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
