Re: [HACKERS] Creating a tablespace directory in recovery
On Thu, Apr 30, 2009 at 3:58 AM, Fujii Masao wrote: > Does anyone know why a tablespace directory isn't automatically > created in recovery? I think that it's troublesome to create all the > directories before recovery. Well, there's some chance that if the directories don't exist, it's because you haven't troubled to mount the correct partitions. And in that case just blindly creating the directories will possibly lead to a series of unfortunate events. I generally think that it's not a good idea for PG to create directories outside $PGDATA. I didn't much like the recent change where (AIUI) we follow the symlink and create a directory in the right place to be the target thereof. Those kinds of things strike me as footguns waiting to go off. If something is not right, I would rather have the system complain to me and stop than just do something that might not be right. It's easier to fix my init scripts if PG is too dumb than to work around PG trying to be too smart. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Restore deleted rows
On Wednesday 29 April 2009 14:03:14 Dimitri Fontaine wrote:
> Hi,
>
> On Tuesday 28 April 2009 20:43:38 Robert Treat wrote:
> > We had started down the path of making a function to read deleted tuples
> > from a table for a DR scenario we were involved with once. The idea was
> > that you could do something like select * from
> > viewdeletedpages('tablename') t (table type), which would allow you to
> > see the dead rows. It ended up unnessesary, so we never finished it, but
> > I still think the utility of such a function would be high... for most
> > people, if you told them that they could do create table as select * from
> > viewdeletedttuples(...) t(...) after doing a mis-placed delete/update, at
> > the cost of having to sift through extra data, they would make that trade
> > in a heartbeat.
>
> There has been another idea proposed to solve this problem:
> http://archives.postgresql.org/pgsql-hackers/2009-02/msg00117.php
>
> The idea is to have VACUUM not discard the no more visible tuples but store
> them on a specific fork (which you'll want to have on a WORM (cheap)
> tablespace, separate issue).
Sounds similar to Oracle's undo logs.
> Then you want to be able to associate the tuple xid info with a timestamptz
> clock, which could be done thanks to txid and txid_snapshot by means of a
> ticker daemon. PGQ from Skytools has such a daemon, a C version is being
> prepared for the 3.0 release (alpha1 released).
>
> Hannu said:
> >Reintroducing keeping old tuples "forever" would also allow us to bring
> >back time travel feature, that is
> >
> >SELECT AS OF 'yesterday afternoon'::timestamp;
>
> It could be that there's a simpler way to implement the feature than
> provide a ticker daemon (one more postmaster child), but the linked thread
> show some other use cases of an integrated ticker. I know we use PGQ alone
> here to obtain reliable batches as presented at Prato:
> http://wiki.postgresql.org/wiki/Image:Prato_2008_pgq_batches.pdf
>
Interesting.
Something like flashback queries would certaily be nice, and it's interesting
that we have most of the machinery to do this stuff already, we just need to
spruce it up a little.
--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] UHC as a server encoding?
Why are certain character encodings not legal for the server_encoding? For example, we allow EUC_KR, but disallow UHC, which is a superset of EUC_KR. What are the rules for what is or is not allowed as server_encoding? Is it having a conversion to MIC that is the issue? Why is that important for server encodings? -- 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] idea: global temp tables
2009/4/29 Tom Lane :
> Greg Stark writes:
>> Well I claim it's not just a nice bonus but is the difference between
>> implementing something which falls technically within the standard's
>> rules but fails to actually be useful for the standard's intended
>> purpose.
>
> I agree with Kevin's objection that you are unfairly raising the bar
> for this feature by demanding a performance improvement to go along
> with a functionality change. The use-case for this feature is to
> simplify application logic by allowing apps to assume that a temp
> table exists without having to create it at the start of a session.
> That's particularly handy in connection-pooling scenarios, for instance.
> Currently, you have to have some sort of "if exists" check, and you
> pay just as much in catalog thrashing as you would if the feature
> was present without any catalog optimization.
>
exactly
> It would be great to find a way to avoid the catalog thrashing,
> but I completely disagree with a point of view that says we can't
> have this without solving that first. It's an improvement on the
> current state of affairs anyway.
>
>> I've been thinking about Alvaro's idea of a separate smgr. If you had
>> a single pg_class entry for all sessions but the smgr knew to store
>> the actual data for it in a session-local file, either in a
>> session-specific tablespace or using the same mechanism the temporary
>> files use to direct data then the backend would basically never know
>> it wasn't a regular table.
>
> 1. pg_statistic.
>
> 2. How you going to have transaction-safe behavior for things like
> TRUNCATE, if you don't have an updatable private catalog entry to keep
> the current relfilenode in?
>
>> It could still use local buffers but it could use the global relcache,
>> invalidation, locks, etc.
>
> Locks would be another big problem: if only smgr knows that different
> instances of the table are different, then different backends' locks
> would conflict, which would be Bad. This might not matter for simple
> read/update, but again TRUNCATE is a counterexample of something that
> is likely to be needed and should not cause cross-backend conflicts.
I though about some techniques for elimination changes in pg_class and
pg_statistic. Teoreticly, we could to overwrite some columns (or
complete rows) from these tables via stored values in memory. My last
(and not sucessfull) prototype was based on some alchymy over
syscache. It was wrong way.
Maybe we could do some like
int get_relpages(oid)
{
tuple = read_tuple_pg_class(oid);
if is_global(tuple)
{
tuple2 = find_global(oid);
if (tuple2 == NULL)
{
store_global(tuple);
return relpages(tuple);
}
else
return relpages(tuple2);
}
else
return relpages(tuple);
}
But question?
about MVCC?
Is necessary to use MVCC on pg_statistic and some columns from pg_proc?
regards
Pavel Stehule
>
> 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] Documentation: GiST extension implementation
Hi, The following documentation page explains the GiST API to extensions authors: http://www.postgresql.org/docs/current/static/gist-implementation.htm I think we should be a little more verbose, and at least explains some more the big picture: same/consistent/union are responsible for correctness of the index while penalty and picksplit are responsible for performances of it, which leaves compress/decompress, to use when leaf/nodes are not the same datatype. This leaf/node construct is explained in the last paragraph of following page, but can exists directly into the C module too: http://www.postgresql.org/docs/current/static/xindex.html The consistent and union should get a lot of attention, and when exactly do your operators need RECHECK is still unclear to me. It's hard to give precise advices about consistent/union in a generic way, but I've been given the following general rule (thanks RhodiumToad): (z is consistent with x) implies (z is consistent with union(x,y)) What's unclear too is memory management: when to palloc() and when to reuse arguments given by -core GiST support functions. I know it was a game of trial and error to get it right, and while I know it's working now, I'd be in a bad position to explain how and why. Maybe reading the source code is what to do here, but a detailed API expectancies page in the documentation wouldn't hurt... Regards, -- dim I didn't propose a real doc patch mainly because english isn't my native language, and while you'll have to reword the content... signature.asc Description: This is a digitally signed message part.
Re: [HACKERS] idea: global temp tables
Greg Stark wrote: > On Wed, Apr 29, 2009 at 6:42 PM, Tom Lane wrote: >> I agree with Kevin's objection that you are unfairly raising the >> bar for this feature by demanding a performance improvement to go >> along with a functionality change. > > I think having the feature is making a promise that we can't keep. > Having a feature which meets the letter of the rules but fails to > actually work as users have a right to expect is going to trap > people unaware that they're writing code that works in testing but > will never scale. But the scaling issues are there already with temp tables. This actually makes it better, not worse, because the table can be materialized once per session, not once per request. >> The use-case for this feature is to >> simplify application logic by allowing apps to assume that a temp >> table exists without having to create it at the start of a session. >> That's particularly handy in connection-pooling scenarios, for >> instance. Currently, you have to have some sort of "if exists" >> check, and you pay just as much in catalog thrashing as you would >> if the feature was present without any catalog optimization. > > That seems like a trivial little annoyance. And a potentially large performance booster. >> It would be great to find a way to avoid the catalog thrashing, >> but I completely disagree with a point of view that says we can't >> have this without solving that first. It's an improvement on the >> current state of affairs anyway. > > Not if it promises something we can't deliver. My claim is that the > whole point of having a persistent catalog definition is *precisely* > to avoid the catalog thrashing and that's obvious to users who would > be using this feature. I've re-read the spec on this several times now, and I can't see where that is implied. > I still maintain that this feature is not primarily about programmer > convenience, but rather comes with an expectation that the schema > definition is being given in advance so that the database doesn't > have to incur the costs of issuing the ddl for every session. I think many would be satisfied not to have those costs on every *request* on the connection. -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] idea: global temp tables
Greg Stark wrote: >> creating/deleting a few dozen rows in the system catalogs shouldn't >> really be something that autovacuum can't deal with. > > I don't see why it's limited to a few dozen rows. Moderately busy > web sites these days count their traffic in hundreds of page views > per second. Sure. We're there. And many of those hits run ten to twenty queries. We'd be insane to get a new connection for each one rather than use a connection pool; and this overhead only occurs once per referenced table per connection. -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] Creating a tablespace directory in recovery
On Thu, Apr 30, 2009 at 2:58 AM, Fujii Masao wrote: > Hi, > > Does anyone know why a tablespace directory isn't automatically > created in recovery? I think that it's troublesome to create all the > directories before recovery. > i guess it's because you need an absolute path to create tablespaces and the appropiate path could not exist in the other machine (assuming you are using recovery for warm standby or because you are recreating a database after reinstall your server). don't know if there are better reasons... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- 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] Keyword list sanity check
On Apr 30, 2009, at 2:11 PM, David Fetter wrote: Here's a patch that gets it to pass perlcritic -4 and still (as far as I can tell) work. Tell ya what. Let me at it and I'll give a larger, more inclusive patch. xoxo, Andy -- Andy Lester => a...@petdance.com => www.theworkinggeek.com => AIM:petdance -- 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] Keyword list sanity check
On Tue, Apr 28, 2009 at 10:33 AM, Heikki Linnakangas wrote: > I wrote a little perl script to perform a basic sanity check to keywords in > gram.y and kwlist.h. It checks that all lists are in alphabetical order, all > keywords present in gram.y are listed in kwlist.h in the right category, and > conversely that all keywords listed in kwlist.h are listed in gram.y. Friendly greetings ! Here is a new version of check_keywords.pl : - perl -w and "use strict" enabled (and all the fixes that come with it) - minor cleaning -- Laurent Laborde Sysadmin at jfg://networks http://www.over-blog.com/ check_keywords.pl Description: Perl program -- 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] idea: global temp tables
Kevin Grittner wrote: contexts. I don't think the updates to the system tables have the same magnitude of performance hit as creating these tables, especially if write barriers are on. Wouldn't it be cleaner just to defer creation of real files to support the structures associated with a temp table until it i snecessary to spill the data from the backend's RAM? This data doesn't need to be in shared memory and the tables and data aren't visible to any other session, so can't they run out of RAM most of the time (or all the time if the data in them is short lived)? -- 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] Keyword list sanity check
On Thu, Apr 30, 2009 at 09:40:50AM -0700, David Fetter wrote:
> On Thu, Apr 30, 2009 at 11:39:33AM -0500, Andy Lester wrote:
> >
> > On Apr 30, 2009, at 6:41 AM, Robert Haas wrote:
> >
> >>> Please clean up this code at least to the point where it's
> >>> strict-clean, which means putting "use strict;" right after the
> >>> shebang line and not checking it in until it runs that way.
> >>
> >> And "use warnings;", too.
> >
> >
> > I'll prob'ly come up with a policy file for Perl::Critic and a make
> > target for perlcritic.
>
> The current code has a bunch of 5s in it, so it's a target-rich
> environment :)
Here's a patch that gets it to pass perlcritic -4 and still (as far as
I can tell) work.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
diff --git a/src/tools/check_keywords.pl b/src/tools/check_keywords.pl
index 8d0d962..a5a01d2 100755
--- a/src/tools/check_keywords.pl
+++ b/src/tools/check_keywords.pl
@@ -1,111 +1,109 @@
-#!/usr/bin/perl -w
+#!/usr/bin/perl
use strict;
+use warnings;
+use diagnostics;
+use Carp;
# Check that the keyword lists in gram.y and kwlist.h are sane. Run from
# the top directory, or pass a path to a top directory as argument.
#
# $PostgreSQL$
-my $path;
+local $, = ' ';# set output field separator
+local $\ = "\n";# set output record separator
-if (@ARGV) {
- $path = $ARGV[0];
- shift @ARGV;
-} else {
- $path = ".";
-}
-
-$[ = 1;# set array base to 1
-$, = ' '; # set output field separator
-$\ = "\n"; # set output record separator
+my $path = $ARGV[0] || '.';
-my %keyword_categories;
-$keyword_categories{'unreserved_keyword'} = 'UNRESERVED_KEYWORD';
-$keyword_categories{'col_name_keyword'} = 'COL_NAME_KEYWORD';
-$keyword_categories{'type_func_name_keyword'} = 'TYPE_FUNC_NAME_KEYWORD';
-$keyword_categories{'reserved_keyword'} = 'RESERVED_KEYWORD';
+my %keyword_categories = (
+unreserved_keyword => 'UNRESERVED_KEYWORD',
+col_name_keyword => 'COL_NAME_KEYWORD',
+type_func_name_keyword => 'TYPE_FUNC_NAME_KEYWORD',
+reserved_keyword => 'RESERVED_KEYWORD',
+);
my $gram_filename = "$path/src/backend/parser/gram.y";
-open(GRAM, $gram_filename) || die("Could not open : $gram_filename");
-my ($S, $s, $k, $n, $kcat);
+my ($S, $s, $k, $kcat);
my $comment;
-my @arr;
my %keywords;
-line: while () {
-chomp; # strip record separator
+open my $gram, '<', $gram_filename or croak "Could not open $gram_filename:
$!";
+my @grammar = <$gram>;
+close $gram;
+line: foreach (@grammar) {
+chomp;# strip record separator
$S = $_;
# Make sure any braces are split
-$s = '{', $S =~ s/$s/ { /g;
-$s = '}', $S =~ s/$s/ } /g;
+$s = '{'; $S =~ s/$s/ { /xg;
+$s = '}'; $S =~ s/$s/ } /xg;
# Any comments are split
-$s = '[/][*]', $S =~ s#$s# /* #g;
-$s = '[*][/]', $S =~ s#$s# */ #g;
+$s = '[/][*]'; $S =~ s#$s# /* #xg;
+$s = '[*][/]'; $S =~ s#$s# */ #xg;
if (!($kcat)) {
- # Is this the beginning of a keyword list?
- foreach $k (keys %keyword_categories) {
- if ($S =~ m/^($k):/) {
- $kcat = $k;
- next line;
- }
- }
- next line;
+# Is this the beginning of a keyword list?
+foreach my $k (keys %keyword_categories) {
+if ($S =~ m/^($k):/x) {
+$kcat = $k;
+next line;
+}
+}
+next line;
}
# Now split the line into individual fields
-$n = (@arr = split(' ', $S));
+my @arr = split(' ', $S);
+
+my %comment_switch = (
+'*/' => 0,
+'/*' => 1,
+);
# Ok, we're in a keyword list. Go through each field in turn
-for (my $fieldIndexer = 1; $fieldIndexer <= $n; $fieldIndexer++) {
- if ($arr[$fieldIndexer] eq '*/' && $comment) {
- $comment = 0;
- next;
- }
- elsif ($comment) {
- next;
- }
- elsif ($arr[$fieldIndexer] eq '/*') {
- # start of a multiline comment
- $comment = 1;
- next;
- }
- elsif ($arr[$fieldIndexer] eq '//') {
- next line;
- }
-
- if ($arr[$fieldIndexer] eq ';') {
- # end of keyword list
- $kcat = '';
- next;
- }
-
- if ($arr[$fieldIndexer] eq '|') {
- next;
- }
-
- # Put this keyword into the right list
- push @{$keywords{$kcat}}, $arr[$fieldIndexer];
+for (0..$#arr) {
+if ($arr[$_] eq '//') {
+next line;
+}
+
+if (exists $comment_switch{$arr[$_]}) {
+$comment = $comment_switch{$arr[$_]};
+next;
+}
+
+if ($comment) {
+next;
+}
+
Re: [HACKERS] pg_resetxlog bug?
On Fri, 2009-05-01 at 00:07 +0900, Fujii Masao wrote: > Current pg_resetxlog doesn't remove any archive status files. This > may cause continuous failure of archive command since .ready file > remains even if a corresponding XLOG segment is removed. And, > .done file without XLOG segment cannot be removed by checkpoint, > and would remain forever. These are undesirable behaviors. Agreed > I think that pg_resetxlog should remove existing archive status files > of XLOG segments. Here is the patch to do so. Seems OK. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] GiST index changes
Has the on-disk format changed for GiST indexes? I know it has for hash and GIN indexes. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] Throw some low-level C scutwork at me
Andy Lester wrote: Getting our Perl into shape would be Really Good(TM). :) I will, but right now my #1 is getting some vi modelines in place so we can all be using the same tab/space settings. Hasn't that been discussed before and rejected? (For one thing, plenty of us don't use vi) 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] Throw some low-level C scutwork at me
On Thu, Apr 30, 2009 at 05:39:42PM -0400, Andrew Dunstan wrote: > > > Andy Lester wrote: >>> Getting our Perl into shape would be Really Good(TM). :) >> >> I will, but right now my #1 is getting some vi modelines in place so >> we can all be using the same tab/space settings. > > Hasn't that been discussed before and rejected? Not that I know of. > (For one thing, plenty of us don't use vi) An emacs modeline would go in a similar spot. Apart from those two, are there other modelines we would need? Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GiST index changes
bruce wrote: > Has the on-disk format changed for GiST indexes? I know it has for hash > and GIN indexes. Sorry, I should have clarified: did the GiST index on-disk format change between Postgres 8.3 and 8.4. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] Throw some low-level C scutwork at me
On Apr 30, 2009, at 4:39 PM, Andrew Dunstan wrote: I will, but right now my #1 is getting some vi modelines in place so we can all be using the same tab/space settings. Hasn't that been discussed before and rejected? (For one thing, plenty of us don't use vi) For those who do use vi, it enforces proper file formatting for the user without having to worry about local settings. And if you're an Emacs person, you can help figure out what the modeline should be for Emacs, and we can get that in there, too. xoa -- Andy Lester => a...@petdance.com => www.theworkinggeek.com => AIM:petdance -- 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] Throw some low-level C scutwork at me
Getting our Perl into shape would be Really Good(TM). :) I will, but right now my #1 is getting some vi modelines in place so we can all be using the same tab/space settings. xoxo, Andy -- Andy Lester => a...@petdance.com => www.theworkinggeek.com => AIM:petdance -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] User documentation on signal handling
Hi All,
I just came across this page from 6.4 docs:
http://www.postgresql.org/docs/6.4/static/signals.htm
Do we have any such doc in our current release? It sure is helpful from user
perspective to understand how Postgres responds to different signals; I just
saw another instance of kill -9 recommendation to kill a backend in the
field.
Best regards,
--
gurjeet[.sin...@enterprisedb.com
singh.gurj...@{ gmail | hotmail | indiatimes | yahoo }.com
EnterpriseDB http://www.enterprisedb.com
Mail sent from my BlackLaptop device
[HACKERS] Throw some low-level C scutwork at me
I've got my git clone set up, a copy of GCC 4.4 (and other compilers) at the ready, and am glad to help out on low-level scut work. Anybody need anything done? splint? valgrind? Let me know. xoxo, Andy -- Andy Lester => a...@petdance.com => www.theworkinggeek.com => AIM:petdance -- 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 a tablespace directory in recovery
Hi, Does anyone know why a tablespace directory isn't automatically created in recovery? I think that it's troublesome to create all the directories before recovery. 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] Python 3.0 does not work with PL/Python
On Sun, Apr 5, 2009 at 7:10 PM, James Pye wrote: > Any thoughts on the acceptability of a complete rewrite for Python 3? I've > been fiddling with a HEAD branch including the plpy code in a github repo. > (nah it dunt compile yet: bitrot and been busy with a 3.x driver. ;) I'd love to see this. I can't help with the C stuff, but I can try to help test things as you go. David Blewett -- 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] Keyword list sanity check
Laurent Laborde wrote: On Tue, Apr 28, 2009 at 10:33 AM, Heikki Linnakangas wrote: I wrote a little perl script to perform a basic sanity check to keywords in gram.y and kwlist.h. It checks that all lists are in alphabetical order, all keywords present in gram.y are listed in kwlist.h in the right category, and conversely that all keywords listed in kwlist.h are listed in gram.y. Friendly greetings ! Here is a new version of check_keywords.pl : - perl -w and "use strict" enabled (and all the fixes that come with it) - minor cleaning Thanks, applied! -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Creating a tablespace directory in recovery
Hi, Does anyone know why a tablespace directory isn't automatically created in recovery? I think that it's troublesome to create all the directories before recovery. 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] Keyword list sanity check
On Thursday 30 April 2009 10:27:45 David Fetter wrote: > I'd also like to propose that "strict clean" be a minimum code quality > metric for any Perl code in our code base. A lot of what's in there > is just about impossible to maintain. use strict and use warnings, I think, although with use warnings I have occasionally run into the trouble of some old versions not supporting it (only via perl -w). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_resetxlog bug?
Hi,
Current pg_resetxlog doesn't remove any archive status files. This
may cause continuous failure of archive command since .ready file
remains even if a corresponding XLOG segment is removed. And,
.done file without XLOG segment cannot be removed by checkpoint,
and would remain forever. These are undesirable behaviors.
I think that pg_resetxlog should remove existing archive status files
of XLOG segments. Here is the patch to do so.
Thought?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Index: src/bin/pg_resetxlog/pg_resetxlog.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_resetxlog/pg_resetxlog.c,v
retrieving revision 1.72
diff -c -r1.72 pg_resetxlog.c
*** src/bin/pg_resetxlog/pg_resetxlog.c 25 Feb 2009 13:03:07 - 1.72
--- src/bin/pg_resetxlog/pg_resetxlog.c 30 Apr 2009 14:42:48 -
***
*** 71,76
--- 71,77
static void RewriteControlFile(void);
static void FindEndOfXLOG(void);
static void KillExistingXLOG(void);
+ static void KillExistingArchiveStatus(void);
static void WriteEmptyXLOG(void);
static void usage(void);
***
*** 360,365
--- 361,367
*/
RewriteControlFile();
KillExistingXLOG();
+ KillExistingArchiveStatus();
WriteEmptyXLOG();
printf(_("Transaction log reset\n"));
***
*** 812,817
--- 814,875
/*
+ * Remove existing archive status files
+ */
+ static void
+ KillExistingArchiveStatus(void)
+ {
+ DIR *xldir;
+ struct dirent *xlde;
+ char path[MAXPGPATH];
+
+ snprintf(path, MAXPGPATH, XLOGDIR "/archive_status");
+ xldir = opendir(path);
+ if (xldir == NULL)
+ {
+ fprintf(stderr, _("%s: could not open directory \"%s\": %s\n"),
+ progname, path, strerror(errno));
+ exit(1);
+ }
+
+ errno = 0;
+ while ((xlde = readdir(xldir)) != NULL)
+ {
+ if (strspn(xlde->d_name, "0123456789ABCDEF") == 24 &&
+ (strcmp(xlde->d_name + 24, ".ready") == 0 ||
+ strcmp(xlde->d_name + 24, ".done") == 0))
+ {
+ snprintf(path, MAXPGPATH, XLOGDIR "/archive_status/%s", xlde->d_name);
+ if (unlink(path) < 0)
+ {
+ fprintf(stderr, _("%s: could not delete file \"%s\": %s\n"),
+ progname, path, strerror(errno));
+ exit(1);
+ }
+ }
+ errno = 0;
+ }
+ #ifdef WIN32
+
+ /*
+ * This fix is in mingw cvs (runtime/mingwex/dirent.c rev 1.4), but not in
+ * released version
+ */
+ if (GetLastError() == ERROR_NO_MORE_FILES)
+ errno = 0;
+ #endif
+
+ if (errno)
+ {
+ fprintf(stderr, _("%s: could not read from directory \"%s\": %s\n"),
+ progname, path, strerror(errno));
+ exit(1);
+ }
+ closedir(xldir);
+ }
+
+
+ /*
* Write an empty XLOG file, containing only the checkpoint record
* already set up in ControlFile.
*/
--
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] Keyword list sanity check
On Thu, Apr 30, 2009 at 11:39:33AM -0500, Andy Lester wrote: > > On Apr 30, 2009, at 6:41 AM, Robert Haas wrote: > >>> Please clean up this code at least to the point where it's >>> strict-clean, which means putting "use strict;" right after the >>> shebang line and not checking it in until it runs that way. >> >> And "use warnings;", too. > > > I'll prob'ly come up with a policy file for Perl::Critic and a make > target for perlcritic. The current code has a bunch of 5s in it, so it's a target-rich environment :) Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Keyword list sanity check
Robert Haas wrote: > On Thu, Apr 30, 2009 at 3:27 AM, David Fetter wrote: > > On Tue, Apr 28, 2009 at 11:33:28AM +0300, Heikki Linnakangas wrote: > >> I wrote a little perl script to perform a basic sanity check to > >> keywords ?in gram.y and kwlist.h. It checks that all lists are in > >> alphabetical ?order, all keywords present in gram.y are listed in > >> kwlist.h in the ?right category, and conversely that all keywords > >> listed in kwlist.h are ?listed in gram.y. > >> > >> It found one minor issue already: > >> > >> $ perl src/tools/check_keywords.pl 'SCHEMA' after 'SERVER' in > >> unreserved_keyword list is misplaced > >> > >> SERVER is not in the right place in gram.y, it should go between > >> SERIALIZABLE and SERVER. I'll fix that. > >> > >> I'll put this into src/tools. It's heavily dependent on the format > >> of ?the lists in gram.y and kwlist.h but if it bitrots due to > >> changes in ?those files, we can either fix it or just remove it if > >> it's not deemed ?useful anymore. > > > > Please clean up this code at least to the point where it's > > strict-clean, which means putting "use strict;" right after the > > shebang line and not checking it in until it runs that way. > > And "use warnings;", too. I now see at the top of the CVS file: #!/usr/bin/perl -w use strict; so it seems it has both now. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] Keyword list sanity check
On Apr 30, 2009, at 6:41 AM, Robert Haas wrote: Please clean up this code at least to the point where it's strict-clean, which means putting "use strict;" right after the shebang line and not checking it in until it runs that way. And "use warnings;", too. I'll prob'ly come up with a policy file for Perl::Critic and a make target for perlcritic. xoa -- Andy Lester => a...@petdance.com => www.theworkinggeek.com => AIM:petdance -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Documenting bgwriter during recovery
There's an Open Item for 8.4 about documenting the fact that the bgwriter is now active during archive recovery. So down to me. We don't currently document which processes are active at any given time. i.e. we didn't document that the bgwriter *wasn't* active during recovery, so there's nothing to change. Thoughts? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Keyword list sanity check
David Fetter wrote: > On Tue, Apr 28, 2009 at 11:33:28AM +0300, Heikki Linnakangas wrote: > > I wrote a little perl script to perform a basic sanity check to > > keywords in gram.y and kwlist.h. It checks that all lists are in > > alphabetical order, all keywords present in gram.y are listed in > > kwlist.h in the right category, and conversely that all keywords > > listed in kwlist.h are listed in gram.y. > > > > It found one minor issue already: > > > > $ perl src/tools/check_keywords.pl 'SCHEMA' after 'SERVER' in > > unreserved_keyword list is misplaced > > > > SERVER is not in the right place in gram.y, it should go between > > SERIALIZABLE and SERVER. I'll fix that. > > > > I'll put this into src/tools. It's heavily dependent on the format > > of the lists in gram.y and kwlist.h but if it bitrots due to > > changes in those files, we can either fix it or just remove it if > > it's not deemed useful anymore. > > Please clean up this code at least to the point where it's > strict-clean, which means putting "use strict;" right after the > shebang line and not checking it in until it runs that way. > > I tried, but couldn't make heads or tails of the thing, given all the > unused- and similarly-named variables, failure to indent, etc. I > don't know how to put this gently, but if you checked in C code with > quality like this, you'd have it bounced with derision. > > I'd also like to propose that "strict clean" be a minimum code quality > metric for any Perl code in our code base. A lot of what's in there > is just about impossible to maintain. Good suggestion; I see this has been done: revision 1.2 date: 2009/04/30 10:26:35; author: heikki; state: Exp; lines: +24 -11 Clean up check_keywords.pl script, making it 'strict' and removing a few leftover unused variables. Laurent Laborde -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] Python 3.0 does not work with PL/Python
On Thu, Apr 30, 2009 at 8:30 AM, James Pye wrote: > On Apr 30, 2009, at 5:09 AM, David Blewett wrote: >> >> I'd love to see this. > > yep, once I get 0.9 of the driver out the door, I'll probably focus on this. > > It's the perfect time for a rewrite.. I really don't want to see the 2.x > version ported. =\ > >> I can't help with the C stuff, but I can try to >> help test things as you go. > > I will probably be taking you up on that offer. =) > > I'll be dev'ing on osx with some occasional compiles/tests on fbsd, so an > extra pair of eyes on builds/test runs would be a *huge* help.. I have access to the current version of ubuntu, centos 5, gentoo and opensolaris. Just let me know what you'd like tested. David Blewett -- 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] Keyword list sanity check
On Thu, Apr 30, 2009 at 3:27 AM, David Fetter wrote: > On Tue, Apr 28, 2009 at 11:33:28AM +0300, Heikki Linnakangas wrote: >> I wrote a little perl script to perform a basic sanity check to >> keywords in gram.y and kwlist.h. It checks that all lists are in >> alphabetical order, all keywords present in gram.y are listed in >> kwlist.h in the right category, and conversely that all keywords >> listed in kwlist.h are listed in gram.y. >> >> It found one minor issue already: >> >> $ perl src/tools/check_keywords.pl 'SCHEMA' after 'SERVER' in >> unreserved_keyword list is misplaced >> >> SERVER is not in the right place in gram.y, it should go between >> SERIALIZABLE and SERVER. I'll fix that. >> >> I'll put this into src/tools. It's heavily dependent on the format >> of the lists in gram.y and kwlist.h but if it bitrots due to >> changes in those files, we can either fix it or just remove it if >> it's not deemed useful anymore. > > Please clean up this code at least to the point where it's > strict-clean, which means putting "use strict;" right after the > shebang line and not checking it in until it runs that way. And "use warnings;", too. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Keyword list sanity check
On Apr 30, 2009, at 2:27 AM, David Fetter wrote: Please clean up this code at least to the point where it's strict-clean, which means putting "use strict;" right after the shebang line and not checking it in until it runs that way. I can take care of this, David. Shouldn't be too tough. -- Andy Lester => a...@petdance.com => www.petdance.com => AIM:petdance -- 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] Keyword list sanity check
On Tue, Apr 28, 2009 at 11:33:28AM +0300, Heikki Linnakangas wrote: > I wrote a little perl script to perform a basic sanity check to > keywords in gram.y and kwlist.h. It checks that all lists are in > alphabetical order, all keywords present in gram.y are listed in > kwlist.h in the right category, and conversely that all keywords > listed in kwlist.h are listed in gram.y. > > It found one minor issue already: > > $ perl src/tools/check_keywords.pl 'SCHEMA' after 'SERVER' in > unreserved_keyword list is misplaced > > SERVER is not in the right place in gram.y, it should go between > SERIALIZABLE and SERVER. I'll fix that. > > I'll put this into src/tools. It's heavily dependent on the format > of the lists in gram.y and kwlist.h but if it bitrots due to > changes in those files, we can either fix it or just remove it if > it's not deemed useful anymore. Please clean up this code at least to the point where it's strict-clean, which means putting "use strict;" right after the shebang line and not checking it in until it runs that way. I tried, but couldn't make heads or tails of the thing, given all the unused- and similarly-named variables, failure to indent, etc. I don't know how to put this gently, but if you checked in C code with quality like this, you'd have it bounced with derision. I'd also like to propose that "strict clean" be a minimum code quality metric for any Perl code in our code base. A lot of what's in there is just about impossible to maintain. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
