[HACKERS] DOCS: SGML identifier may not exceed 44 characters
Hi folks, I was working on a little docs patch today, and when I tried to `make`, openjade choked on an identifier in information_schema.sgml, which is very much unrelated to my changes: openjade:information_schema.sgml:828:60:Q: length of name token must not exceed NAMELEN (44) Here is a trivial patch to shut openjade up. This particular id does not appear to be referred to anywhere else in the docs yet. The identifier appears to have been introduced in commit 2e2d56fea97f43cf8c40a87143bc10356e4ed4d4 on Feb 9 this year. I'm using openjade 1.3.2. Cheers, BJ diff --git a/doc/src/sgml/information_schema.sgml b/doc/src/sgml/information_schema.sgml index 2febb4c..5fdbd51 100644 --- a/doc/src/sgml/information_schema.sgml +++ b/doc/src/sgml/information_schema.sgml @@ -825,7 +825,7 @@ /table /sect1 - sect1 id=infoschema-collation-character-set-applicability + sect1 id=infoschema-collation-charset-applicability titleliteralcollation_character_set_applicability/literal/title para -- 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] Online base backup from the hot-standby
On 31.05.2011 07:46, Jun Ishiduka wrote: I don't much like that approach. The standby would need to be able to write the backup history file to the archive at the end of backup, and we'd have to reintroduce the code to fetch it from archive and, when streaming, from the master. At the moment, the archiver doesn't even run in the standby. Please teach the reason for The standby would need to be able to write the backup history file to the archive at the end of backup . (I'd like to know why to only pg_xlog is wrong .) If the backup history file is not archived, the postgres process won't find it when you try to restore from the base backup. The new server has no access to the standby's pg_xlog directory. Because there is the opinion of Cascade replication , I don't want to realize the function with the method which the standby requests to execute it on the primary server . (The opinion of Cascade replication： http://archives.postgresql.org/pgsql-hackers/2011-05/msg01150.php) I don't see how this helps. -- 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] Cube Index Size
On 30.05.2011 21:51, Nick Raj wrote:
Hi,
Cube code provided by postgres contrib folder. It uses the NDBOX structure.
On creating index, it's size increase at a high rate.
On inserting some tuple and creating indexes its behaviour is shown below.
1. When there is only one tuple
select pg_size_pretty(pg_relation_
size('cubtest')); //Table size without index
pg_size_pretty
8192 bytes
(1 row)
select pg_size_pretty(pg_total_relation_size('cubtest')); //Table size with
index
pg_size_pretty
16 kB
(1 row)
i.e. Index size in nearly 8kB
2. When tuples are 20,000
Table Size without index - 1.6 MB
Table Size with index - 11 MB
i.e. Index size is nearly 9.4 MB
3. When tuples are 5 lakh
Table Size without index - 40 MB
Table Size with index - 2117 MB
i.e. Index size is nearly 2077 MB ~ 2GB
It is taking nearly 20-25 min for creating index for 5 lakh tuples.
Can some one tell me why index is becoming so large?
How to compress or reduce its size?
Which version of PostgreSQL are you using? I wonder if this could be due
to the bug in cube's picksplit algorithm that was fixed a while ago:
http://archives.postgresql.org/message-id/aanlktimc8w6guhpwjewdjqa6wgovh-7qg9ar4pem2...@mail.gmail.com
If not, please post a self-contained test case to create and populate
the table, so that others can easily try to reproduce it.
--
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] switch UNLOGGED to LOGGED
I think we need a detailed design document for how this is all going to work. We need to not only handle the master properly but also handle the slave properly. Consider, for example, the case where the slave begins to replay the transaction, reaches a restartpoint after replaying some of the new pages, and then crashes. If the subsequent restart from the restartpoint blows away the main relation fork, we're hosed. I fear we're plunging into implementation details without having a good overall design in mind first. As I said in my first post, I'm basing the patch on the post: http://archives.postgresql.org/pgsql-hackers/2011-01/msg00315.php So I assumed the design was ok (except for the stray file around on a standby case, which has been discussed earlier on this thread). If there are things to be discussed/analyzed (I guess the restart point thing is one of those) we can do it... but I thought that the whole design was somehow in place Leonardo -- 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] adding applications to the stack builder
On Mon, May 30, 2011 at 9:45 AM, Gaetano Giunta giunta.gaet...@gmail.com wrote: Hello I would like to know what is the process to get new applications accepted for inclusion in the stack builder (namely the eZ Publish cms). I would be ready spend some time to package the application according to some specific format, and to host the built package on some dedicated server if there is need - but the only thing I've found so far is a project in pgfoundry that looks abandonware (not a lot of activity since 2007...) There hasn't been much need to change any of the code :-) Anyway, I can help with adding apps - please reply to me offlist. Have you done any work on an installer so far? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Getting a bug tracker for the Postgres project
On mån, 2011-05-30 at 22:43 -0400, Andrew Dunstan wrote: One of the conclusions the study group came to was that there should be good integration between the tracker system and the SCM. That was in the days before distributed SCMs were common, and in a commercial context, so I'm not sure how well our reasoning would stand up for the current context, but I see it's been mentioned elsewhere and I think it's a significant consideration, at least. What kind of functionality would (good) SCM integration provide? -- 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] Getting a bug tracker for the Postgres project
On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote: The number of people reading and replying to emails on pgsql-bugs is already insufficient, perhaps because of the (incorrect) perception that Tom does or will fix everything and no one else needs to care. So anything that makes it harder for people to follow along and participate is a non-starter IMV. Or the number of people usefully participating in pgsql-bugs is low because it is a waste of time to try to do anything useful there without appropriate tracker support. -- 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] Fix for GiST penalty
On 31.05.2011 01:07, Alexander Korotkov wrote: In gist_box_penalty function floating point error in line *result = (float) (size_box(ud) - size_box(origentry-key)); sometimes makes *result a very small negative number. I beleive that best place to fix it is gistpenalty function. The attached patch makes this function treating negative number from user's penalty as zero. I didn't find mention of negative penalty value in documentation. So, AFAICS such behaviour shouldn't break anything. After the patch index performance is ok. Yeah, there seems to be a hidden assumption that the return value of the penalty function is always = 0. The logic in gistchoose() in particular seems to assume that, by using 0 to mean uninitialized slots in the which_grow array. The documentation should be fixed too. -- 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] Getting a bug tracker for the Postgres project
On mån, 2011-05-30 at 20:16 -0400, Christopher Browne wrote: My suspicion is that RT may be rather a lot heavier weight in terms of how it would have to affect process than people would be happy with. What has been pretty clearly expressed is that various of the developers prefer for the mailing lists and archives thereof to be the primary data source and the venue for bug discussions. RT, and Bugzilla, and pretty well the bulk of the issue trackers out there are designed to themselves be the venue for discussions, and that's not consistent with the preference for email discussions. I'd be more optimistic that debbugs, or an adaption thereof, might more nearly fit into the workflow. Any bug tracker that has an adequate email interface will be isomorphic in terms of how intrusive it is. So I think your argument above is merely a reflection of how people have traditionally used these systems, not how they have to be used. -- 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] Getting a bug tracker for the Postgres project
On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote: I have used RT and I found that the web interface was both difficult to use and unwieldly for tickets containing large numbers of messages. Maybe those those things have been improved, but frankly if RT or Bugzilla is the best we can come up with then I'd rather not have a bug tracker at all. Given that you have been one of the people calling for a bug tracker, and these are the two most widely used systems available, what's wrong with them and what else would you suggest? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [ADMIN] 'SGT DETAIL: Could not open file pg_clog/05DC: No such file or directory' - what to do now?
On 31.05.2011 05:16, Tom Lane wrote: Tomasz Chmielewskiman...@wpkg.org writes: bookstor=# SELECT 1 FROM core_wot_seq FOR UPDATE; Um ... why are you doing that on a sequence? ERROR: could not access status of transaction 1573786613 DETAIL: Could not open file pg_clog/05DC: No such file or directory. This doesn't surprise me too much, because sequences are not expected to contain any live XIDs, so the XID freezing mechanism ignores them. So if you did that in the past, this would eventually happen. I think the most appropriate solution may be to disallow SELECT FOR UPDATE/SHARE on sequences ... so if you have a good reason why we shouldn't do so, please explain it. That's a good question. I grepped the sources of the application using postgres, and it certainly doesn't do it. We use pgpool though, and I see: pool_process_query.c: snprintf(qbuf, sizeof(qbuf), SELECT 1 FROM %s FOR UPDATE, seq_rel_name); So it looks to be coming from pgpool 3.x (it didn't do it in 2.x version). This is a message explaining why it was introduced to pgpool: http://comments.gmane.org/gmane.comp.db.postgresql.pgpool.devel/348 This brings two questions: 1) whatever command I send to postgres, should I expect Could not open file pg_clog/05DC: No such file or directory? If so, it should be documented, and a way to recover from such a situation should be explained. 2) is pgpool behaviour correct? -- Tomasz Chmielewski http://wpkg.org -- 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] Getting a bug tracker for the Postgres project
On Mon, May 30, 2011 at 07:42, Greg Stark gsst...@mit.edu wrote: On Sun, May 29, 2011 at 10:09 PM, Stefan Kaltenbrunner ste...@kaltenbrunner.cc wrote: well bugzilla has an inbound email interface as well that can both be used to creande and to manipulate bugs (as in mails that have the bug-id in the subject will be added as a comment). Ugh, putting it in the subject plays poorly with MUAs like gmail that don't understand threading and group messages by subject. +a lot. Changing the subject will break a lot of things - it's annoying enough already with people who do that (when they shouldn't - doing it when the thread actually changes, is obviously good) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 07:08, Stefan Kaltenbrunner ste...@kaltenbrunner.cc wrote: On 05/31/2011 05:42 AM, Tom Lane wrote: Kim Bisgaard kim...@alleroedderne.adsl.dk writes: On 2011-05-30 04:26, Greg Stark wrote: My biggest gripe about bugzilla was that it sent you an email with updates to the bug but you couldn't respond to that email. Just checked bugzilla's list of features and they *now* lists that as supported: File/Modify Bugs By Email In addition to the web interface, you can send Bugzilla an email that will create a new bug, or will modify an existing bug. You can also very easily attach files to bugs this way. The claim is there all right, but the feature seems spectacularly undocumented otherwise. I wanted to see if it worked like debbugs (ie, you just cc: some mail to the bug tracker), but there's no information about exactly how to use it. Depends on what exactly you are looking for... * that feature relies on finding a valid bugid in the subject, if it finds one it will add the email ass a comment * if you would prefer something like nn-...@tracker.postgresql.org for adding to existing bugs, that would be a trivial thing to add as a feature(have the MTA split the localpart and pass it as a parameter in the pipe-transport to the email_in.pl script) * the challenge is more about creating new bugs, because for that you need a bz account (or maybe a community account in our case) by default. We could certainly modify the feature so that it will autocreate bz accounts as soon as we see a new emailaddress sending email in but that will be fairly hard to control spamwise. Yikes. (On the very last point there) But. I get the feeling we're approaching this backwards. Wouldn't the normal way to do it be to define the workflow we *want*, and then figure out which bugtracker works for that or requires the least changes for that, rather than to try to figure out which bugtracker we want and then see how much we have to change our workflow to match? The previous way is kind of what we did with the CF app, and while I have some things I want fixed in that one they are details - the process seems to work fine. So in order to start a brand new bikeshed to paint on, have we even considered a very trivial workflow like letting the bugtracker actually *only* track our existing lists and archives. That would mean: * Mailing lists are *primary*, and the mailing list archives are *primary* (yes, this probably requires a fix to the archives, but that really is a different issue) * New bugs are added by simply saying this messageid represents a thread that has this bug in it, and all the actual contents are pulled from the archives * On top of this, the bug just tracks metadata - such as open/closed more or less. It does *not* track the actual contents at all. * Bugs registered through the bugs form would of course automatically add such a messageid into the tracker. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Getting a bug tracker for the Postgres project
On mån, 2011-05-30 at 22:17 -0400, Tom Lane wrote: Christopher Browne cbbro...@gmail.com writes: On 2011-05-30 4:31 PM, Peter Eisentraut pete...@gmx.net wrote: Based on that, and past discussions, and things we've tried in the past, and gut feeling, and so on, it looks like Request Tracker would appear to be the next best thing to consider trying out. What do people think about that? I'd be more optimistic that debbugs, or an adaption thereof, might more nearly fit into the workflow. Yeah, that's my impression as well. I'm very familiar with debbugs, so if we'd use that, I would hit the ground running. But a few things to consider: * You would probably need a lot of manpower to customize and maintain this thing. And you'd be dealing with lots of unfamiliar technology. * Only very few people in Debian know the internals of this thing, so don't expect much timely help. * The actual workflow in Debian doesn't only consist of debbugs, but a bunch of ad hoc add-ons, additional web interfaces, and scripts. You'd have to adapt or port or replace some of these as well. * It's not a system set up for easy searching and aggregating, the sort of thing an SQL-savvy crowd might expect. One of the better ways nowadays to search for bugs in Debian is actually the UDD, which is a dump of the bug database imported into a PostgreSQL instance. See previous point. * Actually, a number of teams in Debian use Request Tracker as well (see http://wiki.debian.org/rt.debian.org). I don't know why, just saying. -- 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] Online base backup from the hot-standby
2011/5/31 Heikki Linnakangas heikki.linnakan...@enterprisedb.com: On 31.05.2011 07:46, Jun Ishiduka wrote: I don't much like that approach. The standby would need to be able to write the backup history file to the archive at the end of backup, and we'd have to reintroduce the code to fetch it from archive and, when streaming, from the master. At the moment, the archiver doesn't even run in the standby. Please teach the reason for The standby would need to be able to write the backup history file to the archive at the end of backup . (I'd like to know why to only pg_xlog is wrong .) If the backup history file is not archived, the postgres process won't find it when you try to restore from the base backup. The new server has no access to the standby's pg_xlog directory. Right. If we take a base backup from the standby by not using pg_basebackup, since there is no way to share the backup history file from the standby to new server, an idea like you suggested would be required. OTOH, if we use pg_basebackup, I think that it makes sense that pg_basebackup transfers the backup history file from the standby to new server, puts it in the base backup (pg_xlog?), and new server reads it from the base backup but not the archive. 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] Getting a bug tracker for the Postgres project
On mån, 2011-05-30 at 01:30 -0400, Greg Smith wrote: Greg Stark is right that Debbugs has a lot of interesting features similar to the desired workflow here. It's not tied to just Debian anymore; the GNU project is also using it now. For the benefit of others, I suppose you are referring to this: http://debbugs.gnu.org/ This is actually pretty exciting news, as it alleviates the main concern with debbugs, that's is in practice impossible to use outside of Debian. (The other nice thing is that those GNU projects have also been lacking a good bug tracker in the past.) Should we find the people behind this project and ask them to share some experiences? -- 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] Cube Index Size
2011/5/30, Nick Raj nickrajj...@gmail.com: 3. When tuples are 5 lakh For the benefit of the others: 5 lakh seems to mean 500,000. URL:http://en.wikipedia.org/wiki/Lakh Nicolas -- A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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] Getting a bug tracker for the Postgres project
On tis, 2011-05-31 at 10:36 +0200, Magnus Hagander wrote: I get the feeling we're approaching this backwards. Wouldn't the normal way to do it be to define the workflow we *want*, and then figure out which bugtracker works for that or requires the least changes for that, rather than to try to figure out which bugtracker we want and then see how much we have to change our workflow to match? Maybe you are assuming that there is a single workflow that everyone wants. So far we know that most people want to work by email and want to know that a bug is closed. Is there more detail than that that we can extract? So in order to start a brand new bikeshed to paint on, have we even considered a very trivial workflow like letting the bugtracker actually *only* track our existing lists and archives. That would mean: * Mailing lists are *primary*, and the mailing list archives are *primary* (yes, this probably requires a fix to the archives, but that really is a different issue) * New bugs are added by simply saying this messageid represents a thread that has this bug in it, and all the actual contents are pulled from the archives * On top of this, the bug just tracks metadata - such as open/closed more or less. It does *not* track the actual contents at all. * Bugs registered through the bugs form would of course automatically add such a messageid into the tracker. Well, that is not a workflow either, it's approaching the issue by proposing an implementation. Nothing says that an existing or new system doesn't work exactly like that. I would be concerned about the search capabilities of such a system, however. -- 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] Fix for GiST penalty
On Tue, May 31, 2011 at 12:06 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The documentation should be fixed too.
Patch with documentation fix is attached.
I tried to reproduce this problem on another computer with Windows, but
problem doesn't occurs. So, seems that it can be OS, compiler, optimization
level or CPU specific.
I provide some information about my laptop where I've encountered with
problem. I hope this helps to reproduce this problem if needed.
$ uname -a
Linux smagen-notebook 2.6.38-8-generic-pae #42-Ubuntu SMP Mon Apr 11
05:17:09 UTC 2011 i686 i686 i386 GNU/Linux
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=11.04
DISTRIB_CODENAME=natty
DISTRIB_DESCRIPTION=Ubuntu 11.04
$ gcc --version
gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz
stepping : 10
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3
cx16 xtpr pdcm lahf_lm ida dts tpr_shadow vnmi flexpriority
bogomips : 3990.66
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz
stepping : 10
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3
cx16 xtpr pdcm lahf_lm ida dts tpr_shadow vnmi flexpriority
bogomips : 3989.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
--
With best regards,
Alexander Korotkov.
*** a/doc/src/sgml/gist.sgml
--- b/doc/src/sgml/gist.sgml
***
*** 377,383 my_decompress(PG_FUNCTION_ARGS)
para
Returns a value indicating the quotecost/quote of inserting the new
entry into a particular branch of the tree. Items will be inserted
!down the path of least functionpenalty/function in the tree.
/para
para
--- 377,385
para
Returns a value indicating the quotecost/quote of inserting the new
entry into a particular branch of the tree. Items will be inserted
!down the path of least functionpenalty/function in the tree. Value
!returned by functionpenalty/function should be non-negative. Negative
!values returned by functionpenalty/function are treating as zero.
/para
para
*** a/src/backend/access/gist/gistutil.c
--- b/src/backend/access/gist/gistutil.c
***
*** 526,536 gistpenalty(GISTSTATE *giststate, int attno,
--- 526,540
if (giststate-penaltyFn[attno].fn_strict == FALSE ||
(isNullOrig == FALSE isNullAdd == FALSE))
+ {
FunctionCall3Coll(giststate-penaltyFn[attno],
giststate-supportCollation[attno],
PointerGetDatum(orig),
PointerGetDatum(add),
PointerGetDatum(penalty));
+ if (penalty 0.0)
+ penalty = 0.0;
+ }
else if (isNullOrig isNullAdd)
penalty = 0.0;
else
--
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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 11:47, Peter Eisentraut pete...@gmx.net wrote: On tis, 2011-05-31 at 10:36 +0200, Magnus Hagander wrote: I get the feeling we're approaching this backwards. Wouldn't the normal way to do it be to define the workflow we *want*, and then figure out which bugtracker works for that or requires the least changes for that, rather than to try to figure out which bugtracker we want and then see how much we have to change our workflow to match? Maybe you are assuming that there is a single workflow that everyone wants. So far we know that most people want to work by email and want to know that a bug is closed. Is there more detail than that that we can extract? Yeah, there might definitely be more than one. So in order to start a brand new bikeshed to paint on, have we even considered a very trivial workflow like letting the bugtracker actually *only* track our existing lists and archives. That would mean: * Mailing lists are *primary*, and the mailing list archives are *primary* (yes, this probably requires a fix to the archives, but that really is a different issue) * New bugs are added by simply saying this messageid represents a thread that has this bug in it, and all the actual contents are pulled from the archives * On top of this, the bug just tracks metadata - such as open/closed more or less. It does *not* track the actual contents at all. * Bugs registered through the bugs form would of course automatically add such a messageid into the tracker. Well, that is not a workflow either, it's approaching the issue by proposing an implementation. Nothing says that an existing or new Um, good point. I still stand by my argument though, even if I'm arguing against myself :-) system doesn't work exactly like that. I would be concerned about the search capabilities of such a system, however. We already have a search system that works reasonably well for the archives... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] How can I check the treatment of bug fixes?
From: Robert Haas robertmh...@gmail.com It might be useful, in this situation, for the OP to add this patch to the CommitFest application. https://commitfest.postgresql.org/action/commitfest_view/open Greg Smith g...@2ndquadrant.com wrote in message news:4de1a8e7.1030...@2ndquadrant.com... Discussion here seems to have wandered far away from useful suggestions for you, let's see if that's possible to return to that. Best way to confirm when a bug is resolved is to subscribe to the pgsql-committers mailing list. If a commit for this fix appears, odds are good the original bug number will be referenced. Even if it isn't, you may recognize it via its description. Until you see that, the bug is almost certainly still open. Bugs that are considered to impact the current version under development are sometimes listed at http://wiki.postgresql.org/wiki/Open_Items Adding a bug to there that's not really specific to the new version may not be considered good form by some. It is the closest thing to an open bug tracker around though, and adding items to there means they won't be forgotten about; it's checked regularly by developers considering when it's a good time to release another alpha or beta. Thank you. I understood that it's the best and perhaps only way to search the pgsql-committers mail archive periodically. I would be happy if some bug/issue tracker could kindly notify the issuer of status changes via email. I'll add my patch to either of CommitFest or Open Items list a few days later. (But I'm reluctant to pollute those pages with bug fixes which apply to previous versions. That can't be helped.) Regards MauMau -- 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] Getting a bug tracker for the Postgres project
On 05/31/2011 06:41 AM, Magnus Hagander wrote: We already have a search system that works reasonably well for the archives... I trust this weas a piece of sarcasm. I spoke to more than a few people at pgcon and nobody had a good word to say about the search system on the archives. 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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 14:44, Andrew Dunstan and...@dunslane.net wrote: On 05/31/2011 06:41 AM, Magnus Hagander wrote: We already have a search system that works reasonably well for the archives... I trust this weas a piece of sarcasm. I spoke to more than a few people at pgcon and nobody had a good word to say about the search system on the archives. Well, it's tsearch. And I've heard nobody say anything else than that it's *a lot* better than what we had before. But sure, it can probably be improved. But what people are then basically asying is that tsearch isn't good enough for searching. Which is too bad, but may be so, and in that case we need to fix *that*, rather than build Yet Another Service To Do The Same Thing Slightly Differently. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Getting a bug tracker for the Postgres project
On 05/31/2011 04:01 AM, Peter Eisentraut wrote: On mån, 2011-05-30 at 22:43 -0400, Andrew Dunstan wrote: One of the conclusions the study group came to was that there should be good integration between the tracker system and the SCM. That was in the days before distributed SCMs were common, and in a commercial context, so I'm not sure how well our reasoning would stand up for the current context, but I see it's been mentioned elsewhere and I think it's a significant consideration, at least. What kind of functionality would (good) SCM integration provide? Well, the most obvious one is that when a commit (or merge or push) is made that fixes a bug, the bug is annotated and its status updated. I know I've wasted plenty of time in the past first hunting for bugs and then hunting for the fixes, which aren't always clear from the commit messages. In a more centralized system you can also have fairly tightly integrated workflow (e.g. you can have the tracker open a branch when a bug is assigned, and you can prevent one being created without an issue being assigned) but that doesn't seem like such a good fit for us, nor for anyone using a distributed system like git. You could also argue that it's a bad thing for commercial organizations, but that's a debate for another place. The reason we wanted such a thing is that we were spending significant time managing the workflow issues, and doing tidy up. 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] Getting a bug tracker for the Postgres project
On tis, 2011-05-31 at 08:44 -0400, Andrew Dunstan wrote: On 05/31/2011 06:41 AM, Magnus Hagander wrote: We already have a search system that works reasonably well for the archives... I trust this weas a piece of sarcasm. I spoke to more than a few people at pgcon and nobody had a good word to say about the search system on the archives. To some degree, the lack of a good search for the archives is half the problem. Not that a better search would be a replacement for a bug tracker, but it would go a long way. -- 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] Reducing overhead of frequent table locks
On Wed, May 25, 2011 at 3:35 PM, Tom Lane t...@sss.pgh.pa.us wrote: Simon Riggs si...@2ndquadrant.com writes: On Wed, May 25, 2011 at 1:44 PM, Robert Haas robertmh...@gmail.com wrote: On Wed, May 25, 2011 at 8:27 AM, Simon Riggs si...@2ndquadrant.com wrote: Design seemed relatively easy from there: put local lock table in shared memory for all procs. We then have a use_strong_lock at proc and at transaction level. Anybody that wants a strong lock first sets use_strong_lock at proc and transaction level, then copies all local lock data into shared lock table, I'm not following this... Which bit aren't you following? It's a design outline for how to implement, deliberately brief to allow a discussion of design alternatives. What I'm not following is how moving the local lock table into shared memory can possibly be a good idea. The reason we invented the local lock table in the first place (we didn't use to have one) is so that a process could do some manipulations without touching shared memory. (Notably, it is currently nearly free, and certainly lock-free, to re-request a lock type you already hold. This is not an infrequent case.) That advantage will go away if you do this. The basis for this is that weak locks do not conflict with each other, whereas strong locks conflict with both strong and weak locks. (There's a couple of special cases which I ignore for now). (Using Robert's description of strong/weak locks) Since most actions in normal running only require weak locks then we see that 99% of the time we don't need to share lock information at all. So the idea is that we have 2 modes of operation: mode (1) when nobody is requesting a strong lock we don't share lock information. We switch into mode (2) when somebody requests a strong lock and in this mode we must share all lock information just as we do now. The basic analysis is that we have a way of removing 99% of the overhead of lock information sharing. We still have the local lock table and we still perform locking, we just don't share that with other backends unless we need to. So there is a slight reduction in path length and a total avoidance of contention. Ideally, we would want to be in mode 2 for a short period of time. The difficulty is how to move from mode 1 (non-shared locking) to mode 2 (shared locking) and back again? A strong lock request causes the mode flip automatically via one of these mechanisms: 1. signal to each backend causes them to update shared lock information (at that point non-conflicting) 2. local lock table in shared memory 3. files 4. other The requirement is that the mode be flipped in all backends before we process the request for a strong lock. The idea is to make the local lock table accessible for occasional use in mode switching. Reading the local lock table by its owning backend would always be lock free. Locks are only required when modifying the local lock table by the owning backend, or when another backend reads it. So making the local lock table accessible is not a problem. Flipping back from mode 2 to mode 1 should be fairly slow, since DDL usually occurs in groups. -- 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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 15:07, Andrew Dunstan and...@dunslane.net wrote: On 05/31/2011 04:01 AM, Peter Eisentraut wrote: On mån, 2011-05-30 at 22:43 -0400, Andrew Dunstan wrote: One of the conclusions the study group came to was that there should be good integration between the tracker system and the SCM. That was in the days before distributed SCMs were common, and in a commercial context, so I'm not sure how well our reasoning would stand up for the current context, but I see it's been mentioned elsewhere and I think it's a significant consideration, at least. What kind of functionality would (good) SCM integration provide? Well, the most obvious one is that when a commit (or merge or push) is made that fixes a bug, the bug is annotated and its status updated. I know I've wasted plenty of time in the past first hunting for bugs and then hunting for the fixes, which aren't always clear from the commit messages. As long as we properly track email, we don't actually need a direct integration with the SCM for this - since we send the commit message out to the -committers list anyway, we just need to pick it up there. In a more centralized system you can also have fairly tightly integrated workflow (e.g. you can have the tracker open a branch when a bug is assigned, and you can prevent one being created without an issue being assigned) but that doesn't seem like such a good fit for us, nor for anyone using a distributed system like git. You could also argue that it's a bad thing for commercial organizations, but that's a debate for another place. The reason we wanted such a thing is that we were spending significant time managing the workflow issues, and doing tidy up. Yeah, that does sound like a very bad idea *for us*. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 4:12 AM, Peter Eisentraut pete...@gmx.net wrote: On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote: I have used RT and I found that the web interface was both difficult to use and unwieldly for tickets containing large numbers of messages. Maybe those those things have been improved, but frankly if RT or Bugzilla is the best we can come up with then I'd rather not have a bug tracker at all. Given that you have been one of the people calling for a bug tracker, and these are the two most widely used systems available, what's wrong with them and what else would you suggest? IIRC, both of them think that you should log into the web interface to send emails (which, in the case of Bugzilla, don't permit replies), rather than sending emails that show up in the web interface. But the web interface is, at least in RT, also seems to be pretty rudimentary. Suppose you have a thread with 40 emails in it. View that thread in Gmail. Now view it in RT. In RT, you will notice that there's no way to unexpand emails, and all of the data is loaded with the page, so you sit there for half a minute waiting for everything to load. There's also no suppression of duplicated or quoted meterial, as Gmail does. It's usable, I guess, but it's a long way from state-of-the-art. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pgpool versus sequences (was Re: [ADMIN] 'SGT DETAIL: Could not open file pg_clog/05DC: No such file or directory' - what to do now?)
Tomasz Chmielewski man...@wpkg.org writes: On 31.05.2011 05:16, Tom Lane wrote: I think the most appropriate solution may be to disallow SELECT FOR UPDATE/SHARE on sequences ... so if you have a good reason why we shouldn't do so, please explain it. I grepped the sources of the application using postgres, and it certainly doesn't do it. [ but pgpool does, as of a couple months ago ] This is a message explaining why it was introduced to pgpool: http://comments.gmane.org/gmane.comp.db.postgresql.pgpool.devel/348 Too bad that wasn't mentioned on pgsql-hackers, where someone might have pointed out the major flaws in the idea. 2) is pgpool behaviour correct? No. Quite aside from the lack-of-XID-maintenance problem, the proposal seems just plain bizarre to me. SELECT FOR UPDATE wouldn't block nextval(), so the command doesn't actually guarantee serialization of sequence value acquisition. Taking a table lock on the sequence could do so, and wouldn't run into any implementation issues, so I fail to see why that alternative was rejected. I'm also wondering a bit how one determines *which* sequence to lock, in a case where the table has multiple serial columns ... 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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander mag...@hagander.net wrote: I get the feeling we're approaching this backwards. Wouldn't the normal way to do it be to define the workflow we *want*, and then figure out which bugtracker works for that or requires the least changes for that, rather than to try to figure out which bugtracker we want and then see how much we have to change our workflow to match? The previous way is kind of what we did with the CF app, and while I have some things I want fixed in that one they are details - the process seems to work fine. So in order to start a brand new bikeshed to paint on, have we even considered a very trivial workflow like letting the bugtracker actually *only* track our existing lists and archives. That would mean: * Mailing lists are *primary*, and the mailing list archives are *primary* (yes, this probably requires a fix to the archives, but that really is a different issue) * New bugs are added by simply saying this messageid represents a thread that has this bug in it, and all the actual contents are pulled from the archives * On top of this, the bug just tracks metadata - such as open/closed more or less. It does *not* track the actual contents at all. * Bugs registered through the bugs form would of course automatically add such a messageid into the tracker. That's pretty much exactly what I think would be most useful. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 02:58:02PM +0200, Magnus Hagander wrote: On Tue, May 31, 2011 at 14:44, Andrew Dunstan and...@dunslane.net wrote: On 05/31/2011 06:41 AM, Magnus Hagander wrote: We already have a search system that works reasonably well for the archives... I trust this weas a piece of sarcasm. I spoke to more than a few people at pgcon and nobody had a good word to say about the search system on the archives. Well, it's tsearch. And I've heard nobody say anything else than that it's *a lot* better than what we had before. But sure, it can probably be improved. But what people are then basically asying is that tsearch isn't good enough for searching. Which is too bad, but may be so, and in that case we need to fix *that*, rather than build Yet Another Service To Do The Same Thing Slightly Differently. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ I do agree that the current archive search is much, much better than the searching before the upgrade. I would be interested in taking a look at some open source projects with a good search engine. Most projects have search engines that are true exercises in frustration by pulling either apparently everything or next to nothing and nothing in between. If there is a good one to look at maybe we can do some tweaking our search engine to improve it. Regards, Ken -- 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] Reducing overhead of frequent table locks
On Tue, May 31, 2011 at 9:22 AM, Simon Riggs si...@2ndquadrant.com wrote: The basis for this is that weak locks do not conflict with each other, whereas strong locks conflict with both strong and weak locks. (There's a couple of special cases which I ignore for now). (Using Robert's description of strong/weak locks) Since most actions in normal running only require weak locks then we see that 99% of the time we don't need to share lock information at all. So the idea is that we have 2 modes of operation: mode (1) when nobody is requesting a strong lock we don't share lock information. We switch into mode (2) when somebody requests a strong lock and in this mode we must share all lock information just as we do now. The basic analysis is that we have a way of removing 99% of the overhead of lock information sharing. We still have the local lock table and we still perform locking, we just don't share that with other backends unless we need to. So there is a slight reduction in path length and a total avoidance of contention. Ideally, we would want to be in mode 2 for a short period of time. The difficulty is how to move from mode 1 (non-shared locking) to mode 2 (shared locking) and back again? A strong lock request causes the mode flip automatically via one of these mechanisms: 1. signal to each backend causes them to update shared lock information (at that point non-conflicting) 2. local lock table in shared memory 3. files 4. other The requirement is that the mode be flipped in all backends before we process the request for a strong lock. The idea is to make the local lock table accessible for occasional use in mode switching. Reading the local lock table by its owning backend would always be lock free. Locks are only required when modifying the local lock table by the owning backend, or when another backend reads it. So making the local lock table accessible is not a problem. You can't actually make the local lock table lock-free to the owning backend, if other backends are going to be modifying it, or even examining it. However, as discussed upthread, what does seem possible is to allow each backend to maintain a queue of weak locks that are protected by an LWLock which is normally taken only by the owning backend, except on those rare occasions when a strong lock enters the picture. This doesn't completely eliminate LWLocks from the picture, but preliminary tests with my hacked-up, work-in-progress patch shows that it results in a very large decrease in LWLock *contention*. I'm going to post the patch once I get it debugged and tested a bit more. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Please test peer (socket ident) auth on *BSD
On 05/30/2011 07:57 PM, Tom Lane wrote: I've applied patches to fix Martin Pitt's report of peer auth failing on FreeBSD-amd64 kernels. I tested it with FreeBSD but do not have the resources to check every other platform that uses the same code branch in auth_peer. The buildfarm will soon tell us if the patches fail to compile anywhere, but since the buildfarm doesn't test that authentication path, it's not going to be as obvious whether it works. So, if you have a BSD-ish machine, please try HEAD and see if peer auth (or ident auth in older branches) still works for you. Extra points if you find out it used to be broken on your machine. (Hey Stefan, did you ever try that on spoonbill?) There's actually no reason we couldn't test this in the buildfarm. Turning it on unconditionally is a one-line change. Making it happen just on the right platforms would be a few more lines, but nothing much. It breaks the dblink regression tests, so we'd either have to get around that or turn it off when checking contrib. I can add this if you think it's worth it. But I did try it on my FBSD/x86_64 VM and it passed the tests up till it got to dblink, so there's another data point for you anyway. 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] Getting a bug tracker for the Postgres project
On 05/31/2011 09:33 AM, Robert Haas wrote: IIRC, both of them think that you should log into the web interface to send emails (which, in the case of Bugzilla, don't permit replies), rather than sending emails that show up in the web interface. I think you probably need to look at Bugzilla again. Here's what the current feature page at http://www.bugzilla.org/features/#email-in says: In addition to the web interface, you can send Bugzilla an email that will create a new bug, or will modify an existing bug. 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] Getting a bug tracker for the Postgres project
Robert Haas robertmh...@gmail.com writes: On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander mag...@hagander.net wrote: So in order to start a brand new bikeshed to paint on, have we even considered a very trivial workflow like letting the bugtracker actually *only* track our existing lists and archives. That would mean: * Mailing lists are *primary*, and the mailing list archives are *primary* (yes, this probably requires a fix to the archives, but that really is a different issue) * New bugs are added by simply saying this messageid represents a thread that has this bug in it, and all the actual contents are pulled from the archives * On top of this, the bug just tracks metadata - such as open/closed more or less. It does *not* track the actual contents at all. * Bugs registered through the bugs form would of course automatically add such a messageid into the tracker. That's pretty much exactly what I think would be most useful. I kinda wonder why the CF app doesn't work like that, actually. (Yeah, I know the poor thread linking in the archives is an issue.) 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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 09:33:33AM -0400, Robert Haas wrote: On Tue, May 31, 2011 at 4:12 AM, Peter Eisentraut pete...@gmx.net wrote: On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote: I have used RT and I found that the web interface was both difficult to use and unwieldly for tickets containing large numbers of messages. Maybe those those things have been improved, but frankly if RT or Bugzilla is the best we can come up with then I'd rather not have a bug tracker at all. Given that you have been one of the people calling for a bug tracker, and these are the two most widely used systems available, what's wrong with them and what else would you suggest? IIRC, both of them think that you should log into the web interface to send emails (which, in the case of Bugzilla, don't permit replies), rather than sending emails that show up in the web interface. But the web interface is, at least in RT, also seems to be pretty rudimentary. If you use the commands-by-email with RT you can do most things with Email. Suppose you have a thread with 40 emails in it. View that thread in Gmail. Now view it in RT. In RT, you will notice that there's no way to unexpand emails, and all of the data is loaded with the page, so you sit there for half a minute waiting for everything to load. There's also no suppression of duplicated or quoted meterial, as Gmail does. It's usable, I guess, but it's a long way from state-of-the-art. You can adjust what RT will display in the interface and the latest release does include some enhanced duplicate/quoted material suppression. Note, I am not pushing for RT necessarily just trying to keep information available. Regards, Ken -- 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] Getting a bug tracker for the Postgres project
Andrew Dunstan and...@dunslane.net writes: On 05/31/2011 06:41 AM, Magnus Hagander wrote: We already have a search system that works reasonably well for the archives... I trust this weas a piece of sarcasm. I spoke to more than a few people at pgcon and nobody had a good word to say about the search system on the archives. Please note, though, that there is no bug tracker anywhere whose search mechanism doesn't suck as much or more. If you're unhappy with the search stuff the solution is to improve it, not bring in another bad mechanism. 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] timezone GUC
On May 26, 2011, at 12:41 PM, Alvaro Herrera wrote: Yes, I think the lock-up is better than weird behavior. Maybe we should add a short note in a postgresql.conf comment to this effect, so that it doesn't surprise anyone that deletes or comments out the line. +1 on both counts. -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- 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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 16:21, Kevin Grittner kevin.gritt...@wicourts.gov wrote: k...@rice.edu k...@rice.edu wrote: maybe we can do some tweaking our search engine to improve it. A custom dictionary to carefully add a few synonyms might go a long way. I often need to try a number of permutations of likely words to get relevant hits. If you can provide one, please do :-) Right now, all we have is: postgres postgres postgresql postgres pgsql postgres pg postgres postgre postgres Including the subject line in searches, with a higher weight than message body text, would also be great. We already do this - we set them to class A with setweight(). Possibly it would help to be able to search on From or To fields (including CC in the To). Sometimes you have some recollection who participated in a discussion, but can't find the magic terms to get a small result set which includes the right discussion. This we don't do -w e store the From field, but we don't index it. And we don't do anything with the To field. So that's certainly something we could add. I really think some pretty minor tweaks in these areas would go a very long way toward making the archive searches more useful. Any patches are definitely welcome - you can find the search system at https://pgweb.postgresql.org/browser/trunk/portal/tools/search :-) (for the archives, you're probably most interested in classes/ArchiveIndexer.class.php and the sql/functions.sql file) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Getting a bug tracker for the Postgres project
k...@rice.edu k...@rice.edu wrote: maybe we can do some tweaking our search engine to improve it. A custom dictionary to carefully add a few synonyms might go a long way. I often need to try a number of permutations of likely words to get relevant hits. Including the subject line in searches, with a higher weight than message body text, would also be great. Possibly it would help to be able to search on From or To fields (including CC in the To). Sometimes you have some recollection who participated in a discussion, but can't find the magic terms to get a small result set which includes the right discussion. I really think some pretty minor tweaks in these areas would go a very long way toward making the archive searches more useful. -Kevin -- 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] Bug in XPATH() if expression returns a scalar value
Sorry for the self-reply but I figured it'd be helpful to add information that I discovered only after my initial post. On May30, 2011, at 15:17 , Florian Pflug wrote: The XPath expression 'name(/*)', for example, is supposed to return 'root' when applied to the XML fragment 'rootnested/nested//root'. Postgres, however, currently returns an empty array. In the mean while, I've discovered that this was discussed previously about a year ago here: http://archives.postgresql.org/pgsql-general/2010-07/msg00355.php The basic confusion seems to be whether XPATH() is supposed to work on everything that http://www.w3.org/TR/xpath/ consideres to be an Expression, or only on what that document calls a Location Path. The difference is basically that Location Paths server purely as predicates, i.e. *select* a subset of nodes from an XML fragment, while Expressions can produce node sets *or* arbitrary scalar values (boolean, numeric or string). According to the thread from last summer, XLST handles this by defining *two* constructs which evaluate XPath expressions, one for those which return node sets (xsl:template match=...) and one for those which return scalar values (xsl:value-of select=...). My patch makes XPATH() work for both nodset-returning *and* scalar-value-returning expressions. This has the advantage of being simpler, but it does force the scalar values produced by an XPath expression to be valid XML fragments. For boolean and numeric values this isn't a problem, but it does limit what you can do with string-returning XPath expressions. If people deem this to be a problem, we could instead add a separate function XPATH_VALUE() that returns VARCHAR, and make people use that for scalar-value-returning expressions. However, to avoid confusion, XPATH() should then be taught to raise an error if used for scalar-value returning expressions, instead of silently returning an empty array as it does now. Thoughts, anyone? best regards, Florian Pflug -- 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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 09:36:00AM -0400, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: On 05/31/2011 06:41 AM, Magnus Hagander wrote: We already have a search system that works reasonably well for the archives... I trust this weas a piece of sarcasm. I spoke to more than a few people at pgcon and nobody had a good word to say about the search system on the archives. Please note, though, that there is no bug tracker anywhere whose search mechanism doesn't suck as much or more. If you're unhappy with the search stuff the solution is to improve it, not bring in another bad mechanism. +1 Ken -- 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] Getting a bug tracker for the Postgres project
Magnus Hagander mag...@hagander.net wrote: Any patches are definitely welcome - you can find the search system at https://pgweb.postgresql.org/browser/trunk/portal/tools/search :-) (for the archives, you're probably most interested in classes/ArchiveIndexer.class.php and the sql/functions.sql file) I stashed this away for future reference; I'll take a look when I have a bit more free time. I suppose the first thing is to search the archives for posts about not being able to find some discussion in the archives, where someone then provides search criteria or a link.. I know I've seen a bunch of those -- I just hope I can find them... ;-) -Kevin -- 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] Getting a bug tracker for the Postgres project
On 05/31/2011 04:36 AM, Magnus Hagander wrote: So in order to start a brand new bikeshed to paint on, have we even considered a very trivial workflow like letting the bugtracker actually *only* track our existing lists and archives. That would mean: * Mailing lists are *primary*, and the mailing list archives are *primary* (yes, this probably requires a fix to the archives, but that really is a different issue) * New bugs are added by simply saying this messageid represents a thread that has this bug in it, and all the actual contents are pulled from the archives * On top of this, the bug just tracks metadata - such as open/closed more or less. It does *not* track the actual contents at all. * Bugs registered through the bugs form would of course automatically add such a messageid into the tracker. I have a web crawler for a website I maintain that I could modify to crawl through the archives of -bugs, say from 5 Dec 2003 where the first bug with the new format appears, and capture the structured data (reference, logged by, email address, PG version, OS, description, and message URL) into a table, for every message whose subject starts with BUG #, and capture each message URL for any message that has BUG # somewhere in the subject, in a second table. I presume the tables could be used even if it's decided to go with something like RT or BZ, but before I spend a couple of hours on this I'd like see some ayes or nays. Useful or not? Joe -- 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] pgpool versus sequences
Tomasz Chmielewski man...@wpkg.org writes: On 31.05.2011 05:16, Tom Lane wrote: I think the most appropriate solution may be to disallow SELECT FOR UPDATE/SHARE on sequences ... so if you have a good reason why we shouldn't do so, please explain it. I grepped the sources of the application using postgres, and it certainly doesn't do it. [ but pgpool does, as of a couple months ago ] This is a message explaining why it was introduced to pgpool: http://comments.gmane.org/gmane.comp.db.postgresql.pgpool.devel/348 Too bad that wasn't mentioned on pgsql-hackers, where someone might have pointed out the major flaws in the idea. 2) is pgpool behaviour correct? No. Quite aside from the lack-of-XID-maintenance problem, the proposal seems just plain bizarre to me. SELECT FOR UPDATE wouldn't block nextval(), so the command doesn't actually guarantee serialization of sequence value acquisition. Actually it was already explained before: http://archives.postgresql.org/pgsql-hackers/2011-01/msg00805.php At the time no one noticed the lack-of-XID-maintenance problem. Tomasz, thanks for the report. I will go back to old way as pgpool-II used to do, which is very inefficient unfortunately... Taking a table lock on the sequence could do so, and wouldn't run into any implementation issues, so I fail to see why that alternative was rejected. Table lock on the sequence? PostgreSQL doesn't allow it... I'm also wondering a bit how one determines *which* sequence to lock, in a case where the table has multiple serial columns ... No problem at least for pgpool-II. Just choose one of them and obtain lock on it is enough. Because purpose for the lock is to prevent concurrent INSERT to the table. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- 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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 10:02 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander mag...@hagander.net wrote: So in order to start a brand new bikeshed to paint on, have we even considered a very trivial workflow like letting the bugtracker actually *only* track our existing lists and archives. That would mean: * Mailing lists are *primary*, and the mailing list archives are *primary* (yes, this probably requires a fix to the archives, but that really is a different issue) * New bugs are added by simply saying this messageid represents a thread that has this bug in it, and all the actual contents are pulled from the archives * On top of this, the bug just tracks metadata - such as open/closed more or less. It does *not* track the actual contents at all. * Bugs registered through the bugs form would of course automatically add such a messageid into the tracker. That's pretty much exactly what I think would be most useful. I kinda wonder why the CF app doesn't work like that, actually. (Yeah, I know the poor thread linking in the archives is an issue.) I thought this pretty much WAS how the CF app works, except that it's for patches rather than bugs. Perhaps it could be extended to also track bugs... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 9:59 AM, Andrew Dunstan and...@dunslane.net wrote: On 05/31/2011 09:33 AM, Robert Haas wrote: IIRC, both of them think that you should log into the web interface to send emails (which, in the case of Bugzilla, don't permit replies), rather than sending emails that show up in the web interface. I think you probably need to look at Bugzilla again. Here's what the current feature page at http://www.bugzilla.org/features/#email-in says: In addition to the web interface, you can send Bugzilla an email that will create a new bug, or will modify an existing bug. That's possible. I haven't used it in about 5 years, and I suppose that makes my opinion of it hideously dated. I wouldn't like it if someone judged PostgreSQL based on what 8.1 can do. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] DOCS: SGML identifier may not exceed 44 characters
Excerpts from Brendan Jurd's message of mar may 31 02:17:22 -0400 2011: Hi folks, I was working on a little docs patch today, and when I tried to `make`, openjade choked on an identifier in information_schema.sgml, which is very much unrelated to my changes: openjade:information_schema.sgml:828:60:Q: length of name token must not exceed NAMELEN (44) Odd. I tried it here and it doesn't fail -- same openjade version. Maybe mine is patched. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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 integration
On Sat, May 28, 2011 at 4:39 AM, nil nil unprecedente...@yahoo.com wrote: Sir, i am developing a patch for postgresql in c language. i want to know that how can i integrate my patch with postgresql. regards emman This might be a good place to start: http://wiki.postgresql.org/wiki/Developer_FAQ -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] install softwares
On Sat, May 28, 2011 at 4:53 AM, nil nil unprecedente...@yahoo.com wrote: sir, i am developnig a patch and as per instructionsdescribed on this site http://wiki.postgresql.org/wiki/Developer_FAQ it is specifed on the link that along with unix platform we have to use GCC, GNU Make, GDB, Autoconf but i dont know how to install these softwares in linux ,because the commandas given on the web site are not working. please guide me for this. regards emman I think you're going to have to look elsewhere if you need help with basic Linux administration tasks such as installing software. People on this mailing list are usually pretty happy to answer questions that have something to do with PostgreSQL, but it sounds like your questions are a lot more general than that. As far as installing packages goes, it depends on what version of UNIX you are using. Red Hat Linux will be different from Debian or Solaris or FreeBSD. You might want to start by using Google to research some of these questions. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] switch UNLOGGED to LOGGED
On Tue, May 31, 2011 at 3:39 AM, Leonardo Francalanci m_li...@yahoo.it wrote: I think we need a detailed design document for how this is all going to work. We need to not only handle the master properly but also handle the slave properly. Consider, for example, the case where the slave begins to replay the transaction, reaches a restartpoint after replaying some of the new pages, and then crashes. If the subsequent restart from the restartpoint blows away the main relation fork, we're hosed. I fear we're plunging into implementation details without having a good overall design in mind first. As I said in my first post, I'm basing the patch on the post: http://archives.postgresql.org/pgsql-hackers/2011-01/msg00315.php So I assumed the design was ok (except for the stray file around on a standby case, which has been discussed earlier on this thread). Well, I sort of assumed the design was OK, too, but the more we talk about this WAL-logging stuff, the less convinced I am that I really understand the problem. :-( -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Getting a bug tracker for the Postgres project
Excerpts from Joe Abbate's message of mar may 31 10:43:07 -0400 2011: I have a web crawler for a website I maintain that I could modify to crawl through the archives of -bugs, say from 5 Dec 2003 where the first bug with the new format appears, and capture the structured data (reference, logged by, email address, PG version, OS, description, and message URL) into a table, for every message whose subject starts with BUG #, and capture each message URL for any message that has BUG # somewhere in the subject, in a second table. I presume the tables could be used even if it's decided to go with something like RT or BZ, but before I spend a couple of hours on this I'd like see some ayes or nays. Useful or not? I think this would be easier if you crawled the monthly mboxen instead of the web archives. It'd be preferable to use message-ids to identify messages rather than year-and-month based URLs. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] DOCS: SGML identifier may not exceed 44 characters
On Tue, May 31, 2011 at 3:22 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Brendan Jurd's message of mar may 31 02:17:22 -0400 2011: Hi folks, I was working on a little docs patch today, and when I tried to `make`, openjade choked on an identifier in information_schema.sgml, which is very much unrelated to my changes: openjade:information_schema.sgml:828:60:Q: length of name token must not exceed NAMELEN (44) Odd. I tried it here and it doesn't fail -- same openjade version. Maybe mine is patched. It's not likely an issue of how OpenJade was compiled; there has been a limitation in how SGML parsing was configured. If you poke around in /usr/share/sgml, you should find some configuration indicating NAMELEN was set to 44. I recall hearing that this was an issue in older Red Hat and derivative distributions, and thought that it was supposed to be resolved several years ago, but perhaps there's something to undermine that belief. At any rate, I'd suggest grepping around for NAMELEN in /usr/share/sgml; you'll likely see a limitation there, in some SGML configuration file. -- When confronted by a difficult problem, solve it by reducing it to the question, How would the Lone Ranger handle this? -- 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] Getting a bug tracker for the Postgres project
Robert Haas robertmh...@gmail.com writes: On Tue, May 31, 2011 at 10:02 AM, Tom Lane t...@sss.pgh.pa.us wrote: I kinda wonder why the CF app doesn't work like that, actually. (Yeah, I know the poor thread linking in the archives is an issue.) I thought this pretty much WAS how the CF app works, except that it's for patches rather than bugs. Perhaps it could be extended to also track bugs... Well, the point is you have to go and manually fool around with the web interface to enter something into CF, rather than just cc'ing it on your patch or review email. 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] creating CHECK constraints as NOT VALID
This patch allows you to initially declare a CHECK constraint as NOT VALID, similar to what we already allow for foreign keys. That is, you create the constraint without scanning the table and after it is committed, it is enforced for new rows; later, all rows are checked by running ALTER TABLE VALIDATE CONSTRAINT, which doesn't need AccessExclusive thus allowing for better concurrency. The trickiest bit here was realizing that unlike FKs, check constraints do inherit, and so needed special treatment for recursion. Other than that I think this was pretty straightforward. I intend to attempt to apply this to NOT NULL constraints as well, once the patch to add them to pg_constraint is in. Thoughts? This patch courtesy of Enova Financial. -- Álvaro Herrera alvhe...@alvh.no-ip.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [DOCS] [HACKERS] DOCS: SGML identifier may not exceed 44 characters
Christopher Browne cbbro...@gmail.com writes: On Tue, May 31, 2011 at 3:22 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Brendan Jurd's message of mar may 31 02:17:22 -0400 2011: openjade:information_schema.sgml:828:60:Q: length of name token must not exceed NAMELEN (44) Odd. I tried it here and it doesn't fail -- same openjade version. Maybe mine is patched. It's not likely an issue of how OpenJade was compiled; there has been a limitation in how SGML parsing was configured. If you poke around in /usr/share/sgml, you should find some configuration indicating NAMELEN was set to 44. On a Fedora 13 machine: $ grep -r NAMELEN /usr/share/sgml/ /usr/share/sgml/openjade-1.3.2/style-sheet.dtd: ArcQuant CDATA #FIXED NAMELEN 64 /usr/share/sgml/docbook/sgml-dtd-3.0-1.0-50.fc13/docbook.dcl: NAMELEN 256 /usr/share/sgml/docbook/sgml-dtd-3.0-1.0-50.fc13/cals-tbl.dtd: NOTE: This set of declarations assumes a NAMELEN of 32 as is used in /usr/share/sgml/docbook/sgml-dtd-4.4-1.0-50.fc13/docbook.dcl: NAMELEN 256 /usr/share/sgml/docbook/dsssl-stylesheets/dtds/dbdsssl/dbdsssl.dtd: ArcQuant CDATA #FIXED NAMELEN 64 /usr/share/sgml/docbook/dsssl-stylesheets/dtds/decls/docbook.dcl: NAMELEN44 /usr/share/sgml/docbook/sgml-dtd-3.1-1.0-50.fc13/docbook.dcl: NAMELEN 256 /usr/share/sgml/docbook/sgml-dtd-3.1-1.0-50.fc13/cals-tbl.dtd: NOTE: This set of declarations assumes a NAMELEN of 32 as is used in /usr/share/sgml/docbook/sgml-dtd-4.1-1.0-50.fc13/docbook.dcl: NAMELEN 256 /usr/share/sgml/docbook/sgml-dtd-4.1-1.0-50.fc13/cals-tbl.dtd: NOTE: This set of declarations assumes a NAMELEN of 32 as is used in /usr/share/sgml/docbook/sgml-dtd-4.2-1.0-50.fc13/docbook.dcl: NAMELEN 256 /usr/share/sgml/docbook/sgml-dtd-4.5-1.0-50.fc13/docbook.dcl: NAMELEN 256 /usr/share/sgml/docbook/dsssl-stylesheets-1.79/dtds/dbdsssl/dbdsssl.dtd: ArcQuant CDATA #FIXED NAMELEN 64 /usr/share/sgml/docbook/dsssl-stylesheets-1.79/dtds/decls/docbook.dcl: NAMELEN44 /usr/share/sgml/docbook/sgml-dtd-4.3-1.0-50.fc13/docbook.dcl: NAMELEN 256 /usr/share/sgml/docbook/sgml-dtd-4.0-1.0-50.fc13/docbook.dcl: NAMELEN 256 /usr/share/sgml/docbook/sgml-dtd-4.0-1.0-50.fc13/cals-tbl.dtd: NOTE: This set of declarations assumes a NAMELEN of 32 as is used in /usr/share/sgml/html.dcl: NAMELEN 72-- somewhat arbitrary; taken from It's hard to tell from this exactly which value is active in what contexts, but it does look like 44 is relevant in some. FWIW, I don't see the reported failure on this machine ... 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] Getting a bug tracker for the Postgres project
Hola Alvaro, On 05/31/2011 11:38 AM, Alvaro Herrera wrote: I think this would be easier if you crawled the monthly mboxen instead of the web archives. It'd be preferable to use message-ids to identify messages rather than year-and-month based URLs. I can capture the message-ids, as well as the message date, from crawling the web archives. If the tracker has some kind of web interface, I assume a link such as http://archives.postgresql.org/pgsql-bugs/2003-12/msg00046.php would be easier to follow than 20031205173035.ga16...@wolff.to unless the mboxes are stored in an easily accessible form by message-id (i.e., outside the web archives). Plus having the web link allows eventual tracking of messages outside of -bugs. Joe -- 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] Nested CASE-WHEN scoping
On 30.05.2011 17:21, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
I think we can work around both of those by just saving and restoring
the value of each Param that we set while evaluating an expression,
Huh? That's a waste of time and effort. Just make sure that each such
spot has its own Param number. That's why I'm telling you to do it in
the planner, not the parser --- it is easy to assign globally-unique-
across-the-plan numbers at plan time, in fact we do it already.
Yeah, I got that part. What I'm saying is that it's not that easy,
because of the two issues, domain constraints and index expressions,
that I mentioned. Here's a WIP patch, but those two issues have not been
addressed yet. I'm sure those are not insurmountable problems, I'm just
trying to figure out the best way to surmount them:
For domain constraints, ExecInitExpr could assign globally-unique param
numbers if it knew how many params are in use. That's trivial for
expressions in plans, as you have access to the EState via the
PlanState, and EState can include the number of params assigned. For a
stand-alone expression, we don't have that. There is no global
information whatsoever for stand-alone expressions, ExecInitExpr only
sees the current node it's dealing with. Perhaps we need to add the
concept of a global plan
For index expressions, we could use a function similar to
ChangeVarNodes(), that shifts all the paramids in the already-planned
expression, preparing it for inclusion within the enclosing plan. I'm a
bit worried that that might screw up the logic used to compare if an
expression matches the index expression, though; the param ids in the
two expressions won't match.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
*** a/src/backend/executor/execMain.c
--- b/src/backend/executor/execMain.c
***
*** 158,163 standard_ExecutorStart(QueryDesc *queryDesc, int eflags)
--- 158,164
*/
estate-es_param_list_info = queryDesc-params;
+ estate-es_num_param_exec_vals = queryDesc-plannedstmt-nParamExec;
if (queryDesc-plannedstmt-nParamExec 0)
estate-es_param_exec_vals = (ParamExecData *)
palloc0(queryDesc-plannedstmt-nParamExec * sizeof(ParamExecData));
***
*** 2179,2184 EvalPlanQualStart(EPQState *epqstate, EState *parentestate, Plan *planTree)
--- 2180,2186
{
int i = parentestate-es_plannedstmt-nParamExec;
+ estate-es_num_param_exec_vals = i;
estate-es_param_exec_vals = (ParamExecData *)
palloc0(i * sizeof(ParamExecData));
while (--i = 0)
*** a/src/backend/executor/execQual.c
--- b/src/backend/executor/execQual.c
***
*** 61,67
static Datum ExecEvalArrayRef(ArrayRefExprState *astate,
ExprContext *econtext,
bool *isNull, ExprDoneCond *isDone);
- static bool isAssignmentIndirectionExpr(ExprState *exprstate);
static Datum ExecEvalAggref(AggrefExprState *aggref,
ExprContext *econtext,
bool *isNull, ExprDoneCond *isDone);
--- 61,66
***
*** 78,83 static Datum ExecEvalWholeRowSlow(ExprState *exprstate, ExprContext *econtext,
--- 77,83
bool *isNull, ExprDoneCond *isDone);
static Datum ExecEvalConst(ExprState *exprstate, ExprContext *econtext,
bool *isNull, ExprDoneCond *isDone);
+ static void enlargeParamExecVals(ExprContext *econtext, int maxparamid);
static Datum ExecEvalParamExec(ExprState *exprstate, ExprContext *econtext,
bool *isNull, ExprDoneCond *isDone);
static Datum ExecEvalParamExtern(ExprState *exprstate, ExprContext *econtext,
***
*** 122,130 static Datum ExecEvalConvertRowtype(ConvertRowtypeExprState *cstate,
bool *isNull, ExprDoneCond *isDone);
static Datum ExecEvalCase(CaseExprState *caseExpr, ExprContext *econtext,
bool *isNull, ExprDoneCond *isDone);
- static Datum ExecEvalCaseTestExpr(ExprState *exprstate,
- ExprContext *econtext,
- bool *isNull, ExprDoneCond *isDone);
static Datum ExecEvalArray(ArrayExprState *astate,
ExprContext *econtext,
bool *isNull, ExprDoneCond *isDone);
--- 122,127
***
*** 352,394 ExecEvalArrayRef(ArrayRefExprState *astate,
if (isAssignment)
{
Datum sourceData;
! Datum save_datum;
! bool save_isNull;
/*
* We might have a nested-assignment situation, in which the
* refassgnexpr is itself a FieldStore or ArrayRef that needs to
* obtain and modify the previous value of the array element or slice
* being replaced. If so, we have to extract that value from the
! * array and pass it down via the econtext's caseValue. It's safe to
! * reuse the CASE mechanism because there cannot be a CASE between
! * here and where the value would be needed, and an array assignment
! * can't be within a CASE either. (So saving and restoring the
! * caseValue is just paranoia, but let's do it anyway.)
Re: [HACKERS] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Tue, May 31, 2011 at 10:02 AM, Tom Lane t...@sss.pgh.pa.us wrote: I kinda wonder why the CF app doesn't work like that, actually. (Yeah, I know the poor thread linking in the archives is an issue.) I thought this pretty much WAS how the CF app works, except that it's for patches rather than bugs. Perhaps it could be extended to also track bugs... Well, the point is you have to go and manually fool around with the web interface to enter something into CF, rather than just cc'ing it on your patch or review email. Oh, I see. Well, that could probably be changed. One thing to think about with the current system is that typically only the most relevant links get added, as opposed to the entire thread. Now, the bad news is that means things often don't get added at all. The good news is that typically when people do update it, the add only the relevant things, thus avoiding filling it up with a massive amount of crap. I don't know whether that works out to a bug or a feature. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] creating CHECK constraints as NOT VALID
On Tue, May 31, 2011 at 11:04 AM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: This patch allows you to initially declare a CHECK constraint as NOT VALID seems you forgot to add the patch itself -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- 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] Please test peer (socket ident) auth on *BSD
I wrote: BTW, after looking more closely at the buildfarm configure logs, it appears that both OpenBSD and NetBSD have getpeereid(), which means that they don't use this code at all. It is currently looking to me like the HAVE_STRUCT_FCRED and HAVE_STRUCT_SOCKCRED variants are dead code. Further research discloses that: 1. FreeBSD has has getpeereid() since 2001; their CVS logs show that it was implemented mostly for compatibility with OpenBSD, so OpenBSD has had it since even further back. 2. NetBSD implemented getpeereid() as of 5.0. 3. Mac OS X has had getpeereid() since 10.3 or thereabouts. This means that in fact the control-message variant of auth_peer is dead code on EVERY modern *BSD variant. So far as I can find, the only platform on which it is still used is Debian/kFreeBSD, that is Linux userland running on a FreeBSD kernel: glibc naturally lacks getpeereid, but the kernel doesn't have SO_PEERCRED, so you end up with the control message stuff. (This doubtless explains why the portability issues in the control-message code escaped notice for so long.) However, FreeBSD does have, and Debian/kFreeBSD does expose, getsockopt(LOCAL_PEERCRED), which turns out to be functionally equivalent to SO_PEERCRED: in particular, you can just call it and get the answer without having to fool with getting the far end to send a message. This is not only a whole lot cleaner than what we have, but also could be used to implement libpq's requirepeer option, which is currently unsupported on such platforms. So what I'm now thinking is we should rip out the control-message implementation altogether, and instead use LOCAL_PEERCRED. This is probably not something to back-patch, but it would make things a lot cleaner going forward. Comments? 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] Getting a bug tracker for the Postgres project
Joe Abbate j...@freedomcircle.com wrote: I assume a link such as http://archives.postgresql.org/pgsql-bugs/2003-12/msg00046.php would be easier to follow than 20031205173035.ga16...@wolff.to The point is that the community seems to have reached a consensus that they would rather use this URL for the above message: http://archives.postgresql.org/message-id/20031205173035.ga16...@wolff.to -Kevin -- 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] Getting a bug tracker for the Postgres project
Excerpts from Kevin Grittner's message of mar may 31 12:41:59 -0400 2011: Joe Abbate j...@freedomcircle.com wrote: I assume a link such as http://archives.postgresql.org/pgsql-bugs/2003-12/msg00046.php would be easier to follow than 20031205173035.ga16...@wolff.to The point is that the community seems to have reached a consensus that they would rather use this URL for the above message: http://archives.postgresql.org/message-id/20031205173035.ga16...@wolff.to Yeah, I keep dreaming that one day we will get rid of the silly monthly partitioning of archives. Those URLs will eventually be legacy -- existing ones will continue to work, but new messages will not (may not) get them any longer. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] creating CHECK constraints as NOT VALID
Excerpts from Alvaro Herrera's message of mar may 31 12:39:48 -0400 2011: Excerpts from Jaime Casanova's message of mar may 31 12:24:09 -0400 2011: On Tue, May 31, 2011 at 11:04 AM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: This patch allows you to initially declare a CHECK constraint as NOT VALID seems you forgot to add the patch itself oops ... another bug in my email client, it seems. Hmm, found an inconsistency in the way recursion is handled -- other commands have a AT_DoFooRecurse case. Weird. I'll change this to be like that, though I don't readily see why we do it that way. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] creating CHECK constraints as NOT VALID
Excerpts from Jaime Casanova's message of mar may 31 12:24:09 -0400 2011: On Tue, May 31, 2011 at 11:04 AM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: This patch allows you to initially declare a CHECK constraint as NOT VALID seems you forgot to add the patch itself oops ... another bug in my email client, it seems. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support 0001-Enable-CHECK-constraints-to-be-declared-NOT-VALID.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] [PATCH] Bug in XPATH() if expression returns a scalar value
On Tue, May 31, 2011 at 04:19:29PM +0200, Florian Pflug wrote: Sorry for the self-reply but I figured it'd be helpful to add information that I discovered only after my initial post. On May30, 2011, at 15:17 , Florian Pflug wrote: The XPath expression 'name(/*)', for example, is supposed to return 'root' when applied to the XML fragment 'rootnested/nested//root'. Postgres, however, currently returns an empty array. In the mean while, I've discovered that this was discussed previously about a year ago here: http://archives.postgresql.org/pgsql-general/2010-07/msg00355.php The basic confusion seems to be whether XPATH() is supposed to work on everything that http://www.w3.org/TR/xpath/ consideres to be an Expression, or only on what that document calls a Location Path. The difference is basically that Location Paths server purely as predicates, i.e. *select* a subset of nodes from an XML fragment, while Expressions can produce node sets *or* arbitrary scalar values (boolean, numeric or string). According to the thread from last summer, XLST handles this by defining *two* constructs which evaluate XPath expressions, one for those which return node sets (xsl:template match=...) and one for those which return scalar values (xsl:value-of select=...). My patch makes XPATH() work for both nodset-returning *and* scalar-value-returning expressions. This has the advantage of being simpler, but it does force the scalar values produced by an XPath expression to be valid XML fragments. For boolean and numeric values this isn't a problem, but it does limit what you can do with string-returning XPath expressions. If people deem this to be a problem, we could instead add a separate function XPATH_VALUE() that returns VARCHAR, and make people use that for scalar-value-returning expressions. However, to avoid confusion, XPATH() should then be taught to raise an error if used for scalar-value returning expressions, instead of silently returning an empty array as it does now. Thoughts, anyone? I think it's important to note here that the nodeset returning nature of XPATH in XSLT is a context setting functionality: these nodes are then further processed by the template. In the postgresql case, the distinction between returning a value and doing further processing isn't so clear. My one use-cases tend toward processing a table full of records with an XML field, using the XPATH to select out fragments and records ids into a secondary table for further processing/analysis. What you describe, making XPATH return something for the scalar functions, is sorely needed. Constraining the return values to be valid XML fragments is the sort of wart that makes XML processing in postgresql seem odd to those familiar with other tools, though. How about naming the other function XPATH_VALUE_OF, just to make it the XSLT connection clear? Ross -- Ross Reedstrom, Ph.D. reeds...@rice.edu Systems Engineer Admin, Research Scientistphone: 713-348-6166 Connexions http://cnx.orgfax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE -- 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] creating CHECK constraints as NOT VALID
On Tue, May 31, 2011 at 12:04 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: This patch allows you to initially declare a CHECK constraint as NOT VALID, similar to what we already allow for foreign keys. That is, you create the constraint without scanning the table and after it is committed, it is enforced for new rows; later, all rows are checked by running ALTER TABLE VALIDATE CONSTRAINT, which doesn't need AccessExclusive thus allowing for better concurrency. The trickiest bit here was realizing that unlike FKs, check constraints do inherit, and so needed special treatment for recursion. Other than that I think this was pretty straightforward. I intend to attempt to apply this to NOT NULL constraints as well, once the patch to add them to pg_constraint is in. Seems like a logical extension of what we have now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] Getting a bug tracker for the Postgres project
On 05/31/2011 01:12 AM, Peter Eisentraut wrote: On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote: I have used RT and I found that the web interface was both difficult to use and unwieldly for tickets containing large numbers of messages. Maybe those those things have been improved, but frankly if RT or Bugzilla is the best we can come up with then I'd rather not have a bug tracker at all. Given that you have been one of the people calling for a bug tracker, and these are the two most widely used systems available, what's wrong with them and what else would you suggest? Just FYI, CMD uses redmine and so far it is the best we have found. It isn't perfect certainly but overall it does a nice job. It supports email integration as well as plugins (we have even written a couple). Alvaro has also brought up the system that Debian uses which is actually email based versus web based. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development The PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579 -- 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] switch UNLOGGED to LOGGED
Well, I sort of assumed the design was OK, too, but the more we talk about this WAL-logging stuff, the less convinced I am that I really understand the problem. :-( I see. In fact, I think nobody thought about restart points... To sum up: 1) everything seems ok when in the wal_level = minimal case. In this case, we fsync everything and at transaction commit we remove the init fork; in case of a crash, we don't reply anything (as nothing has been written to the log), and we remove the main fork as we do now. 2) in the wal_level != minimal case things become more complicated: if the standby reaches a restart point and then crashes we are in trouble: it would remove the main fork at startup, and would reply only a portion of the table. I guess the same applies to the master too? I mean: if we log HEAP_XLOG_NEWPAGEs, reach a checkpoint, and then crash, at server restart the main fork would be deleted, and the pages logged on the log couldn't be replayed. But the problem on the master can be removed using another type of log instead of HEAP_XLOG_NEWPAGE (to be replayed by the standbys only). Is this analysis correct? Leonardo -- 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] creating CHECK constraints as NOT VALID
Alvaro Herrera alvhe...@alvh.no-ip.org wrote: This patch allows you to initially declare a CHECK constraint as NOT VALID, similar to what we already allow for foreign keys. That is, you create the constraint without scanning the table and after it is committed, it is enforced for new rows; later, all rows are checked by running ALTER TABLE VALIDATE CONSTRAINT, which doesn't need AccessExclusive thus allowing for better concurrency. I think it's a valuable feature, not just in terms of timing and concurrency, but in terms of someone starting with less-than-perfect data who wants to prevent further degradation while cleaning up the existing problems. This feature is present in other databases I've used. -Kevin -- 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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 19:10, Joe Abbate j...@freedomcircle.com wrote: On 05/31/2011 12:41 PM, Kevin Grittner wrote: The point is that the community seems to have reached a consensus that they would rather use this URL for the above message: http://archives.postgresql.org/message-id/20031205173035.ga16...@wolff.to OK, as I said, I can still capture the message-id's by crawling -bugs by year-month. Just to be clear, crawling the current archives for this info is probably the easiest part of the whole project. In fact, the majority of the information you'd need is *already* in a postgresql database on search.postgresql.org. So - let's start in the other end, and get back to this if/when it's needed. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Getting a bug tracker for the Postgres project
On tis, 2011-05-31 at 14:58 +0200, Magnus Hagander wrote: But sure, it can probably be improved. But what people are then basically asying is that tsearch isn't good enough for searching. For one thing, there should be more structured search possibilities, such as by date or author or subject only etc. Nothing that tsearch has anything to do with. -- 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] creating CHECK constraints as NOT VALID
Here it is -- as a context patch this time, as well. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support 0001-Enable-CHECK-constraints-to-be-declared-NOT-VALID.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] Getting a bug tracker for the Postgres project
On 05/31/2011 12:41 PM, Kevin Grittner wrote: The point is that the community seems to have reached a consensus that they would rather use this URL for the above message: http://archives.postgresql.org/message-id/20031205173035.ga16...@wolff.to OK, as I said, I can still capture the message-id's by crawling -bugs by year-month. Joe -- 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] creating CHECK constraints as NOT VALID
On Tue, May 31, 2011 at 11:35:01AM -0500, Kevin Grittner wrote: Alvaro Herrera alvhe...@alvh.no-ip.org wrote: This patch allows you to initially declare a CHECK constraint as NOT VALID, similar to what we already allow for foreign keys. That is, you create the constraint without scanning the table and after it is committed, it is enforced for new rows; later, all rows are checked by running ALTER TABLE VALIDATE CONSTRAINT, which doesn't need AccessExclusive thus allowing for better concurrency. I think it's a valuable feature, not just in terms of timing and concurrency, but in terms of someone starting with less-than-perfect data who wants to prevent further degradation while cleaning up the existing problems. This feature is present in other databases I've used. Yup, the ER triage approach to data integrity: Stop the major bleeding, we'll go back and make it a pretty scar later Follows from one of the practical maxims of databases: The data is always dirty Being able to have the constraints enforced at least for new data allows you to at least fence the bad data, and have a shot at fixing it all. Right now, you may be forced into running with constraints effectively 'off', depending on the app to get new data right, while attempting to catch up. And the app probably put the bad data in there in the first place. One of the thankless, important but seemingly never urgent tasks. Ross -- Ross Reedstrom, Ph.D. reeds...@rice.edu Systems Engineer Admin, Research Scientistphone: 713-348-6166 Connexions http://cnx.orgfax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE -- 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] Getting a bug tracker for the Postgres project
Excerpts from Joshua D. Drake's message of mar may 31 12:32:43 -0400 2011: Given that you have been one of the people calling for a bug tracker, and these are the two most widely used systems available, what's wrong with them and what else would you suggest? Just FYI, CMD uses redmine and so far it is the best we have found. It isn't perfect certainly but overall it does a nice job. It supports email integration as well as plugins (we have even written a couple). I certainly wouldn't suggest that Redmine wouldn't cause a change in workflow though. Alvaro has also brought up the system that Debian uses which is actually email based versus web based. Yeah, that's debbugs, which has been mentioned elsewhere in this thread. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Getting a bug tracker for the Postgres project
On 05/31/2011 01:13 PM, Magnus Hagander wrote: Just to be clear, crawling the current archives for this info is probably the easiest part of the whole project. In fact, the majority of the information you'd need is *already* in a postgresql database on search.postgresql.org. Does that database have the bug number, PG version and OS as separate columns, or is it simply an index over all the messages across all the lists? I think a table just of bug info would be useful at this time, e.g., to load a potential candidate. However, the message database --if it includes the message bodies-- would obviously be easier to work with than web crawling. Joe -- 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] Getting a bug tracker for the Postgres project
On Sun, May 29, 2011 at 4:05 PM, Tom Lane t...@sss.pgh.pa.us wrote: Peter Eisentraut pete...@gmx.net writes: That doesn't mean that better integration cannot be worked on later, but this illusion that a bug tracker must have magical total awareness of the entire flow of information in the project from day one is an illusion and has blocked this business for too long IMO. If it has only a partial view of the set of bugs being worked on, it's not going to meet the goals that are being claimed for it. I don't doubt that somebody could run around and link every discussion about a bug into the tracker. I'm just dubious that that actually *will* happen with enough reliability to make the tracker more useful than a mailing-list search. In the end, I think that requests for a tracker mostly come from people who are not part of this community, or at least not part of its mailing lists (which is about the same thing IMO). If they submitted a bug report via the lists, they're generally going to get replies via email, and that seems sufficient to me. But if they submitted a report via the web form, they might well be expecting that they can track what's going on with it on a web page. And that's not unreasonable. But we could fix that without any changes at all in our work processes. Just have the webform add a cc: bugbot-bugn...@postgresql.org to each submitted email, and set up a bot to collect the traffic and display it on a suitable web page. (Spam filtering left as an exercise for the reader.) The part of the discussion we've missed so far is that bug trackers are usually about the blame functionality and measurement of response times. We're a responsive and diligent community, so I see no problem here that wouldn't be solved simply by using better static URLs. -- 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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 19:59, Joe Abbate j...@freedomcircle.com wrote: On 05/31/2011 01:13 PM, Magnus Hagander wrote: Just to be clear, crawling the current archives for this info is probably the easiest part of the whole project. In fact, the majority of the information you'd need is *already* in a postgresql database on search.postgresql.org. Does that database have the bug number, PG version and OS as separate columns, or is it simply an index over all the messages across all the lists? I think a table just of bug info would be useful at this time, e.g., to load a potential candidate. However, the message database --if it includes the message bodies-- would obviously be easier to work with than web crawling. It does not have all those details, but it has the sender, subject and bodies broken out. So it's definitely an easier starting point. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Getting a bug tracker for the Postgres project
On 05/31/2011 11:05 AM, Alvaro Herrera wrote: Excerpts from Joshua D. Drake's message of mar may 31 12:32:43 -0400 2011: Given that you have been one of the people calling for a bug tracker, and these are the two most widely used systems available, what's wrong with them and what else would you suggest? Just FYI, CMD uses redmine and so far it is the best we have found. It isn't perfect certainly but overall it does a nice job. It supports email integration as well as plugins (we have even written a couple). I certainly wouldn't suggest that Redmine wouldn't cause a change in workflow though. Nor am I, I was mainly bringing it up as a (better) alternative to bugzilla and rt. Sincerely, Joshua D. Drake -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development The PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579 -- 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] Getting a bug tracker for the Postgres project
On Tue, May 31, 2011 at 19:37, Peter Eisentraut pete...@gmx.net wrote: On tis, 2011-05-31 at 14:58 +0200, Magnus Hagander wrote: But sure, it can probably be improved. But what people are then basically asying is that tsearch isn't good enough for searching. For one thing, there should be more structured search possibilities, such as by date or author or subject only etc. Nothing that tsearch has anything to do with. All those sound like things that should be easily doable on top of the current database. Care to create a wiki page with a suggested interface? (Unless oyu want to code up an actual patch for it :P) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Bug in XPATH() produces invalid XML values and probably un-restorable dumps
Hi
While trying to figure out sensible semantics for XPATH() and scalar-value
returning XPath expressions, I've stumbled upon a bug in XPATH() that allows
invalid XML values to be produced. This is a serious problem because should
such invalid values get inserted into an XML column, an un-restorable dump
ensues.
Here's an example (REL9_0_STABLE as of a few days ago)
template1=# SELECT (XPATH('/*/text()', 'rootlt;/root'))[1];
xpath
---
Since XPATH() returns XML[], this value has type XML, but clearly isn't
well-formed. And behold, casting to TEXT and back to XML complains loudly.
template1=# SELECT (XPATH('/*/text()', 'rootlt;/root'))[1]::TEXT::XML;
ERROR: invalid XML content
DETAIL: Entity: line 1: parser error : StartTag: invalid element name
^
The culprit is xml_xmlnodetoxmltype() in backend/utils/adt/xml.c. For
non-element nodes, it returns the result of xmlXPathCastNodeToString()
verbatim, even though that function doesn't reverse the entity replacement that
was done during parsing. Adding a call to escape_xml()
for non-element nodes fixes the problem
template1=# SELECT (XPATH('/*/text()', 'rootlt;/root'))[1];
xpath
---
lt;
Patch is attached.
best regards,
Florian Pflug
pg_xpath_invalidxml.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] Getting a bug tracker for the Postgres project
2011/5/31 Alvaro Herrera alvhe...@commandprompt.com: Excerpts from Joshua D. Drake's message of mar may 31 12:32:43 -0400 2011: Alvaro has also brought up the system that Debian uses which is actually email based versus web based. Yeah, that's debbugs, which has been mentioned elsewhere in this thread. I like this one, does it have something we don't like ? it is mail oriented, have a web-interface, a search engine. It is easy to merge bugs etc... The other alternative more individual is a sieve script to filter and manage -bugs and -commiters maybe -hackers (not done, but that might not be so hard) -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- 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] Bug in XPATH() if expression returns a scalar value
On May31, 2011, at 19:15 , Ross J. Reedstrom wrote:
What you describe, making XPATH return something for the scalar
functions, is sorely needed. Constraining the return values to be valid
XML fragments is the sort of wart that makes XML processing in
postgresql seem odd to those familiar with other tools, though.
I've now changes things so that the results of scalar-value
returning XPath expressions are correctly entity-encoded (i.e.,
a literal gets translated to lt;).
After realizing that this is necessary even for node-set
returning XPath expressions (see my other mail from today),
because they may very well select text nodes, I came to the
conclusion that doing this unconditionally (well, except for
element nodes obviously) is the least surprising behaviour.
The following subsumes the behavior with this and the patch
from my other e-mail applied.
SELECT
(XPATH('namespace-uri(/*)', x))[1] AS namespace,
(XPATH('/*/@value', x))[1] AS value,
(XPATH('/*/text()', x))[1] AS text
FROM (VALUES (XMLELEMENT(name root,
XMLATTRIBUTES('n' AS xmlns, 'v' AS value),
't'
))) v(x);
namespace | value | text
---+---+---
lt;n | lt;v | lt;t
Without the patch from the other mail, the namespace result
stays the same, but value and text are v and t
respectively.
Updated patch is attached
best regards,
Florian Pflug
PS: Btw, while trying this I think I found another problem. If you
do
SELECT (XPATH(
'/*',
XMLELEMENT(NAME root,
XMLATTRIBUTES('n' AS xmlns,
'v' AS value))
))[1];
you get
xpath
--
root xmlns=n value=lt;v/
i.e. the in the namespace URI isn't quoted properly.
Trying to cast that value to text and back to xml fails.
Funnily enough, if you skip the XPATH() call, things work properly
SELECT XMLELEMENT(NAME root,
XMLATTRIBUTES('n' AS xmlns,
'v' AS value))
gives
xmlelement
-
root xmlns=lt;n value=lt;v/
I'll start a new thread for this issue...
pg_xpath_returnvalue.v2.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] Please test peer (socket ident) auth on *BSD
On tis, 2011-05-31 at 11:59 -0400, Tom Lane wrote: However, FreeBSD does have, and Debian/kFreeBSD does expose, getsockopt(LOCAL_PEERCRED), which turns out to be functionally equivalent to SO_PEERCRED: in particular, you can just call it and get the answer without having to fool with getting the far end to send a message. This is not only a whole lot cleaner than what we have, but also could be used to implement libpq's requirepeer option, which is currently unsupported on such platforms. So what I'm now thinking is we should rip out the control-message implementation altogether, and instead use LOCAL_PEERCRED. This is probably not something to back-patch, but it would make things a lot cleaner going forward. Oh yes, no point in having complicated code that doesn't get exercised. -- 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] creating CHECK constraints as NOT VALID
Excerpts from Ross J. Reedstrom's message of mar may 31 14:02:04 -0400 2011: Follows from one of the practical maxims of databases: The data is always dirty Being able to have the constraints enforced at least for new data allows you to at least fence the bad data, and have a shot at fixing it all. Right now, you may be forced into running with constraints effectively 'off', depending on the app to get new data right, while attempting to catch up. And the app probably put the bad data in there in the first place. One of the thankless, important but seemingly never urgent tasks. Interesting point of view. I have to admit that I didn't realize I was allowing that, even though I have wished for it in the past myself. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Getting a bug tracker for the Postgres project
Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Kevin Grittner's message of mar may 31 12:41:59 -0400 2011: The point is that the community seems to have reached a consensus that they would rather use this URL for the above message: http://archives.postgresql.org/message-id/20031205173035.ga16...@wolff.to Yeah, I keep dreaming that one day we will get rid of the silly monthly partitioning of archives. Those URLs will eventually be legacy -- existing ones will continue to work, but new messages will not (may not) get them any longer. Check out the following POC, which needs to get migrated into a django application for the upcoming new infrastructure: http://archives.beccati.org/ It uses AOX (http://aox.org/) and as such is baked by a PostgreSQL database. The mails threading view is even a CTE. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [DOCS] [HACKERS] DOCS: SGML identifier may not exceed 44 characters
On tis, 2011-05-31 at 12:13 -0400, Tom Lane wrote: Christopher Browne cbbro...@gmail.com writes: On Tue, May 31, 2011 at 3:22 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Brendan Jurd's message of mar may 31 02:17:22 -0400 2011: openjade:information_schema.sgml:828:60:Q: length of name token must not exceed NAMELEN (44) Odd. I tried it here and it doesn't fail -- same openjade version. Maybe mine is patched. It's not likely an issue of how OpenJade was compiled; there has been a limitation in how SGML parsing was configured. If you poke around in /usr/share/sgml, you should find some configuration indicating NAMELEN was set to 44. On a Fedora 13 machine: $ grep -r NAMELEN /usr/share/sgml/ /usr/share/sgml/openjade-1.3.2/style-sheet.dtd: ArcQuant CDATA #FIXED NAMELEN 64 /usr/share/sgml/docbook/sgml-dtd-3.0-1.0-50.fc13/docbook.dcl: NAMELEN256 /usr/share/sgml/docbook/sgml-dtd-3.0-1.0-50.fc13/cals-tbl.dtd: NOTE: This set of declarations assumes a NAMELEN of 32 as is used in /usr/share/sgml/docbook/sgml-dtd-4.4-1.0-50.fc13/docbook.dcl: NAMELEN256 /usr/share/sgml/docbook/dsssl-stylesheets/dtds/dbdsssl/dbdsssl.dtd: ArcQuant CDATA #FIXED NAMELEN 64 /usr/share/sgml/docbook/dsssl-stylesheets/dtds/decls/docbook.dcl: NAMELEN44 /usr/share/sgml/docbook/sgml-dtd-3.1-1.0-50.fc13/docbook.dcl: NAMELEN256 /usr/share/sgml/docbook/sgml-dtd-3.1-1.0-50.fc13/cals-tbl.dtd: NOTE: This set of declarations assumes a NAMELEN of 32 as is used in /usr/share/sgml/docbook/sgml-dtd-4.1-1.0-50.fc13/docbook.dcl: NAMELEN256 /usr/share/sgml/docbook/sgml-dtd-4.1-1.0-50.fc13/cals-tbl.dtd: NOTE: This set of declarations assumes a NAMELEN of 32 as is used in /usr/share/sgml/docbook/sgml-dtd-4.2-1.0-50.fc13/docbook.dcl: NAMELEN256 /usr/share/sgml/docbook/sgml-dtd-4.5-1.0-50.fc13/docbook.dcl: NAMELEN256 /usr/share/sgml/docbook/dsssl-stylesheets-1.79/dtds/dbdsssl/dbdsssl.dtd: ArcQuant CDATA #FIXED NAMELEN 64 /usr/share/sgml/docbook/dsssl-stylesheets-1.79/dtds/decls/docbook.dcl: NAMELEN44 /usr/share/sgml/docbook/sgml-dtd-4.3-1.0-50.fc13/docbook.dcl: NAMELEN256 /usr/share/sgml/docbook/sgml-dtd-4.0-1.0-50.fc13/docbook.dcl: NAMELEN256 /usr/share/sgml/docbook/sgml-dtd-4.0-1.0-50.fc13/cals-tbl.dtd: NOTE: This set of declarations assumes a NAMELEN of 32 as is used in /usr/share/sgml/html.dcl: NAMELEN 72-- somewhat arbitrary; taken from It's hard to tell from this exactly which value is active in what contexts, but it does look like 44 is relevant in some. FWIW, I don't see the reported failure on this machine ... It looks like the original DocBook distribution has a limit of 44, but someone patched it to 256 on your installation. But it seems like no one else has seen this problem yet, so it's quite suspicious, since surely people have built the documentation in the last few months. -- 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] Please test peer (socket ident) auth on *BSD
On Tue, May 31, 2011 at 12:38 PM, Peter Eisentraut pete...@gmx.net wrote: So what I'm now thinking is we should rip out the control-message implementation altogether, and instead use LOCAL_PEERCRED. This is probably not something to back-patch, but it would make things a lot cleaner going forward. Oh yes, no point in having complicated code that doesn't get exercised. This does amount to desupporting old versions of those OSes in newer versions of Postgres, at least for this one feature. Since you're saying you don't want to backport it that doesn't seem like a big deal to me. Probably something worth mentioning in release notes 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] Getting a bug tracker for the Postgres project
All, Let me mention some of the reasons we as a project could use a bug tracker which have nothing to do with actually fixing bugs. (1) Testing: a bug tracker could be used for beta testing instead of the ad-hoc system I'm writing. Assuming it has the right features, of course. (2) User information: right now, if a user has an issue, it's very very hard for them to answer the question Has this already been reported and/or fixed in a later release. This is a strong source of frustration for business users who don't actively participate in the community, a complaint I have heard multiple times. (3) Lack of a bug tracker with a web services API prevents downstream projects (PostGIS, RHEL, Ubuntu, Django, Drupal, etc.) from linking in PostgreSQL bug reports which affect their users. Also, because these projects are used to bug trackers, they get confused when they need to report a bug to us. (4) Because having a bug tracker is seen as standard and mainstream among OSS projects, the fact that we don't have one is regarded as oddball and backwards, and does result in some companies choosing not to use PostgreSQL because we're perceived as too weird and anti-commercial. Where *fixing* bugs is concerned, I'm concerned that a bug tracker would actually slow things down. I'm dubious about our ability to mobilize volunteers for anything other than bug triage, and the fact that we *don't* triage is an advantage in bug report responsiveness (I have unconfirmed bugs for Thunderbird which have been pending for 3 years). So I'm skeptical about bug trackers on that score. However, for the four non-fixing items, having some kind of bug tracker would be a real asset to the project. I'm just not sure what kind of bug tracker that would be. BTW, we talked to Debian about debbugs ages ago, and the Debian project said that far too much of debbugs was not portable to other projects. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.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: [DOCS] [HACKERS] DOCS: SGML identifier may not exceed 44 characters
On 05/31/2011 04:36 PM, Peter Eisentraut wrote: But it seems like no one else has seen this problem yet, so it's quite suspicious, since surely people have built the documentation in the last few months. I have two buildfarm members with stock openjade/docbook installations building the docs every day. 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] Please test peer (socket ident) auth on *BSD
Greg Stark gsst...@mit.edu writes: On Tue, May 31, 2011 at 12:38 PM, Peter Eisentraut pete...@gmx.net wrote: Oh yes, no point in having complicated code that doesn't get exercised. This does amount to desupporting old versions of those OSes in newer versions of Postgres, at least for this one feature. Since you're saying you don't want to backport it that doesn't seem like a big deal to me. Probably something worth mentioning in release notes though. Yeah, possibly. So far as I can tell, both FreeBSD and OpenBSD have had getpeereid for so long that it couldn't be an issue. I guess there might still be some people running pre-5.0 versions of NetBSD though. (BTW, in both FreeBSD and NetBSD, it turns out that getpeereid is just a thin wrapper around SO_PEERCRED-equivalent getsockopt calls. However, there doesn't seem to be any point in supporting NetBSD's getsockopt call directly, because it was added at the same time as the getpeereid function. Unless maybe there's a kFreeBSD-like project out there with NetBSD as the kernel?) 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] patch review : Add ability to constrain backend temporary file space
Hello here is a partial review of your patch, better than keeping it sleeping in the commitfest queue I hope. Submission review * The patch is not in context diff format. * The patch apply, but contains some extra whitespace. * Documentation is here but not explicit about 'temp tables', maybe worth adding that this won't limit temporary table size ? * There is no test provided. One can be expected to check that the feature work. Code review = * in fd.c, I think that temporary_files_size -= (double)vfdP-fileSize; should be done later in the function once we have successfully unlink the file, not before. * I am not sure it is better to add a fileSize like you did or use relationgetnumberofblock() when file is about to be truncated or unlinked, this way the seekPos should be enough to increase the global counter. * temporary_files_size, I think it is better to have a number of pages à la postgresql than a kilobyte size * max_temp_files_size, I'll prefer an approach like shared_buffers GUC: you can use pages, or KB, MB, ... Simple Feature test == either explain buffers is wrong or the patch is wrong: cedric=# explain (analyze,buffers) select * from foo order by 1 desc ; QUERY PLAN - Sort (cost=10260.02..10495.82 rows=94320 width=4) (actual time=364.373..518.940 rows=10 loops=1) Sort Key: generate_series Sort Method: external merge Disk: 1352kB Buffers: local hit=393, temp read=249 written=249 - Seq Scan on foo (cost=0.00..1336.20 rows=94320 width=4) (actual time=0.025..138.754 rows=10 loops=1) Buffers: local hit=393 Total runtime: 642.874 ms (7 rows) cedric=# set max_temp_files_size to 1900; SET cedric=# explain (analyze,buffers) select * from foo order by 1 desc ; ERROR: aborting due to exceeding max temp files size STATEMENT: explain (analyze,buffers) select * from foo order by 1 desc ; ERROR: aborting due to exceeding max temp files size Do you have some testing method I can apply to track that without explain (analyze, buffers) before going to low-level monitoring ? Architecture review == max_temp_files_size is used for the global space used per backend. Based on how work_mem work I expect something like work_disk to limit per file and maybe a backend_work_disk (and yes maybe a backend_work_mem ?!) per backend. So I propose to rename the current GUC to something like backend_work_disk. Patch is not large and easy to read. I like the idea and it sounds useful. -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- 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] Getting a bug tracker for the Postgres project
Excerpts from Dimitri Fontaine's message of mar may 31 16:11:35 -0400 2011: Check out the following POC, which needs to get migrated into a django application for the upcoming new infrastructure: http://archives.beccati.org/ It uses AOX (http://aox.org/) and as such is baked by a PostgreSQL database. The mails threading view is even a CTE. Yeah, it's great. Last time I heard, though, Mateo wasn't open to doing any more work on it (including fixing a bunch of bugs we found) until the web migration to the Django stuff materialized. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 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] Retrieving variable names from ids in pl_exec.c
Hello, Is there any way to retrieve the actual variable names (as were given during Stored Procedure definition) for the corresponding var_ids in pl/plpgsql/src/pl_exec.c ? I have modified some PostgreSQL code for my own project and I track some information for functions during their execution. It would be much more clear at the end if I could map variable ids to their actual names. Thanks in advance -- 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] Getting a bug tracker for the Postgres project
Excerpts from Josh Berkus's message of mar may 31 17:05:23 -0400 2011: BTW, we talked to Debian about debbugs ages ago, and the Debian project said that far too much of debbugs was not portable to other projects. The good news is that the GNU folk proved them wrong, as evidenced elsewhere in the thread. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Getting a bug tracker for the Postgres project
2011/5/31 Josh Berkus j...@agliodbs.com: All, Let me mention some of the reasons we as a project could use a bug tracker which have nothing to do with actually fixing bugs. (1) Testing: a bug tracker could be used for beta testing instead of the ad-hoc system I'm writing. Assuming it has the right features, of course. (2) User information: right now, if a user has an issue, it's very very hard for them to answer the question Has this already been reported and/or fixed in a later release. This is a strong source of frustration for business users who don't actively participate in the community, a complaint I have heard multiple times. (3) Lack of a bug tracker with a web services API prevents downstream projects (PostGIS, RHEL, Ubuntu, Django, Drupal, etc.) from linking in PostgreSQL bug reports which affect their users. Also, because these projects are used to bug trackers, they get confused when they need to report a bug to us. (4) Because having a bug tracker is seen as standard and mainstream among OSS projects, the fact that we don't have one is regarded as oddball and backwards, and does result in some companies choosing not to use PostgreSQL because we're perceived as too weird and anti-commercial. Where *fixing* bugs is concerned, I'm concerned that a bug tracker would actually slow things down. I'm dubious about our ability to mobilize volunteers for anything other than bug triage, and the fact that we *don't* triage is an advantage in bug report responsiveness (I have unconfirmed bugs for Thunderbird which have been pending for 3 years). So I'm skeptical about bug trackers on that score. However, for the four non-fixing items, having some kind of bug tracker would be a real asset to the project. I'm just not sure what kind of bug tracker that would be. BTW, we talked to Debian about debbugs ages ago, and the Debian project said that far too much of debbugs was not portable to other projects. GNU succeed to use it, it seems: http://debbugs.gnu.org/Using.html http://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;max-bugs=100;base-order=1;bug-rev=1 -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- 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] Please test peer (socket ident) auth on *BSD
On Wed, Jun 1, 2011 at 12:22 AM, Tom Lane t...@sss.pgh.pa.us wrote: Greg Stark gsst...@mit.edu writes: On Tue, May 31, 2011 at 12:38 PM, Peter Eisentraut pete...@gmx.net wrote: Oh yes, no point in having complicated code that doesn't get exercised. This does amount to desupporting old versions of those OSes in newer versions of Postgres, at least for this one feature. Since you're saying you don't want to backport it that doesn't seem like a big deal to me. Probably something worth mentioning in release notes though. Yeah, possibly. So far as I can tell, both FreeBSD and OpenBSD have had getpeereid for so long that it couldn't be an issue. I guess there might still be some people running pre-5.0 versions of NetBSD though. (BTW, in both FreeBSD and NetBSD, it turns out that getpeereid is just a thin wrapper around SO_PEERCRED-equivalent getsockopt calls. However, there doesn't seem to be any point in supporting NetBSD's getsockopt call directly, because it was added at the same time as the getpeereid function. Unless maybe there's a kFreeBSD-like project out there with NetBSD as the kernel?) My suggestion would be to use getpeereid() everywhere. And just have compat getpeereid() implementation on non-BSD platforms. This would minimize ifdeffery in core core. -- marko -- 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] Please test peer (socket ident) auth on *BSD
Marko Kreen mark...@gmail.com writes: My suggestion would be to use getpeereid() everywhere. And just have compat getpeereid() implementation on non-BSD platforms. This would minimize ifdeffery in core core. Hm, maybe. I'd be for this if we had more than two call sites, but as things stand I'm not sure it's worth the trouble to set up a src/port module for it. 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] Please test peer (socket ident) auth on *BSD
2011/5/31, Tom Lane t...@sss.pgh.pa.us: Unless maybe there's a kFreeBSD-like project out there with NetBSD as the kernel?) There used to be an attempt by Debian (called GNU/NetBSD), but that has since long been abandoned. I don't know of any other similar projects. URL:http://www.debian.org/ports/netbsd/ Wikipedia doesn't list any other similar projects either: URL:http://en.wikipedia.org/wiki/GNU_variants#BSD_variants Nicolas -- A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
