[HACKERS] [PATCH] fix segfault with DO and plperl/plperlu
If you do:
# DO $do$ 1; $do$ LANGUAGE plperlu;
# DO $do$ 1; $do$ LANGUAGE plperl;
You get a segfault as we try to SvREFCNT_dec(...); for the wrong
interpreter. To fix push down the restore_context() so that we do the
above on the correct perl interpreter.
--
*** a/src/pl/plperl/plperl.c
--- b/src/pl/plperl/plperl.c
***
*** 1154,1170 plperl_inline_handler(PG_FUNCTION_ARGS)
PG_CATCH();
{
current_call_data = save_call_data;
- restore_context(oldcontext);
if (desc.reference)
SvREFCNT_dec(desc.reference);
PG_RE_THROW();
}
PG_END_TRY();
current_call_data = save_call_data;
- restore_context(oldcontext);
if (desc.reference)
SvREFCNT_dec(desc.reference);
error_context_stack = pl_error_context.previous;
--- 1154,1170
PG_CATCH();
{
current_call_data = save_call_data;
if (desc.reference)
SvREFCNT_dec(desc.reference);
+ restore_context(oldcontext);
PG_RE_THROW();
}
PG_END_TRY();
current_call_data = save_call_data;
if (desc.reference)
SvREFCNT_dec(desc.reference);
+ restore_context(oldcontext);
error_context_stack = pl_error_context.previous;
*** a/src/pl/plperl/plperl.c
--- b/src/pl/plperl/plperl.c
***
*** 1154,1170 plperl_inline_handler(PG_FUNCTION_ARGS)
PG_CATCH();
{
current_call_data = save_call_data;
- restore_context(oldcontext);
if (desc.reference)
SvREFCNT_dec(desc.reference);
PG_RE_THROW();
}
PG_END_TRY();
current_call_data = save_call_data;
- restore_context(oldcontext);
if (desc.reference)
SvREFCNT_dec(desc.reference);
error_context_stack = pl_error_context.previous;
--- 1154,1170
PG_CATCH();
{
current_call_data = save_call_data;
if (desc.reference)
SvREFCNT_dec(desc.reference);
+ restore_context(oldcontext);
PG_RE_THROW();
}
PG_END_TRY();
current_call_data = save_call_data;
if (desc.reference)
SvREFCNT_dec(desc.reference);
+ restore_context(oldcontext);
error_context_stack = pl_error_context.previous;
--
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] testing HS/SR - 1 vs 2 performance
On Sat, 2010-04-17 at 18:52 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: What I'm not clear on is why you've used a spinlock everywhere when only weak-memory thang CPUs are a problem. Why not have a weak-memory-protect macro that does does nada when the hardware already protects us? (i.e. a spinlock only for the hardware that needs it). Well, we could certainly consider that, if we had enough places where there was a demonstrable benefit from it. I couldn't measure any real slowdown from adding a spinlock in that sinval code, so I didn't propose doing so at the time --- and I'm pretty dubious that this code is sufficiently performance-critical to justify the work, either. OK, I'll put a spinlock around access to the head of the array. Thanks for your input. -- Simon Riggs www.2ndQuadrant.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] testing HS/SR - 1 vs 2 performance
On Sun, 2010-04-18 at 08:24 +0100, Simon Riggs wrote:
On Sat, 2010-04-17 at 18:52 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
What I'm not clear on is why you've used a spinlock everywhere when only
weak-memory thang CPUs are a problem. Why not have a weak-memory-protect
macro that does does nada when the hardware already protects us? (i.e. a
spinlock only for the hardware that needs it).
Well, we could certainly consider that, if we had enough places where
there was a demonstrable benefit from it. I couldn't measure any real
slowdown from adding a spinlock in that sinval code, so I didn't propose
doing so at the time --- and I'm pretty dubious that this code is
sufficiently performance-critical to justify the work, either.
OK, I'll put a spinlock around access to the head of the array.
v2 patch attached
--
Simon Riggs www.2ndQuadrant.com
*** a/src/backend/access/transam/twophase.c
--- b/src/backend/access/transam/twophase.c
***
*** 1200,1205 StandbyTransactionIdIsPrepared(TransactionId xid)
--- 1200,1208
Assert(TransactionIdIsValid(xid));
+ if (max_prepared_xacts = 0)
+ return false; /* nothing to do */
+
/* Read and validate file */
buf = ReadTwoPhaseFile(xid, false);
if (buf == NULL)
*** a/src/backend/access/transam/xlog.c
--- b/src/backend/access/transam/xlog.c
***
*** 6453,6458 CheckRecoveryConsistency(void)
--- 6453,6464
}
}
+ bool
+ XLogConsistentState(void)
+ {
+ return reachedMinRecoveryPoint;
+ }
+
/*
* Is the system still in recovery?
*
*** a/src/backend/storage/ipc/procarray.c
--- b/src/backend/storage/ipc/procarray.c
***
*** 52,57
--- 52,58
#include access/twophase.h
#include miscadmin.h
#include storage/procarray.h
+ #include storage/spin.h
#include storage/standby.h
#include utils/builtins.h
#include utils/snapmgr.h
***
*** 64,73 typedef struct ProcArrayStruct
int numProcs; /* number of valid procs entries */
int maxProcs; /* allocated size of procs array */
! int numKnownAssignedXids; /* current number of known assigned
! * xids */
! int maxKnownAssignedXids; /* allocated size of known assigned
! * xids */
/*
* Highest subxid that overflowed KnownAssignedXids array. Similar to
--- 65,84
int numProcs; /* number of valid procs entries */
int maxProcs; /* allocated size of procs array */
! /*
! * Known assigned xids handling
! */
! int maxKnownAssignedXids; /* allocated size */
!
! /*
! * Callers must hold either ProcArrayLock in Exclusive mode or
! * ProcArrayLock in Shared mode *and* known_assigned_xids_lck
! * to update these values.
! */
! int numKnownAssignedXids; /* currrent # valid entries */
! int tailKnownAssignedXids; /* current tail */
! int headKnownAssignedXids; /* current head */
! slock_t known_assigned_xids_lck; /* shared protection lock */
/*
* Highest subxid that overflowed KnownAssignedXids array. Similar to
***
*** 87,93 static ProcArrayStruct *procArray;
/*
* Bookkeeping for tracking emulated transactions in recovery
*/
! static HTAB *KnownAssignedXidsHash;
static TransactionId latestObservedXid = InvalidTransactionId;
/*
--- 98,105
/*
* Bookkeeping for tracking emulated transactions in recovery
*/
! static TransactionId *KnownAssignedXids;
! static bool *KnownAssignedXidsValid;
static TransactionId latestObservedXid = InvalidTransactionId;
/*
***
*** 142,150 static int KnownAssignedXidsGet(TransactionId *xarray, TransactionId xmax);
static int KnownAssignedXidsGetAndSetXmin(TransactionId *xarray, TransactionId *xmin,
TransactionId xmax);
static bool KnownAssignedXidsExist(TransactionId xid);
! static void KnownAssignedXidsAdd(TransactionId *xids, int nxids);
static void KnownAssignedXidsRemove(TransactionId xid);
! static void KnownAssignedXidsRemoveMany(TransactionId xid, bool keepPreparedXacts);
static void KnownAssignedXidsDisplay(int trace_level);
/*
--- 154,166
static int KnownAssignedXidsGetAndSetXmin(TransactionId *xarray, TransactionId *xmin,
TransactionId xmax);
static bool KnownAssignedXidsExist(TransactionId xid);
! static void KnownAssignedXidsAdd(TransactionId from_xid, TransactionId to_xid,
! bool exclusive_lock);
static void KnownAssignedXidsRemove(TransactionId xid);
! static void KnownAssignedXidsRemoveMany(TransactionId xid);
! static void KnownAssignedXidsRemoveTree(TransactionId xid, int nsubxids,
! TransactionId *subxids);
! static void KnownAssignedXidsCompress(bool full);
static void KnownAssignedXidsDisplay(int trace_level);
/*
***
*** 204,228 CreateSharedProcArray(void)
procArray-numKnownAssignedXids = 0;
procArray-maxKnownAssignedXids = TOTAL_MAX_CACHED_SUBXIDS;
Re: [HACKERS] patch: Distinguish between unique indexes and unique constraints
On Sat, Apr 17, 2010 at 11:53 PM, Josh Kupershmidt schmi...@gmail.com wrote: Addressing TODO item Distinguish between unique indexes and unique constraints in \d+ for psql, and picking up from thread: http://archives.postgresql.org/message-id/8780.1271187...@sss.pgh.pa.us Attached is a simple patch which clarifies unique constraints with UNIQUE CONSTRAINT in psql's \d+ description of a table. The appearance of unique indexes is left as-is. == Old \d+ display == Indexes: name_uniq_constr UNIQUE, btree (name) == New \d+ display == Indexes: name_uniq_constr UNIQUE CONSTRAINT, btree (name) You know, I've never really understood the difference between these two types of things, or why we need to support both. Which may be just because I'm slow? ...Robert -- 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] patch: Distinguish between unique indexes and unique constraints
Robert Haas robertmh...@gmail.com writes: You know, I've never really understood the difference between these two types of things, or why we need to support both. Which may be just because I'm slow? Unique constraints are defined by the SQL standard, and have a syntax that can't support a lot of the extensions that CREATE INDEX allows. There's also restrictions in the information_schema views. So unifying the two concepts completely would be a mess. 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] patch: Distinguish between unique indexes and unique constraints
On Sun, Apr 18, 2010 at 11:23 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: You know, I've never really understood the difference between these two types of things, or why we need to support both. Which may be just because I'm slow? Unique constraints are defined by the SQL standard, and have a syntax that can't support a lot of the extensions that CREATE INDEX allows. There's also restrictions in the information_schema views. So unifying the two concepts completely would be a mess. I thought it might be something like that. Josh - you may want to add your patch here: https://commitfest.postgresql.org/action/commitfest_view/open ...Robert -- 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] patch: Distinguish between unique indexes and unique constraints
On Sun, Apr 18, 2010 at 11:41 AM, Robert Haas robertmh...@gmail.com wrote: Josh - you may want to add your patch here: https://commitfest.postgresql.org/action/commitfest_view/open Added, thanks! 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] [PATCH] fix segfault with DO and plperl/plperlu
Alex Hunsaker bada...@gmail.com writes: If you do: # DO $do$ 1; $do$ LANGUAGE plperlu; # DO $do$ 1; $do$ LANGUAGE plperl; You get a segfault as we try to SvREFCNT_dec(...); for the wrong interpreter. To fix push down the restore_context() so that we do the above on the correct perl interpreter. Hmm. I don't see a segfault on my machine, but I agree that this looks bogus. I changed it to this order instead: if (desc.reference) SvREFCNT_dec(desc.reference); current_call_data = save_call_data; restore_context(oldcontext); so as to keep the state restore operations together. 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] testing HS/SR - 1 vs 2 performance
On Sun, Apr 18, 2010 at 12:01:05PM +0100, Simon Riggs wrote: On Sun, 2010-04-18 at 08:24 +0100, Simon Riggs wrote: On Sat, 2010-04-17 at 18:52 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: What I'm not clear on is why you've used a spinlock everywhere when only weak-memory thang CPUs are a problem. Why not have a weak-memory-protect macro that does does nada when the hardware already protects us? (i.e. a spinlock only for the hardware that needs it). Well, we could certainly consider that, if we had enough places where there was a demonstrable benefit from it. I couldn't measure any real slowdown from adding a spinlock in that sinval code, so I didn't propose doing so at the time --- and I'm pretty dubious that this code is sufficiently performance-critical to justify the work, either. OK, I'll put a spinlock around access to the head of the array. v2 patch attached If you've committed this, or any other patch you've sent here, *please* mention so on the same thread. 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] enable_material patch
Robert Haas robertmh...@gmail.com writes: Here's a patch to add enable_material, per previous discussion. I still think we should add enable_joinremoval also, but there wasn't a clear consensus for that. I'd appreciate it if someone could check this over for sanity - like, did I get all the places where materialize nodes can be created? and, did i prevent them from being inserted anywhere that they are necessary for correctness? I think the code is all right, but the comments (or to be more precise, the complete lack of attention to the comments) not so much. Each of the places where you added an enable_material test has an associated comment that is reasonably thorough about explaining what's being checked and why. Adding an unrelated test and not adjusting the comment to account for it is not acceptable IMO. Also, as a matter of style, I don't care for burying enable_ checks down inside a nest of unrelated if-conditions. Rather than this: - else if (splan-parParam == NIL + else if (splan-parParam == NIL enable_material !ExecMaterializesOutput(nodeTag(plan))) plan = materialize_finished_plan(plan); I'd suggest else if (enable_material splan-parParam == NIL !ExecMaterializesOutput(nodeTag(plan))) and make sure that those tests line up with the order in which the conditions are explained in the associated comment. As far as missed changes go, the only place that I found where a material node can be created and you didn't touch it was in planner.c line 209. It's correct to not add an enable_ check there because the node is required for correctness, but maybe it'd be worth saying so in the comment? Otherwise somebody might fix it someday... Also, documentation-wise, I think this variable needs some weasel wording similar to what we have for enable_nestloop and enable_sort, ie point out that the variable cannot suppress all uses of materialization. If you fix that stuff I think this is OK to commit for 9.0. 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] testing HS/SR - 1 vs 2 performance
On Sun, 2010-04-18 at 13:16 -0700, David Fetter wrote: On Sun, Apr 18, 2010 at 12:01:05PM +0100, Simon Riggs wrote: On Sun, 2010-04-18 at 08:24 +0100, Simon Riggs wrote: On Sat, 2010-04-17 at 18:52 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: What I'm not clear on is why you've used a spinlock everywhere when only weak-memory thang CPUs are a problem. Why not have a weak-memory-protect macro that does does nada when the hardware already protects us? (i.e. a spinlock only for the hardware that needs it). Well, we could certainly consider that, if we had enough places where there was a demonstrable benefit from it. I couldn't measure any real slowdown from adding a spinlock in that sinval code, so I didn't propose doing so at the time --- and I'm pretty dubious that this code is sufficiently performance-critical to justify the work, either. OK, I'll put a spinlock around access to the head of the array. v2 patch attached If you've committed this, or any other patch you've sent here, *please* mention so on the same thread. I haven't yet. I've written two patches - this is a major module rewrite and is still under discussion. The other patch has nothing to do with this (though I did accidentally include a couple of changes from this patch and immediately revoked them). I will wait awhile to see if anybody has some independent test results. -- Simon Riggs www.2ndQuadrant.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] testing HS/SR - 1 vs 2 performance
On Sun, Apr 18, 2010 at 09:22:21PM +0100, Simon Riggs wrote: On Sun, 2010-04-18 at 13:16 -0700, David Fetter wrote: On Sun, Apr 18, 2010 at 12:01:05PM +0100, Simon Riggs wrote: On Sun, 2010-04-18 at 08:24 +0100, Simon Riggs wrote: On Sat, 2010-04-17 at 18:52 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: What I'm not clear on is why you've used a spinlock everywhere when only weak-memory thang CPUs are a problem. Why not have a weak-memory-protect macro that does does nada when the hardware already protects us? (i.e. a spinlock only for the hardware that needs it). Well, we could certainly consider that, if we had enough places where there was a demonstrable benefit from it. I couldn't measure any real slowdown from adding a spinlock in that sinval code, so I didn't propose doing so at the time --- and I'm pretty dubious that this code is sufficiently performance-critical to justify the work, either. OK, I'll put a spinlock around access to the head of the array. v2 patch attached If you've committed this, or any other patch you've sent here, *please* mention so on the same thread. I haven't yet. I've written two patches - this is a major module rewrite and is still under discussion. The other patch has nothing to do with this (though I did accidentally include a couple of changes from this patch and immediately revoked them). I will wait awhile to see if anybody has some independent test results. Thanks :) 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] [PATCH] fix segfault with DO and plperl/plperlu
On Sun, Apr 18, 2010 at 13:17, Tom Lane t...@sss.pgh.pa.us wrote: Alex Hunsaker bada...@gmail.com writes: You get a segfault as we try to SvREFCNT_dec(...); Hmm. I don't see a segfault on my machine, but I agree that this looks bogus. I changed it to this order instead: [ ... ] so as to keep the state restore operations together. Even better Thanks! -- 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] How to generate specific WAL records?
Now I've tested almost all WAL record, including CLOG_TRUNCATE and all the GIST and GIN-related WALs. I'm still struggling to find how to have XLOG_HEAP_INIT_PAGE and XLOG_BTREE_INSERT_META. I'm trying to find how to have these WAL records but it's a great help if anyone suggests me how. Thank you very much in advance; -- Koichi Suzuki 2010/4/15 Bruce Momjian br...@momjian.us: Kevin Grittner wrote: Koichi Suzuki koichi@gmail.com wrote: 2010/4/14 Simon Riggs si...@2ndquadrant.com: It would be a very useful test case to publish. I'm still struggling to generate remaing WAL records. Sure, but when you've got it all, please share. I'd like to see us have a much larger set of tests than the make check regression tests which would get run less frequently but test a lot more. This sounds like a good one to include. Agreed. This test belongs in our CVS tree so we can maintain it as we add new WAL types. -- Bruce Momjian br...@momjian.us http://momjian.us EnterpriseDB http://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] enable_material patch
On Sun, Apr 18, 2010 at 4:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Here's a patch to add enable_material, per previous discussion. I still think we should add enable_joinremoval also, but there wasn't a clear consensus for that. I'd appreciate it if someone could check this over for sanity - like, did I get all the places where materialize nodes can be created? and, did i prevent them from being inserted anywhere that they are necessary for correctness? I think the code is all right, but the comments (or to be more precise, the complete lack of attention to the comments) not so much. Each of the places where you added an enable_material test has an associated comment that is reasonably thorough about explaining what's being checked and why. Adding an unrelated test and not adjusting the comment to account for it is not acceptable IMO. Also, as a matter of style, I don't care for burying enable_ checks down inside a nest of unrelated if-conditions. Rather than this: - else if (splan-parParam == NIL + else if (splan-parParam == NIL enable_material !ExecMaterializesOutput(nodeTag(plan))) plan = materialize_finished_plan(plan); I'd suggest else if (enable_material splan-parParam == NIL !ExecMaterializesOutput(nodeTag(plan))) and make sure that those tests line up with the order in which the conditions are explained in the associated comment. As far as missed changes go, the only place that I found where a material node can be created and you didn't touch it was in planner.c line 209. It's correct to not add an enable_ check there because the node is required for correctness, but maybe it'd be worth saying so in the comment? Otherwise somebody might fix it someday... Also, documentation-wise, I think this variable needs some weasel wording similar to what we have for enable_nestloop and enable_sort, ie point out that the variable cannot suppress all uses of materialization. If you fix that stuff I think this is OK to commit for 9.0. Thanks for the review. Committed with revisions along the lines you suggest. ...Robert -- 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] shared_buffers documentation
On Wed, Apr 14, 2010 at 4:18 PM, Greg Smith g...@2ndquadrant.com wrote: As for updating the size recommendations, the text at http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server has been beaten into the status quo by a number of people. A few other random thoughts on this document: 1. The section on default_statistics_target needs some updating - the default is 100 in 8.4+. 2. Reading the section on checkpoint_segments reminds me, again, that the current value seems extremely conservative on modern hardware. It's quite easy to hit this when doing large bulk data loads or even a big ol' CTAS. I think we should consider raising this for 9.1. I don't have a real strong opinion on what we should raise it TO - I think it's basically a question of how much temporary disk storage we think we can use during a large bulk data load without having users come back and say wtf? - but it seems to me that we're not doing ourselves any favors by having this set to a value where the first advice we give our users is try tripling it. ...Robert -- 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] master in standby mode croaks
On Sun, Apr 18, 2010 at 7:52 AM, Robert Haas robertmh...@gmail.com wrote: On Sat, Apr 17, 2010 at 6:41 PM, Simon Riggs si...@2ndquadrant.com wrote: On Sat, 2010-04-17 at 17:44 -0400, Robert Haas wrote: I will change the error message. I gave a good deal of thought to trying to figure out a cleaner solution to this problem than just changing the error message and failed. So let's change the error message. Of course I'm not quite sure what we should change it TO, given that the situation is the result of an interaction between three different GUCs and we have no way to distinguish which one(s) are the problem. You need all three covers it. Actually you need standby_connections and either archive_mode=on or max_wal_senders0, I think. Right. First of all, I wonder why the latter two need to affect the decision of whether additional information is written to WAL for HS. How about just removing XLogIsNeeded() condition from XLogStandbyInfoActive()? 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
Re: [HACKERS] [GENERAL] trouble with to_char('L')
Magnus Hagander mag...@hagander.net wrote: But I'm unsure how that would work. We're talking about the output of localeconv(), right? I don't see a version of localeconv() that does wide chars anywhere. (You can't just set LC_CTYPE and use the regular function - Windows has a separate set of functions for dealing with UTF16). Yeah, msvcrt doesn't have wlocaleconv :-( . Since localeconv() returns characters in the encoding specified in LC_TYPE, we need to hande the issue with codes something like: 1. setlocale(LC_CTYPE, lc_monetary) 2. setlocale(LC_MONETARY, lc_monetary) 3. lc = localeconv() 4. pg_do_encoding_conversion(lc-xxx, FROM pg_get_encoding_from_locale(lc_monetary), TO GetDatabaseEncoding()) 5. Revert LC_CTYPE and LC_MONETARY. Another idea is to use GetLocaleInfoW() [1], that is win32 native locale functions, instead of the libc one. It returns locale characters in wide chars, so we can safely convert them as UTF16-UTF8-db. But it requires an additional branch in our locale codes only for Windows. [1] http://msdn.microsoft.com/en-us/library/dd318101 Regards, --- Takahiro Itagaki 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
Re: [HACKERS] master in standby mode croaks
On Sun, Apr 18, 2010 at 9:58 PM, Fujii Masao masao.fu...@gmail.com wrote: On Sun, Apr 18, 2010 at 7:52 AM, Robert Haas robertmh...@gmail.com wrote: On Sat, Apr 17, 2010 at 6:41 PM, Simon Riggs si...@2ndquadrant.com wrote: On Sat, 2010-04-17 at 17:44 -0400, Robert Haas wrote: I will change the error message. I gave a good deal of thought to trying to figure out a cleaner solution to this problem than just changing the error message and failed. So let's change the error message. Of course I'm not quite sure what we should change it TO, given that the situation is the result of an interaction between three different GUCs and we have no way to distinguish which one(s) are the problem. You need all three covers it. Actually you need standby_connections and either archive_mode=on or max_wal_senders0, I think. Right. First of all, I wonder why the latter two need to affect the decision of whether additional information is written to WAL for HS. How about just removing XLogIsNeeded() condition from XLogStandbyInfoActive()? Bad idea, I think. If XLogIsNeeded() is returning false and XLogStandbyInfoActive() is returning true, the resulting WAL will still be unusable for HS, at least AIUI. ...Robert -- 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] cost_rescan (was: match_unsorted_outer() vs. cost_nestloop())
On Sat, Sep 12, 2009 at 6:14 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Sep 6, 2009, at 10:45 AM, Tom Lane t...@sss.pgh.pa.us wrote: ... But now that we have a plan for a less obviously broken costing approach, maybe we should open the floodgates and allow materialization to be considered for any inner path that doesn't materialize itself already Maybe. I think some experimentation will be required. We also have to be aware of effects on planning time; match_unsorted_outer() is, AIR, a significant part of the CPU cost of planning large join problems. I've committed some changes pursuant to this discussion. It may be that match_unsorted_outer gets a bit slower, but I'm not too worried about that. My experience is that the code that tries different mergejoin options eats way more cycles than the nestloop code does. One problem with the current implementation of cost_rescan() is that it ignores caching effects. It seems to be faster to rescan a materialize node than it is to rescan a seqscan of a table, even if there are no restriction clauses, presumably because you get to skip tuple visibility checks and maybe some other overhead, too. But cost_rescan() thinks that rescanning the table will require rereading the whole thing from disk, which isn't right either - it probably ought to factor in effective_cache_size much as the estimates for iterated index scans do. I'm not sure how many real problems this is going to create. Another potential problem is that materializing a whole-table seqscan to avoid repeating the tuple visibility checks may be a win in some strict sense, but there are externalities: it's also going to use a lot more memory/disk than just rescanning the table. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
