walreceiver settings Re: [HACKERS] Streaming Replication patch for CommitFest 2009-09
Hi, On Fri, Sep 18, 2009 at 7:34 PM, Fujii Masao wrote: > This approach is OK if the stand-alone walreceiver is treated steadily > by the startup process like a child process under postmaster: > > * Handling of some interrupts: SIGHUP, SIGTERM?, SIGINT, SIGQUIT... > For example, the startup process would need to rethrow walreceiver > the interrupt from postmaster. > > * Communication with other child processes: stats collector? syslogger?... > For example, the log message generated by walreceiver should also > be collected by syslogger if requested. Also we should consider how to give a GUC parameter to the stand-alone walreceiver. In the initial patch, since walreceiver was a child process of postmaster, it could easily get any GUC parameter. But it's not so easy to give a GUC parameter to a stand-alone program. I think that at least the following parameters should affect walreceiver: * wal_sync_method I want walreceiver to use fdatasync instead of fsync for performance improvement. And other DBA might want to choose another method. * fsync I'm not surprised if someone wants to disable fsync in the standby. * some parameters for logging I think that the log messages generated by walreceiver should also be treated as well as the other postgres messages. For example, I'd like to specify log_line_prefix also for walreceiver. There are some approaches to give a GUC parameter to walreceiver. Which is the best? 1) Give a parameter as a command-line argument of the stand-alone walreceiver. This is a straightforward approach, but wouldn't cover a reload of parameter. 2) Give a parameter via pipe between the startup process and walreceiver. 3) Change walreceiver to read a configuration file. The problem is that the command-line argument of postmaster doesn't affect walreceiver. The combination of 1) and 3) might be required. 4) Change walreceiver back to a child process of postmaster. Do you have any other better approach? 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] [COMMITTERS] pgsql: Easier to translate psql help Instead of requiring translators
Josh Williams wrote: On Fri, 2009-09-18 at 09:46 -0400, Tom Lane wrote: pet...@postgresql.org (Peter Eisentraut) writes: Log Message: --- Easier to translate psql help Looks like this broke the msvc build ... Yep, one of create_help.pl's arguments changed to not include the file extension, but msvc was still trying to give it "sql_help.h". Quickpatch attached. Thanks. Applied. 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] Crypto
David Do you can comment this altertatives or choices that we have? We can support us in Bruce Schneier[1], Chief Security Technology Officer, BT (schne...@schneier.com) who is one of the person that knows many topics about security in the world. Is a very nice person and allways is to able to help to people. One of his knowledge areas is the hashing algorithm's desing and study, and we can ask to him since his point of view which would be the best algoritm to do this. Regards [1] http://www.schneier.com "The hurry is enemy of the success: for that reason...Be patient" Ing. Marcos L. Ortiz Valmaseda Línea Soporte y Despliegue Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD) Linux User # 418229 PostgreSQL User http://www.postgresql.org http://www.planetpostgresql.org/ http://www.postgresql-es.org/ - Mensaje original - De: "David Fetter" Para: "PG Hackers" Enviados: Viernes, 18 de Septiembre 2009 15:14:29 GMT -10:00 Hawai Asunto: [HACKERS] Crypto Folks, Here's what came out for Mozilla, which, I hope you'll pardon my saying so, is a teensy tad more widely used than PostgreSQL has any plans to become. http://www.internetnews.com/government/article.php/3839831/Mozilla+Firefox+Cleared+of+US+Export+Rules.htm I suggest that we start by putting secure hashing algorithms into the core distribution so, should MD5 ever break, we have real alternatives, and not done in a panic. 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 -- 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] [COMMITTERS] pgsql: Easier to translate psql help Instead of requiring translators
On Fri, 2009-09-18 at 09:46 -0400, Tom Lane wrote:
> pet...@postgresql.org (Peter Eisentraut) writes:
> > Log Message:
> > ---
> > Easier to translate psql help
>
> Looks like this broke the msvc build ...
Yep, one of create_help.pl's arguments changed to not include the file
extension, but msvc was still trying to give it "sql_help.h".
Quickpatch attached.
Wondered why my attempts to test and review another patch were suddenly
confounded...
> regards, tom lane
- Josh Williams
Index: src/tools/msvc/Solution.pm
===
RCS file: /projects/cvsroot/pgsql/src/tools/msvc/Solution.pm,v
retrieving revision 1.47
diff -c -r1.47 Solution.pm
*** src/tools/msvc/Solution.pm 6 Jan 2009 18:37:50 - 1.47
--- src/tools/msvc/Solution.pm 19 Sep 2009 03:41:40 -
***
*** 235,241
{
print "Generating sql_help.h...\n";
chdir('src\bin\psql');
! system("perl create_help.pl ../../../doc/src/sgml/ref sql_help.h");
chdir('..\..\..');
}
--- 235,241
{
print "Generating sql_help.h...\n";
chdir('src\bin\psql');
! system("perl create_help.pl ../../../doc/src/sgml/ref sql_help");
chdir('..\..\..');
}
--
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] Largeobject access controls
On Fri, Sep 18, 2009 at 8:29 PM, Stephen Frost wrote: > Jamie, > > How is the review for this coming? Do you have any thoughts regarding > the new GUC? > Hi, sorry... these have been hard days... i'm just starting reviewing -- 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] [PATCH] Largeobject access controls
Jamie, * Robert Haas (robertmh...@gmail.com) wrote: > Jaime Casanova > - Largeobject access controls How is the review for this coming? Do you have any thoughts regarding the new GUC? Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] updated hstore patch
> "David" == "David E Wheeler" writes:
David> * I ran the following to update the SQL functions in my simple database:
David>psql -d try --set hstore_xact='--' -f hstore.sql
David>The use of `--set hstore_xact='--' was on Andrew's advice
David>via IRC, because otherwise the entire update takes place in
David>a single transaction, and thus would fail since I already
David>had the old hstore installed. By using this psql variable
David>hack to disable the transactions, I was able to install
David>over the old hstore.
I'm more than half inclined to take this bit out again. It made sense in the
context of the pgfoundry version, but it doesn't fit in so well for contrib.
(It's a concept I was testing on the pgfoundry version)
However, I would prefer to keep the ability to do this:
psql --set hstore_schema='myschema' -f hstore.sql dbname
The logic to do it is a bit ugly, but editing the file to set what schema to
use is even uglier...
David> Notes and minor issues:
David> * `hstore - hstore` resolves before `hstore - text`, meaning
David> that this failed:
The '-' operator did not previously exist so this isn't a compatibility issue.
BUT the delete(hstore,text) function did previously exist, however it seems to
still be resolved in preference to delete(hstore,hstore) when the second arg
is a bare text literal:
contrib_regression=# explain verbose select delete(('a' => now()::text),'a');
QUERY PLAN
---
Result (cost=0.00..0.02 rows=1 width=0)
Output: delete(('a'::text => (now())::text), 'a'::text)
(2 rows)
contrib_regression=# explain verbose select delete(('a' =>
now()::text),'a=>1'::hstore);
QUERY PLAN
Result (cost=0.00..0.02 rows=1 width=0)
Output: delete(('a'::text => (now())::text), '"a"=>"1"'::hstore)
(2 rows)
The only open question I can see is what delete(hs,$1) resolves to when $1 is
an unknown-type placeholder; this is probably an incompatibility with the old
version if anyone is relying on that (but I don't see why they would be).
David> * Maybe it's time to kill off `...@` and `~`, eh? Or could they
David> generate warnings for a release or something? How are
David> operators properly deprecated?
David> * The documentation for `populate_record()` is wrong. It's
David> still just a cut-and-paste of `delete()`
GAH. I fixed some doc issues (stray &s) but forgot that one. I'll fix it.
David> * The NOTE about `populate_record()` says that it takes
David> anyelement instead of record and just throws an error if it's
David> not a record. I thought that C functions could take record
David> arguments. Why do the extra work here?
Because "record" doesn't express the fact that the return type of
populate_record is the SAME record type as its parameter type, whereas
anyelement does.
David> * Your original submission say that the new version offers
David> btree and hash support, but the docs still mention only GIN
David> and GIST.
I'll fix that.
David> * I'd like to see more examples of the new functionality in
David> the documentation. I'd be happy to contribute them once the
David> main patch is committed.
Thanks. I'll do some (especially for populate_record, which really needs
them), but more can be added later.
David> * I think that there should be some exmples in the docs of the
David> use of the backslash with and without
David> standard_conforming_strings and with and without E''. That
David> stuff is confusing enough, it should all be spelled out, IMHO.
ugh. yeah
David> * The use of the `:hstore_xact` variable hack needs to be
David> documented,
(or removed, see above)
David> along with detailed instructions for those upgrading
David> (in-place) from 8.4. You might consider documenting your
David> `:hstore_default_schema` variable as well: if I understand
David> correctly, it's a way to specify a schema on the command-line
David> without having to edit the file, yes? Currently, there are no
David> installation instructions in the documentation.
ya.
David> Comments
David>
David> * So the main objection to the original patch from the July
David> CommitFest, that it wasn't backwards compatible, seems to have
David> been addressed, assuming that the structure currently used in
David> HEAD is just like what's in 8.4, so in-place upgrade should
David> work, yes? It apears that you've taken the approach, in
David> hstore_compat.c, of reading both the old and the new
David> formats. Does it also upgrade the old formats as it reads
David> them, or only as they're updated? (I'm assuming the latter.)
Old values are converted to new values in core, but they can't be
changed on-disk unless something actually updates them.
David> * I'm not qualified to talk
[HACKERS] Crypto
Folks, Here's what came out for Mozilla, which, I hope you'll pardon my saying so, is a teensy tad more widely used than PostgreSQL has any plans to become. http://www.internetnews.com/government/article.php/3839831/Mozilla+Firefox+Cleared+of+US+Export+Rules.htm I suggest that we start by putting secure hashing algorithms into the core distribution so, should MD5 ever break, we have real alternatives, and not done in a panic. 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
[HACKERS] Draft for organized beta testing
Hackers, I'm about to launch on a program of organized alpha and beta testing by volunteers from our community. Initially, tests will be logged either by e-mail parsing on the pgsql-testers mailing list, or by a web-based Radix interface if I can get one up. Please comment on the draft if you see anything I'm missing; otherwise I'll start the call for testers as soon as Alpha2 comes out. -- Josh Berkus PostgreSQL Experts Inc. www.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: [HACKERS] SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan wrote: > Boszormenyi Zoltan írta: > > > > Okay, we implemented only the lock_timeout GUC. > > Patch attached, hopefully in an acceptable form. > > Documentation included in the patch, lock_timeout > > works the same way as statement_timeout, takes > > value in milliseconds and 0 disables the timeout. > > > > Best regards, > > Zoltán Böszörményi > > > > New patch attached. It's only regenerated for current CVS > so it should apply cleanly. > I'm getting segfaults, built in 32 bit linux with gcc bin/pg_ctl -D data start -l logfile -o "--lock_timeout=5" Session 1: jjanes=# begin; BEGIN jjanes=# select * from pgbench_branches where bid=3 for update; bid | bbalance | filler -+--+ 3 | -3108950 | (1 row) Session 2: jjanes=# select * from pgbench_branches where bid=3 for update; ERROR: could not obtain lock on row in relation "pgbench_branches" jjanes=# select * from pgbench_branches where bid=3 for update; ERROR: could not obtain lock on row in relation "pgbench_branches" jjanes=# select * from pgbench_branches where bid=3 for update; ERROR: could not obtain lock on row in relation "pgbench_branches" jjanes=# set lock_timeout = 0 ; SET jjanes=# select * from pgbench_branches where bid=3 for update; Session1: jjanes=# commit; server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. I just realized I should have built with asserts turned on. I'll do that tomorrow, but don't want to delay this info until then, so I am sending it now. Cheers, Jeff
Re: [HACKERS] happy birthday Tom Lane ...
On Sep 18, 2009, at 5:18 PM, Paul Matthews wrote: happy_birthday++; SELECT count( happy ) FROM birthday WHERE name ~ 'Tom Lane'; WARNING : condition stack overflow: INF Sigh, Rob smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] happy birthday Tom Lane ...
happy_birthday++; -- Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- 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] happy birthday Tom Lane ...
Congratulations from Cuba, Tom. I hope that you follow teaching to many of us. Regards "The hurry is enemy of the success: for that reason...Be patient" Ing. Marcos L. Ortiz Valmaseda Línea Soporte y Despliegue Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD) Linux User # 418229 PostgreSQL User http://www.postgresql.org http://www.planetpostgresql.org/ http://www.postgresql-es.org/ - Mensaje original - De: "Khee Chin" Para: "Tom Lane" CC: "PostgreSQL-development" , "Hans-Juergen Schoenig -- PostgreSQL" Enviados: Viernes, 18 de Septiembre 2009 2:36:15 GMT -10:00 Hawai Asunto: Re: [HACKERS] happy birthday Tom Lane ... Happy birthday Tom, from the sunny island of Singapore. :-) Regards, Khee Chin. On Fri, Sep 18, 2009 at 7:04 PM, Hans-Juergen Schoenig -- PostgreSQL wrote: > Tom, > > On behalf of the entire PostgreSQL team here in Austria I want to wish you a > happy birthday. > We hope that you fill be a vital part of PostgreSQL for many years to come. > > Best regards, > > Hans-Jürgen Schönig + team > > > -- > Cybertec Schoenig & Schoenig GmbH > Reyergasse 9 / 2 > A-2700 Wiener Neustadt > Web: www.postgresql-support.de > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby 0.2.1
I want to help on this area, but I need a mentor for this. For example, Heikki will be a excellent mentor for me. Following the theme, I think that we have to wide all questions for the process of the acceptance of a patch on the same way that you Simon. We could write new requirements with all these ideas. Don´t you think? Regards "The hurry is enemy of the success: for that reason...Be patient" Ing. Marcos L. Ortiz Valmaseda Línea Soporte y Despliegue Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD) Linux User # 418229 PostgreSQL User http://www.postgresql.org http://www.planetpostgresql.org/ http://www.postgresql-es.org/ - Mensaje original - De: "Simon Riggs" Para: "Robert Haas" CC: "Heikki Linnakangas" , "Josh Berkus" , pgsql-hackers@postgresql.org Enviados: Jueves, 17 de Septiembre 2009 20:53:24 GMT -10:00 Hawai Asunto: Re: [HACKERS] Hot Standby 0.2.1 On Thu, 2009-09-17 at 19:01 -0400, Robert Haas wrote: > > > > I'm going to put the index-only scans aside for now to focus on hot > > standby and streaming replication. Both are big patches, so there's > > plenty of work in those two alone, and not only for me. > > What is the best way to attack this? Should I keep reviewing > index-only scans so that you have feedback for when you get back to > it, or should I move on to something else? If something else, does it > make more sense for me to look at HS since I did a bit of work with a > previous version, or would it be better for me to just pick one of the > other patches from the CommitFest and work on that? > > Also, stepping back from me personally, should we try to assign some > additional reviewers to these patches? Is there some way we can > divide up review tasks among multiple people so that we're not > repeating each others work? > > Thoughts appreciated, from Heikki, Simon, or others. I think this is a great opportunity to widen the pool of people contributing to reviews. I suggest the creation of a second group of people, performing round-robin testing of patches. These people would be able to verify * documentation matches implemented features (does it do what it says on the tin?) * usability of explicit features (do the features work well?) * usability gap of unimplemented features (what else do we need?) * are there any bugs? These questions are often quickly answered for smaller patches, but HS's scope mean that such a task properly executed could take a full week, if not longer. Second group of people are just as skilled Postgres people as reviewers, in some cases more so, apart from they have less detailed knowledge of the codebase. We have many such people and it would be good to encourage them to perform thorough reviews rather than "tire kicking". I'm not sure that Heikki needs additional reviewers. He now has significant knowledge of the patch and is good at focusing on key aspects of the internals. Other code reviewers are welcome, of course. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] DefaultACLs
Jan Urbański napsal(a): Petr Jelinek wrote: So I've been working on solution with which I am happy with (does not mean anybody else will be also though). Hi Petr, I'm reviewing this patch and after reading it I have some comments. Unfortunately, when I got to the compiling part, it turned out that the attached patch is missing src/include/catalog/pg_default_acls.h (or is it just me?). I'll continue reviewing while waiting for a new patch with that header file and in any case will send the full review tommorrow. Hmm looks like I forgot to git add that file in the new branch, sorry about that. Attached patch should have the missing file (otherwise it's same). -- Regards Petr Jelinek (PJMODOS) defacl-2009-09-18.diff.gz Description: Unix tar archive -- 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: Review handling of MOVE and FETCH (ToDo)
Hello
2009/9/18 Selena Deckelmann :
> Hi!
>
> John Naylor and I reviewed this patch. John created two test cases to
> demonstrated issues described later in this email. I've attached
> those for reference.
>
> On Thu, Aug 27, 2009 at 8:04 PM, Pavel Stehule
> wrote:
>> Hello,
>>
>> this small patch complete MOVE support in plpgsql and equalize plpgsql
>> syntax with sql syntax.
>>
>> There are possible new directions:
>>
>> FORWARD expr, FORWARD ALL, BACKWARD expr, BACKWARD all.
>>
>> These directions are not allowed for FETCH statement, because returns more
>> rows.
>>
>> This patch is related to ToDo issue: Review handling of MOVE and FETCH
>
> == Submission review ==
>
> * Is the patch in the standard form?
>
> Yes, we have a contextual diff!
>
> * Does it apply cleanly to the current CVS HEAD?
>
> Yes!
>
> * Does it include reasonable tests, docs, etc?
>
> Suggestion: change variable 'returns_row' to 'returns_multiple_rows'
> and invert the values of 'returns_row' in the patch.
>
good idea - changed
> Example:
>
> if (!fetch->returns_row)
> ereport(ERROR,
> (errcode(ERRCODE_SYNTAX_ERROR),
> errmsg("statement FETCH returns more rows."),
> errhint("Multirows fetch are not allowed in PL/pgSQL.")));
>
> instead do:
>
> if (fetch->returns_multiple_rows)
> ereport(ERROR,
> (errcode(ERRCODE_SYNTAX_ERROR),
> errmsg("statement FETCH returns more than one row."),
> errhint("Multirow FETCH is not allowed in PL/pgSQL.")));
>
> Does that make sense? In reading the code, we thought this change
> made this variable much easier to understand, and the affected code
> much easier to read.
>
> ===
>
> Need a hard tab here to match the surrounding code: :)
> + %token K_ALL$
>
fixed
> ===
>
> Can you clarify this comment?
>
> + /*
> + * Read FETCH or MOVE statement direction. For statement for are only
> + * one row directions allowed. MOVE statement can use FORWARD [(n|ALL)],
> + * BACKWARD [(n|ALL)] directions too.
> + */
>
> We think what you mean is:
> By default, cursor will only move one row. To MOVE more than one row
> at a time see complete_direction()
>
fixed - I add new comment there - I am sure, so this comments needs
some correction from native speakers - sorry, my English is bad still.
> We tested on Mac OS X and Linux (Ubuntu)
> ===
>
> Also, the tests did not test what the standard SQL syntax would
> require. John created a test case that demonstrated that the current
> patch did not work according to the SQL spec.
>
> We used that to find a little bug in complete_direction() (see below!).
>
> == Usability review ==
>
> Read what the patch is supposed to do, and consider:
>
> * Does the patch actually implement that?
>
> No -- we found a bug:
>
> Line 162 of the patch:
> + expr = read_sql_expression2(K_FROM, K_IN,
> Should be:
> + fetch->expr = read_sql_expression2(K_FROM, K_IN,
>
grr
fixed
> And you don' t need to declare expr earlier in the function.
>
> Once that's changed, the regression test needs to be updated for the
> expected result set.
>
> * Does it follow SQL spec, or the community-agreed behavior?
>
> It conforms with the already implemented SQL syntax once the
> 'fetch->expr' thing is fixed.
>
> * Have all the bases been covered?
>
> We think so, as long the documentation is fixed and the above changes
> are applied.
>
> Another thing John noted is that additional documentation needs to be
> updated for the SQL standard syntax, so that it no longer says that
> PL/PgSQL doesn't implement the same functionality.
>
> Thanks!
> -selena & John
>
> --
> http://chesnok.com/daily - me
> http://endpoint.com - work
>
Thank You
Pavel
*** ./doc/src/sgml/plpgsql.sgml.orig 2009-08-27 17:14:26.926410144 +0200
--- ./doc/src/sgml/plpgsql.sgml 2009-09-18 22:44:45.267608075 +0200
***
*** 2656,2670
The options for the direction clause are
! the same as for FETCH, namely
NEXT,
PRIOR,
FIRST,
LAST,
ABSOLUTE count,
RELATIVE count,
! FORWARD, or
! BACKWARD.
Omitting direction is the same
as specifying NEXT.
direction values that require moving
--- 2656,2670
The options for the direction clause are
! similar to FETCH, namely
NEXT,
PRIOR,
FIRST,
LAST,
ABSOLUTE count,
RELATIVE count,
! FORWARD count | ALL , or
! BACKWARD count | ALL .
Omitting direction is the same
as specifying NEXT.
direction values that require moving
***
*** 2678,2683
--- 2678,2684
MOVE curs1;
MOVE LAST FROM curs3;
MOVE RELATIVE -2 FROM curs4;
+ MOVE FORWARD 2 FROM curs4;
*** ./src/pl/plpgsql/src/gram.y.orig 2009-08-26 22:43:23.138239357 +0200
--- ./src/pl/plpgsql/src/gram.y 2009-09-18 22:10:37.239609424 +0200
***
*** 72,77
--- 72,79
int until, const char *expected);
static List*read_raise_options(void);
+ static PLpgSQL_stm
Re: [HACKERS] happy birthday Tom Lane ...
daveg wrote: > On Fri, Sep 18, 2009 at 01:04:23PM +0200, Hans-Juergen Schoenig -- PostgreSQL > wrote: >> Tom, >> >> On behalf of the entire PostgreSQL team here in Austria I want to wish >> you a happy birthday. >> We hope that you fill be a vital part of PostgreSQL for many years to come. >> >> Best regards, >> >> Hans-Jürgen Schönig + team > > +1 from me too. I generally hate to do "me too", but in this case it is well justified :-) +1 Joe signature.asc Description: OpenPGP digital signature
Re: [HACKERS] updated join removal patch
On Fri, Sep 18, 2009 at 3:52 PM, Tom Lane wrote: > Robert Haas writes: >> The clauses are well-defined, but they don't have well-defined sides. >> I see now what you're going for with clause_matches_join, but >> "matches" is a pretty broad term, IMO. > > clause_sides_match_join? Yes, that's perfect. ...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] numeric_to_number() function skipping some digits
2009/9/19 Tom Lane :
> Should we have it throw an error if the input corresponding to a G
> symbol doesn't match the expected group separator? I'm concerned that
> that would break applications that work okay today.
>
It would be a substantial change to the behaviour, and to do it
properly we'd have to change to_date() to actually parse separator
characters as well.
That is, you can currently write to_date('2009/09/19', '-MM-DD')
-- it doesn't matter what the separator characters actually look like,
since per the format pattern they cannot affect the date outcome.
This naturally leads to the question we always have to ask with these
functions: What Does Oracle Do?
But FWIW, a -1 from me for changing this.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: Anonymous code blocks (was: Re: [HACKERS] GRANT ON ALL IN schema)
Brendan Jurd writes: > The commitfest app has you listed as the reviewer for this patch. Any > progress on your review? Funny I just sent a mail to rrr explaining I don't think I'll be able to complete my review until next Thursday. Feel free to steal me the patch if you want to, as I'm planning to start on Monday only... Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Anonymous code blocks (was: Re: [HACKERS] GRANT ON ALL IN schema)
Hi Dimitri, The commitfest app has you listed as the reviewer for this patch. Any progress on your review? Cheers, BJ -- 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] happy birthday Tom Lane ...
On Fri, Sep 18, 2009 at 01:04:23PM +0200, Hans-Juergen Schoenig -- PostgreSQL wrote: > Tom, > > On behalf of the entire PostgreSQL team here in Austria I want to wish > you a happy birthday. > We hope that you fill be a vital part of PostgreSQL for many years to come. > > Best regards, > > Hans-Jürgen Schönig + team +1 from me too. -dg -- David Gould da...@sonic.net 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- 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] TODO item: Allow more complex user/database default GUC settings
--On 25. August 2009 22:17:38 -0400 Alvaro Herrera wrote: I'm just posting in case somebody has thoughts on the UI part of it. Other things that need fixed: - need to figure out locking for roles; this stuff must be synchronized with role drop - pg_shadow and pg_roles need a join to obtain settings - two regression tests need their expected file updated - catalog version bump Here's a first shot on this for my current review round. Patch needed to re-merged into current CVS HEAD due to some merge conflicts, i've also adjusted the regression tests (minor). On a first look, i like the patch (especially the code for the utility commands accessing the settings is better modularized now, which looks much nicer). -- Thanks Bernd complex_guc_review_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] updated join removal patch
Robert Haas writes: > The clauses are well-defined, but they don't have well-defined sides. > I see now what you're going for with clause_matches_join, but > "matches" is a pretty broad term, IMO. clause_sides_match_join? 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] updated join removal patch
On Fri, Sep 18, 2009 at 3:06 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Sep 18, 2009 at 1:58 PM, Tom Lane wrote:
>>> Robert Haas writes:
Mmm, I like that. Putting that bunch of hairy logic in a subroutine
instead of repeating it in several places definitely seems better. I
don't really like the name "clause_matches_join", though.
>
>>> It was the first thing that came to mind ... got a better idea?
>
>> clause_has_well_defined_sides()?
>
> Nah ... they're "well defined" in any case, they might just not be what
> we need for the current join. As an example,
>
> (a.f1 + b.f2) = c.f3
>
> would be usable if joining {A B} to {C}, but not when joining
> {A} to {B C}.
The clauses are well-defined, but they don't have well-defined sides.
I see now what you're going for with clause_matches_join, but
"matches" is a pretty broad term, IMO.
...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] FSM search modes
On Fri, 2009-09-18 at 15:43 +0300, Hannu Krosing wrote: > > > > * cluster - page selection made based around selecting block with > > freespace nearest current block and we prefer keep-in-sequence to > > avoid-contention > > Is the information about "current block" available to FSM search API, or > do we need to change the API for that ? Need to change the API, but its a small code impact. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] happy birthday Tom Lane ...
On Fri, 2009-09-18 at 16:24 +0200, Dimitri Fontaine wrote: > Hans-Juergen Schoenig -- PostgreSQL writes: > > Tom, > > happy birthday. > > +1 from me :) +1 from me too :D > Regards, > -- > dim -- Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training -- 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] FSM search modes
On Thu, 2009-09-17 at 16:26 +0100, Simon Riggs wrote: > Just been looking again at the way FSM works. In fsm_search_avail() we > essentially have just a single way for working out how to search the > tree. > > Seems like it would be good to abstract this so that we can implement a > number of FSM search strategies > > * (current) randomize - page selection encourages different backends to > access different blocks, thus reducing block contention > > * cluster - page selection made based around selecting block with > freespace nearest current block and we prefer keep-in-sequence to > avoid-contention Is the information about "current block" available to FSM search API, or do we need to change the API for that ? > * compact - page selection specifically attempts to find the lowest > numbered blocks, so that the table will naturally shrink over time. > > These are not all mutually exclusive, suggested combinations would be > > randomize, randomize | cluster, randomize | compact > > So we don't give up the load spreading behaviour, we just apply the > logic at lower levels of the tree only. > > VACUUM could set the FSM into FSMstrategy = compact when it notices that > most of the free blocks are at lower end of table. Or explicitly set > during VF replacement utility. > > FSMstrategy = cluster would be the default if clustering is enabled on a > table. > > FSMstrategy can change via ALTER TABLE ... WITH (fsm_strategy = ...) > > -- > Simon Riggs www.2ndQuadrant.com > -- Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training -- 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] updated join removal patch
Robert Haas writes:
> On Fri, Sep 18, 2009 at 1:58 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Mmm, I like that. Putting that bunch of hairy logic in a subroutine
>>> instead of repeating it in several places definitely seems better. I
>>> don't really like the name "clause_matches_join", though.
>> It was the first thing that came to mind ... got a better idea?
> clause_has_well_defined_sides()?
Nah ... they're "well defined" in any case, they might just not be what
we need for the current join. As an example,
(a.f1 + b.f2) = c.f3
would be usable if joining {A B} to {C}, but not when joining
{A} to {B C}.
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] Join optimization for inheritance tables
Herodotos Herodotou writes: > This patch extends the query optimizer to consider joins between child tables > when hierarchies are joined together. I looked over this patch a bit. I am of the opinion that this is a lot of work towards a dead-end direction :-(. The patch contains a large amount of rather inefficient code that attempts to reverse-engineer knowledge about whether an inheritance tree forms a range-partitioned table. We already know that reasoning from first principles using a set of arbitrary per-table constraints doesn't scale very well, and this would make it a lot worse. pgsql-hackers have been talking for some time about implementing an explicit partitioning feature, which would give the planner direct knowledge about this type of table structure without expending nearly so much work (and then expending it all over again for the next query). I think the right way to go at it is to implement that first, and then see about teaching the planner to plan like this. We could possibly extract a subset of the patch that just deals with pushing joins down through appends, without the constraint-exclusion logic that tries to eliminate provably empty join pairs. But I'm dubious that that would be worthwhile by itself. I think you need the constraint exclusion to eliminate a good deal of work before this is actually better than doing a single join above the append. There are a number of other things I don't like, such as the restrictive and not-obviously-necessary requirement that all the join clauses be simple "Var op Var" clauses. But the main thing is that a large fraction of the patch is doing something I don't think we should try to do. 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] Lock Wait Statistics (next commitfest)
Pierre, > Configurable by #define's in lwlock.c Given that we already have dtrace/systemtap probes around the lwlocks, is there some way you could use those instead of extra #defines? -- Josh Berkus PostgreSQL Experts Inc. www.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: [HACKERS] Lock Wait Statistics (next commitfest)
I have this patch, if you're interested. LWLock Instrumentation Patch - counts locks and waits in shared and exclusive mode - for selected locks, measures wait and hold times - for selected locks, displays a histogram of wait and hold times - information is printed at backend exit Configurable by #define's in lwlock.c Regards, pierre lwlock_instrument_v4.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] Unicode UTF-8 table formatting for psql text output
Hi!
Below is from Brad Slinger. I'm just forwarding his message so that
the review will be in the thread for the archives. (Sorry, Brad that I
missed this earlier.. I thought you'd already replied to the list for
some reason.)
Brad says:
Please forgive my top posting. Below is my patch review.
The purpose of this patch is to improve psql output
readability. This is accomplished through table formatting
improvements and line art improvements.
The patch is a unified diff, rather than a context diff. The
patch applies from the project root with with -p1 set. Patch(1)
reports "with fuzz 1" when patching src/bin/psql/print.h. The patch
touches two files:
src/bin/psql/print.h
src/bin/psql/print.c
The patch does not include any documentation or tests.
Comments and style are similar to existing code.
The patched code compiles without any additional warnings.
Lint gripes about a trailing ',' in 'typedef enum printTextRule' in
print.h. Other additional lint seem to be false positives. The
regression tests pass against the new patch.
The patched code installs and runs. There were no crashes,
although I didn't try very hard. The ASCII line art works:
createdb test
psql test
\pset border 2
\pset format wrapped
SELECT 'short' AS short, lpad('', 1000, 'long') AS long;
I can trigger the new line art by setting LC_ALL=en_US.UTF-8 in
the environment.
As far as I can tell, the patch works as advertised. The patch
does not change the server/backend. I don't see any performance
problems.
Thanks,
--bts
--
http://chesnok.com/daily - me
http://endpoint.com - work
--
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] updated join removal patch
On Fri, Sep 18, 2009 at 1:58 PM, Tom Lane wrote: > Robert Haas writes: >> Mmm, I like that. Putting that bunch of hairy logic in a subroutine >> instead of repeating it in several places definitely seems better. I >> don't really like the name "clause_matches_join", though. It's more >> like "clause has well-defined sides, and mark which is which as a >> side-effect". > > It was the first thing that came to mind ... got a better idea? clause_has_well_defined_sides()? ...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] updated join removal patch
Robert Haas writes: > Mmm, I like that. Putting that bunch of hairy logic in a subroutine > instead of repeating it in several places definitely seems better. I > don't really like the name "clause_matches_join", though. It's more > like "clause has well-defined sides, and mark which is which as a > side-effect". It was the first thing that came to mind ... got a better idea? 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] Draft for organized beta testing
> Would help if I had a link, eh? > > http://wiki.postgresql.org/wiki/HowToBetaTest It would also help if the mail servers cleared my original e-mail. Gr. Here's what I posted originally, which our servers have decided to eat: I'm about to launch on a program of organized alpha and beta testing by volunteers from our community. Initially, tests will be logged either by e-mail parsing on the pgsql-testers mailing list, or by a web-based Radix interface if I can get one up. Please comment on the draft if you see anything I'm missing; otherwise I'll start the call for testers as soon as Alpha2 comes out. -- Josh Berkus PostgreSQL Experts Inc. www.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: [HACKERS] updated hstore patch
On Sep 15, 2009, at 8:31 PM, Andrew Gierth wrote:
> Gah. rerolled to fix a missing file. includes the docs too this time.
Yay, thank you Andrew! Here are my review notes.
Testing
===
Here's what I did to try out the patch, paying special attention to in-
place upgrading:
* I built a simple database with a table with an (old) hstore column
from an unpatched Git checkout.
* I ran the script I developed for testing the previous patch in July,
commenting out the new features, just to test the existing
implementation.
* I applied your patch, rebuilt hstore, installed the DSO, and
restarted PotgreSQL. I did *not* dump the previous database or restore
it, I just just used the existing cluster. The only thing that changed
was the new hstore.
* I ran the hstore `make installcheck` and all tests passed.
* I ran the following to update the SQL functions in my simple database:
psql -d try --set hstore_xact='--' -f hstore.sql
The use of `--set hstore_xact='--' was on Andrew's advice via IRC,
because otherwise the entire update takes place in a single
transaction, and thus would fail since I already had the old hstore
installed. By using this psql variable hack to disable the
transactions, I was able to install over the old hstore.
* I connected to my simple database and did a select on the table I
created before installing the new hstore, and all the old data showed
up fine in psql.
* I uncommented the new stuff in my test script (attached) and ran it.
Everything worked as I expected.
Notes and minor issues:
* `hstore - hstore` resolves before `hstore - text`, meaning that this
failed:
SELECT 'a=>1, b =>2'::hstore - 'a' = 'b=>2';
ERROR: Unexpected end of string
LINE 1: SELECT 'a=>1, b =>2'::hstore - 'a' = 'b=>2';
But it works if I cast it:
SELECT 'a=>1, b =>2'::hstore - 'a'::text = 'b=>2';
Not sure if there's anything to be done about that. I mentioned this
issue back in July, as well.
* Maybe it's time to kill off `...@` and `~`, eh? Or could they generate
warnings for a release or something? How are operators properly
deprecated?
* The documentation for `populate_record()` is wrong. It's still just
a cut-and-paste of `delete()`
* The NOTE about `populate_record()` says that it takes anyelement
instead of record and just throws an error if it's not a record. I
thought that C functions could take record arguments. Why do the extra
work here?
* Your original submission say that the new version offers btree and
hash support, but the docs still mention only GIN and GIST.
* I'd like to see more examples of the new functionality in the
documentation. I'd be happy to contribute them once the main patch is
committed.
* I think that there should be some exmples in the docs of the use of
the backslash with and without standard_conforming_strings and with
and without E''. That stuff is confusing enough, it should all be
spelled out, IMHO.
* The use of the `:hstore_xact` variable hack needs to be documented,
along with detailed instructions for those upgrading (in-place) from
8.4. You might consider documenting your `:hstore_default_schema`
variable as well: if I understand correctly, it's a way to specify a
schema on the command-line without having to edit the file, yes?
Currently, there are no installation instructions in the documentation.
Comments
* So the main objection to the original patch from the July
CommitFest, that it wasn't backwards compatible, seems to have been
addressed, assuming that the structure currently used in HEAD is just
like what's in 8.4, so in-place upgrade should work, yes? It apears
that you've taken the approach, in hstore_compat.c, of reading both
the old and the new formats. Does it also upgrade the old formats as
it reads them, or only as they're updated? (I'm assuming the latter.)
* I'm not qualified to talk about the approach taken to maintaining
compatibility, but would like to know if it imposes an overhead on the
use of the data type, and if so, how much?
* Also, just as an aside, I'm wondering if the approach you've taken
could be used for core data types going forward, so as to work towards
true in-place upgrades in the future?
* Regarding the bug you found in the old hstore format (mentioned
[here](http://archives.postgresql.org/pgsql-hackers/2009-07/msg01422.php)
), has that been fixed? Is it a regression that should be back-patched?
* Does there need to be documentation with upgrade instructions for
hstore-new users (the pgFoundry version)? Or will you handle that via
a new pgFoundry release?
* In addition to the functions to get all the keys and all the values
as arrays, I'd love a function (or, dare I say, a cast?) to get all
the rows and keys in an array. Something like this:
try=# select 'a => 1, b => 2'::hstore::text[];
array
---
{a,1,b,2}
I'd find t
Re: [HACKERS] generic copy options
Josh Berkus wrote: Nope, but it was on the checklist and I was being thorough. That's a good thing. I was just seeing if I needed to get involved in performance testing. That would be good to have more people test the autopartitioning feature in COPY. If you want to be involved in performance testing on that, that would be great. Emmanuel -- Emmanuel Cecchet Aster Data Systems Web: http://www.asterdata.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] updated join removal patch
On Fri, Sep 18, 2009 at 1:26 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Sep 17, 2009 at 4:59 PM, Tom Lane wrote: >>> Robert Haas writes: You're the committer; I'm not. But I completely disagree. There isn't any reason at all to duplicate this logic in two separate places, let alone three. I'd actually be in favor of merging the existing two cases even if we weren't adding join removal. >>> >>> No, I still think this was a bad idea. There are *parts* of those >>> tests that are similar, but combining them all into one function is >>> just a recipe for bugs. > >> Having read your commit, it makes more sense to me. The fact that >> we're now looking at innerrel->baserestrictinfo also is a pretty >> powerful argument for your way. > > Looking at it some more, I think that there is some value in factoring > out the tests to see if the clause has the right variable membership, > so I did that. Mmm, I like that. Putting that bunch of hairy logic in a subroutine instead of repeating it in several places definitely seems better. I don't really like the name "clause_matches_join", though. It's more like "clause has well-defined sides, and mark which is which as a side-effect". ...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] generic copy options
On Fri, Sep 18, 2009 at 10:31:21AM -0700, Josh Berkus wrote: > > > Nope, but it was on the checklist and I was being thorough. > > That's a good thing. I was just seeing if I needed to get involved in > performance testing. > > -- > Josh Berkus > PostgreSQL Experts Inc. > www.pgexperts.com I always say, the more tests the better. From the tests I ran it was clear the parser did not change speed. Might be good to have someone confirm that. -- Dan -- 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] Schedule for 8.5 Development
Josh Berkus wrote: > Bruce, > > >> CF17/15 to 8/14 > >> Alpha1 by 8/20 > >> CF29/15 to 10/14 > >> Alpha2 by 10/20 > >> CF311/15 to 12/14 > >> Alpha3 by 11/20 > >> CF41/15 to 2/14 > >> Alpha4 by 2/20 > >> Beta1 est. 3/1 to 3/7 > >> Release June, depending on bugs > > > > I think that June release date is realistic. > > Are we ready to put this up on /developer then and make it real? Sure. -- 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] Draft for organized beta testing
> Please comment on the draft if you see anything I'm missing; otherwise > I'll start the call for testers as soon as Alpha2 comes out. Would help if I had a link, eh? http://wiki.postgresql.org/wiki/HowToBetaTest -- 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] generic copy options
> Nope, but it was on the checklist and I was being thorough. That's a good thing. I was just seeing if I needed to get involved in performance testing. -- Josh Berkus PostgreSQL Experts Inc. www.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: [HACKERS] generic copy options
On Fri, Sep 18, 2009 at 10:21:08AM -0700, Josh Berkus wrote: > On 9/17/09 3:54 PM, Greg Smith wrote: > > On Thu, 17 Sep 2009, Dan Colish wrote: > > > >> - Performance appears to be the same although I don't have a good > >> way for > >> testing this at the moment > > > > Here's what I do to generate simple COPY performance test cases: > > Is there any reason to think that *this* copy patch will affect > performance at all? > > -- > Josh Berkus > PostgreSQL Experts Inc. > www.pgexperts.com > Nope, but it was on the checklist and I was being thorough. -- Dan -- 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] updated join removal patch
Robert Haas writes: > On Thu, Sep 17, 2009 at 4:59 PM, Tom Lane wrote: >> Robert Haas writes: >>> You're the committer; I'm not. But I completely disagree. There >>> isn't any reason at all to duplicate this logic in two separate >>> places, let alone three. I'd actually be in favor of merging the >>> existing two cases even if we weren't adding join removal. >> >> No, I still think this was a bad idea. There are *parts* of those >> tests that are similar, but combining them all into one function is >> just a recipe for bugs. > Having read your commit, it makes more sense to me. The fact that > we're now looking at innerrel->baserestrictinfo also is a pretty > powerful argument for your way. Looking at it some more, I think that there is some value in factoring out the tests to see if the clause has the right variable membership, so I did that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] generic copy options
On 9/17/09 3:54 PM, Greg Smith wrote: > On Thu, 17 Sep 2009, Dan Colish wrote: > >> - Performance appears to be the same although I don't have a good >> way for >> testing this at the moment > > Here's what I do to generate simple COPY performance test cases: Is there any reason to think that *this* copy patch will affect performance at all? -- Josh Berkus PostgreSQL Experts Inc. www.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: [HACKERS] Schedule for 8.5 Development
Bruce, >> CF1 7/15 to 8/14 >> Alpha1 by 8/20 >> CF2 9/15 to 10/14 >> Alpha2 by 10/20 >> CF3 11/15 to 12/14 >> Alpha3 by 11/20 >> CF4 1/15 to 2/14 >> Alpha4 by 2/20 >> Beta1est. 3/1 to 3/7 >> Release June, depending on bugs > > I think that June release date is realistic. Are we ready to put this up on /developer then and make it real? -- Josh Berkus PostgreSQL Experts Inc. www.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: [HACKERS] [PATCH] pgbench: new feature allowing to launch shell commands
On Fri, Sep 18, 2009 at 03:10:14PM +0900, Michael Paquier wrote: > > > > You really should be returning a value at the point since the function > > signature defines a return type. If not the function should be void, > > which it cannot be in this context since it is used for boolean tests > > elsewhere. The returns in question are all part of error blocks and > > should return false. > > > > OK I got your point, I missed the part managing with CState, which is tested > after doCustom. > Another version of the patch is attached with this email. > > I must be doing something wrong when I am running this script. It is > > still throwing errors. Would you mind showing me the pgbench command you > > used to run it? > > > > Of course, here it is the list of commands I use: > pgbench -i dbname (in case your database is called dbname) > pgbench -c 10 -t 10 -f transaction_file_name.data dbname (customer and > transaction numbers can also bet set as you want). > > Regards, > > -- > Michael Paquier > > NTT OSSC OK, thank you for sending me the patch and the relivent commands. You're still not returning false where you should be, but that wasn't the issue I am seeing. I believe there is an issue in either the custom script you posted on the wiki or pgbench itself. Here is the script I am running, you might recongnize it :) \set nbranches :scale \set ntellers 10 * :scale \set naccounts 10 * :scale \setrandom aid 1 :naccounts \setrandom bid 1 :nbranches \setrandom tid 1 :ntellers \setrandom delta -5000 5000 \setrandom txidrand 0 1 START TRANSACTION; UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid; SELECT abalance FROM pgbench_accounts WHERE aid = :aid; SELECT abalance FROM pgbench_accounts WHERE aid = :aid; UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid; UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid; INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); PREPARE TRANSACTION ':txidrand'; \shell ls -ll >> /tmp/log_data`date '+%Y%m%d'`_`date '+%k%M'` COMMIT PREPARED ':txidrand'; So I get this output with and with out the shell command in there, against the unpatched and patched version on pgbench. The commands you sent will not work with this script since it is using prepared statements. I am using this command to run the script. ./contrib/pgbench/pgbench -c 10 -j 2 -M prepared -f custom.script test >From which, I get the following output: starting vacuum...end. Client 0 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement "P0_15" requires 0 Client 1 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement "P0_15" requires 0 Client 2 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement "P0_15" requires 0 Client 5 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement "P0_15" requires 0 Client 8 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement "P0_15" requires 0 Client 6 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement "P0_15" requires 0 Client 7 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement "P0_15" requires 0 Client 3 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement "P0_15" requires 0 Client 4 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement "P0_15" requires 0 Client 9 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement "P0_15" requires 0 transaction type: Custom query scaling factor: 1 query mode: prepared number of clients: 10 number of threads: 2 number of transactions per client: 10 number of transactions actually processed: 0/100 tps = 0.00 (including connections establishing) tps = 0.00 (excluding connections establishing) Since it occurs on both versions, I'm having some trouble identifying whether this is a bug in the script or a bug in pgbench. Any help is appreciated. -- --Dan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby 0.2.1
On Fri, 2009-09-18 at 11:14 -0400, Tom Lane wrote: > Simon Riggs writes: > > On Fri, 2009-09-18 at 07:23 -0700, Jeff Janes wrote: > >> Is there a reason that you remove the WAL_DEBUG shown below? > > > WAL_DEBUG is not removed by the patch, though that section of code is > > removed, as you observe. I recall an earlier bug report by > > me/conversation on hackers about how that section of code was > > irrecoverably broken, since it's calling an rmgr routine while not in > > recovery and also assuming the data is fully accessible at that point, > > which it is not. > > Wouldn't it be sufficient to remove the rm_desc() call? I agree > that that's broken, but the rest doesn't seem to be. That would make sense also. Previous action just because that was earlier consensus. Will change. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] numeric_to_number() function skipping some digits
Jeevan Chalke writes:
> With PG84, I have tried something like this which seem incorrect to me.
> # SELECT '' AS to_number_2, to_number('-347,58', '99G999');
Well, the input doesn't actually match the format, so I'm not totally
excited about this. You do get sane results from:
regression=# select to_number('-347,58', '999G99');
to_number
---
-34758
(1 row)
Should we have it throw an error if the input corresponding to a G
symbol doesn't match the expected group separator? I'm concerned that
that would break applications that work okay today.
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] happy birthday Tom Lane ...
On Fri, Sep 18, 2009 at 01:04:23PM +0200, Hans-Juergen Schoenig -- PostgreSQL wrote: > Tom, > > On behalf of the entire PostgreSQL team here in Austria I want to > wish you a happy birthday. We hope that you fill be a vital part > of PostgreSQL for many years to come. Happy birthday, Tom! Many happy returns :) 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] Hot Standby 0.2.1
Simon Riggs writes: > On Fri, 2009-09-18 at 07:23 -0700, Jeff Janes wrote: >> Is there a reason that you remove the WAL_DEBUG shown below? > WAL_DEBUG is not removed by the patch, though that section of code is > removed, as you observe. I recall an earlier bug report by > me/conversation on hackers about how that section of code was > irrecoverably broken, since it's calling an rmgr routine while not in > recovery and also assuming the data is fully accessible at that point, > which it is not. Wouldn't it be sufficient to remove the rm_desc() call? I agree that that's broken, but the rest doesn't seem to be. 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] happy birthday Tom Lane ...
On Fri, Sep 18, 2009 at 4:04 AM, Hans-Juergen Schoenig -- PostgreSQL wrote: > Tom, > > On behalf of the entire PostgreSQL team here in Austria I want to wish you a > happy birthday. > We hope that you fill be a vital part of PostgreSQL for many years to come. In short, +1 from me. :) -selena -- http://chesnok.com/daily - me http://endpoint.com - work -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby 0.2.1
On Fri, 2009-09-18 at 07:23 -0700, Jeff Janes wrote: > On Tue, Sep 15, 2009 at 2:41 PM, Simon Riggs > wrote: > > OK, here is the latest version of the Hot Standby patchset. > This is > about version 30+ by now, but we should regard this as 0.2.1 > Patch against CVS HEAD (now): clean apply, compile, no known > bugs. > Is there a reason that you remove the WAL_DEBUG shown below? WAL_DEBUG is not removed by the patch, though that section of code is removed, as you observe. I recall an earlier bug report by me/conversation on hackers about how that section of code was irrecoverably broken, since it's calling an rmgr routine while not in recovery and also assuming the data is fully accessible at that point, which it is not. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] happy birthday Tom Lane ...
Hans-Juergen Schoenig -- PostgreSQL writes: > Tom, > happy birthday. +1 from me :) Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby 0.2.1
On Tue, Sep 15, 2009 at 2:41 PM, Simon Riggs wrote:
>
> OK, here is the latest version of the Hot Standby patchset. This is
> about version 30+ by now, but we should regard this as 0.2.1
> Patch against CVS HEAD (now): clean apply, compile, no known bugs.
>
Hi Simon,
Is there a reason that you remove the WAL_DEBUG shown below?
*** begin:;
*** 899,923
FIN_CRC32(rdata_crc);
record->xl_crc = rdata_crc;
- #ifdef WAL_DEBUG
- if (XLOG_DEBUG)
- {
- StringInfoData buf;
-
- initStringInfo(&buf);
- appendStringInfo(&buf, "INSERT @ %X/%X: ",
-RecPtr.xlogid,
RecPtr.xrecoff);
- xlog_outrec(&buf, record);
- if (rdata->data != NULL)
- {
- appendStringInfo(&buf, " - ");
- RmgrTable[record->xl_rmid].rm_desc(&buf,
record->xl_info, rdata->data);
- }
- elog(LOG, "%s", buf.data);
- pfree(buf.data);
- }
- #endif
-
/* Record begin of record in appropriate places */
ProcLastRecPtr = RecPtr;
Insert->PrevRecord = RecPtr;
--- 947,952
Thanks,
Jeff
Re: [HACKERS] Hot Standby 0.2.1
Robert Haas writes: > Also, stepping back from me personally, should we try to assign some > additional reviewers to these patches? Is there some way we can > divide up review tasks among multiple people so that we're not > repeating each others work? > > Thoughts appreciated, from Heikki, Simon, or others. How about this proposal: http://archives.postgresql.org/pgsql-hackers/2009-08/msg00764.php Regards, -- dim -- 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] happy birthday Tom Lane ...
Happy nice birthday Tom Lane On Fri, Sep 18, 2009 at 10:36 AM, Robert Haas wrote: > On Fri, Sep 18, 2009 at 7:11 AM, A. Kretschmer > wrote: > > In response to Hans-Juergen Schoenig -- PostgreSQL : > >> Tom, > >> > >> On behalf of the entire PostgreSQL team here in Austria I want to wish > >> you a happy birthday. > >> We hope that you fill be a vital part of PostgreSQL for many years to > come. > > > > +1 > > Of all the responses so far I like this one the best. +1 from me, 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 > -- Marcelo Costa www.marcelocosta.net - “You can't always get what want”, Doctor House in apology to Mike Jagger
Re: [HACKERS] [COMMITTERS] pgsql: Easier to translate psql help Instead of requiring translators
pet...@postgresql.org (Peter Eisentraut) writes: > Log Message: > --- > Easier to translate psql help Looks like this broke the msvc build ... 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] happy birthday Tom Lane ...
On Fri, Sep 18, 2009 at 7:11 AM, A. Kretschmer wrote: > In response to Hans-Juergen Schoenig -- PostgreSQL : >> Tom, >> >> On behalf of the entire PostgreSQL team here in Austria I want to wish >> you a happy birthday. >> We hope that you fill be a vital part of PostgreSQL for many years to come. > > +1 Of all the responses so far I like this one the best. +1 from me, 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] Rename StrNCpy to avoid conflictions on win32
Peter Eisentraut wrote: > On Mon, 2009-09-07 at 11:36 +0200, Magnus Hagander wrote: > > On Mon, Sep 7, 2009 at 04:40, Itagaki > > Takahiro wrote: > > > There might be some places to replace it to strlcpy() instead. > > > > Can't comment on that without looking at the code, but it wouldn't surprise > > me. > > There are some performance tradeoffs between these variants, and we > already did change all (most?) of the not performance-critical calls to > strlcpy a while ago. Of all the macro names we use, I would have bet StrNCpy() was the last one that would have conflicted with anything. :-O Did they copy it from our code? -- 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] happy birthday Tom Lane ...
On Fri, Sep 18, 2009 at 8:09 AM, Andrew Chernow wrote: > Hans-Juergen Schoenig -- PostgreSQL wrote: >> >> Tom, >> >> On behalf of the entire PostgreSQL team here in Austria I want to wish you >> a happy birthday. >> We hope that you fill be a vital part of PostgreSQL for many years to >> come. >> >> Best regards, >> >> Hans-Jürgen Schönig + team >> >> > > Happy 30th Tom ;) so that's where he gets his energy... (happy birthday) merlin -- 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] happy birthday Tom Lane ...
Happy birthday Tom, from the sunny island of Singapore. :-) Regards, Khee Chin. On Fri, Sep 18, 2009 at 7:04 PM, Hans-Juergen Schoenig -- PostgreSQL wrote: > Tom, > > On behalf of the entire PostgreSQL team here in Austria I want to wish you a > happy birthday. > We hope that you fill be a vital part of PostgreSQL for many years to come. > > Best regards, > > Hans-Jürgen Schönig + team > > > -- > Cybertec Schoenig & Schoenig GmbH > Reyergasse 9 / 2 > A-2700 Wiener Neustadt > Web: www.postgresql-support.de > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- 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] happy birthday Tom Lane ...
Hans-Juergen Schoenig -- PostgreSQL wrote: Tom, On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. Best regards, Hans-Jürgen Schönig + team Happy 30th Tom ;) -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.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] [PATCH] DefaultACLs
Petr Jelinek wrote: > So I've been working on solution with which I am happy with (does not > mean anybody else will be also though). Hi Petr, I'm reviewing this patch and after reading it I have some comments. Unfortunately, when I got to the compiling part, it turned out that the attached patch is missing src/include/catalog/pg_default_acls.h (or is it just me?). I'll continue reviewing while waiting for a new patch with that header file and in any case will send the full review tommorrow. Cheers, Jan -- 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] happy birthday Tom Lane ...
Hans-Juergen Schoenig -- PostgreSQL wrote: > > Tom, > > On behalf of the entire PostgreSQL team here in Austria I want to wish > you a happy birthday. > We hope that you fill be a vital part of PostgreSQL for many years to come. Alright, Tom ... I'm in the area, when/where's the party? ;) In any event, happy birthday. -- Bill Moran http://www.potentialtech.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] happy birthday Tom Lane ...
On Fri, 2009-09-18 at 13:04 +0200, Hans-Juergen Schoenig -- PostgreSQL wrote: > On behalf of the entire PostgreSQL team here in Austria I want to wish > you a happy birthday. > We hope that you fill be a vital part of PostgreSQL for many years to > come. Assuming that we have only one Tom Lane (i.e., he is not clustered yet), Happy birthday from here, too :) -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org signature.asc Description: This is a digitally signed message part
Re: [HACKERS] happy birthday Tom Lane ...
In response to Hans-Juergen Schoenig -- PostgreSQL : > Tom, > > On behalf of the entire PostgreSQL team here in Austria I want to wish > you a happy birthday. > We hope that you fill be a vital part of PostgreSQL for many years to come. +1 -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] happy birthday Tom Lane ...
Tom, On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. Best regards, Hans-Jürgen Schönig + team -- Cybertec Schoenig & Schoenig GmbH Reyergasse 9 / 2 A-2700 Wiener Neustadt Web: www.postgresql-support.de -- 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] Streaming Replication patch for CommitFest 2009-09
Hi, On Thu, Sep 17, 2009 at 5:08 PM, Heikki Linnakangas wrote: > I'm thinking that walreceiver should be a stand-alone program that the > startup process launches, similar to how it invokes restore_command in > PITR recovery. Instead of using system(), though, it would use > fork+exec, and a pipe to communicate. This approach is OK if the stand-alone walreceiver is treated steadily by the startup process like a child process under postmaster: * Handling of some interrupts: SIGHUP, SIGTERM?, SIGINT, SIGQUIT... For example, the startup process would need to rethrow walreceiver the interrupt from postmaster. * Communication with other child processes: stats collector? syslogger?... For example, the log message generated by walreceiver should also be collected by syslogger if requested. For now, I think that pipe is enough for communication between the startup process and walreceiver. Though there was the idea to pass XLOG to the startup process via wal_buffers, in which pipe is not suitable, I think that is overkill. 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] Streaming Replication patch for CommitFest 2009-09
Fujii Masao wrote: > Hi, > > On Fri, Sep 18, 2009 at 2:47 PM, Heikki Linnakangas > wrote: >> Heikki Linnakangas wrote: >>> I'm thinking that walreceiver should be a stand-alone program that the >>> startup process launches, similar to how it invokes restore_command in >>> PITR recovery. Instead of using system(), though, it would use >>> fork+exec, and a pipe to communicate. >> Here's a WIP patch to do that, over your latest posted patch. I've also >> pushed this to my git repository at >> git://git.postgresql.org/git/users/heikki/postgres.git, "replication" >> branch. > > In my environment, I cannot use git protocol for some reason. > Could you export your repository so that it can be accessed also via http? Sure, it should be accessible via HTTP as well: http://git.postgresql.org/git/users/heikki/postgres.git > How should we advance development of SR? > Should I be concentrated on the primary side, and leave the standby side to > you? > When I change something, should I make a patch for the latest SR source in > your > git repo, and submit it? Hmm, yeah, let's do that. Right now, I'm trying to understand the page boundary stuff and partial page handling in ReadRecord and walsender. -- 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] Streaming Replication patch for CommitFest 2009-09
Hi, On Fri, Sep 18, 2009 at 2:47 PM, Heikki Linnakangas wrote: > Heikki Linnakangas wrote: >> I'm thinking that walreceiver should be a stand-alone program that the >> startup process launches, similar to how it invokes restore_command in >> PITR recovery. Instead of using system(), though, it would use >> fork+exec, and a pipe to communicate. > > Here's a WIP patch to do that, over your latest posted patch. I've also > pushed this to my git repository at > git://git.postgresql.org/git/users/heikki/postgres.git, "replication" > branch. In my environment, I cannot use git protocol for some reason. Could you export your repository so that it can be accessed also via http? BTW, I seem to be able to access http://git.postgresql.org/git/bucardo.git. http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#exporting-via-http How should we advance development of SR? Should I be concentrated on the primary side, and leave the standby side to you? When I change something, should I make a patch for the latest SR source in your git repo, and submit it? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] numeric_to_number() function skipping some digits
Hi,
With PG84, I have tried something like this which seem incorrect to me.
# SELECT '' AS to_number_2, to_number('-347,58', '99G999');
to_number_2 | to_number
-+---
| -3458
(1 row)
After browsing the code (numeric_to_number), I have found that number string
is processed according to the number format. Which means, when 'G' is found
in the format we have moved the number pointer to next character. This is
why the digit '7' is skipped. And while processing ',', as it is not a digit
it is ignored.
Is this expected behaviour? or a bug?
Thanks
--
Jeevan B Chalke
EnterpriseDB Software India Private Limited, Pune
Visit us at: www.enterprisedb.com
---
If better is possible, then good is not enough
Re: [HACKERS] Feedback on getting rid of VACUUM FULL
Simon Riggs wrote: > CTIDs don't help with optimistic locking, though it seems they can. > > If you don't hold open the transaction then someone else can update the > row. That sounds good, but because of HOT it is possible that the same > CTID with the same PK value occupies that exact CTID value when you > return to check it. You think row has not been updated so you perform > your update, but it has been updated, so you overwrite previous data - > data loss. Actually worse, sporadic data loss because of race > conditions. Yeah, you have to check xmin as well. -- 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] Feedback on getting rid of VACUUM FULL
> Exactly. The application is typically going to throw a "concurrent > update" type of error when this happens, and we don't want magic > background operations to cause that. > I`d give up the possibility of using CTIDs in the way You explained for an auto-debloater without blinking an eye. Maybe we should have a GUC to enable/disable the auto-debloater? Make it a reloption? -- 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] Feedback on getting rid of VACUUM FULL
On Fri, 2009-09-18 at 08:50 +0200, Albe Laurenz wrote: > Tom Lane wrote: > > > I don't see any reason why not breaking the user visible behavior of > > > tuples CTID between any two major releases, > > > > > Am I completely wet here? > > > > Completely. This is a user-visible behavior that we have encouraged > > people to rely on, and for which there is no easy substitute. > > I second that: it would hurt to lose this generic technique for > optimistic locking. CTIDs don't help with optimistic locking, though it seems they can. If you don't hold open the transaction then someone else can update the row. That sounds good, but because of HOT it is possible that the same CTID with the same PK value occupies that exact CTID value when you return to check it. You think row has not been updated so you perform your update, but it has been updated, so you overwrite previous data - data loss. Actually worse, sporadic data loss because of race conditions. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG patchset
New patch - two decimal-related memory leak fixes.
Happens on 8.4 and 8.5, maybe on older trees as well.
One of the two chunks was in the SQLDA patch originally.
This is independent from any other patches.
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/
diff -dcrpN pgsql.ifdef/src/interfaces/ecpg/compatlib/informix.c pgsql.decimalfix/src/interfaces/ecpg/compatlib/informix.c
*** pgsql.ifdef/src/interfaces/ecpg/compatlib/informix.c 2009-09-03 12:25:47.0 +0200
--- pgsql.decimalfix/src/interfaces/ecpg/compatlib/informix.c 2009-09-15 12:35:48.0 +0200
*** deccvasc(char *cp, int len, decimal *np)
*** 232,238
{
int i = PGTYPESnumeric_to_decimal(result, np);
! free(result);
if (i != 0)
ret = ECPG_INFORMIX_NUM_OVERFLOW;
}
--- 232,238
{
int i = PGTYPESnumeric_to_decimal(result, np);
! PGTYPESnumeric_free(result);
if (i != 0)
ret = ECPG_INFORMIX_NUM_OVERFLOW;
}
diff -dcrpN pgsql.dyncursor/src/interfaces/ecpg/ecpglib/data.c pgsql.sqlda/src/interfaces/ecpg/ecpglib/data.c
*** pgsql.dyncursor/src/interfaces/ecpg/ecpglib/data.c 2009-08-08 17:19:45.0 +0200
--- pgsql.sqlda/src/interfaces/ecpg/ecpglib/data.c 2009-09-03 12:56:36.0 +0200
*** ecpg_get_data(const PGresult *results, i
*** 554,560
else
PGTYPESnumeric_to_decimal(nres, (decimal *) (var + offset * act_tuple));
! free(nres);
break;
case ECPGt_interval:
--- 554,560
else
PGTYPESnumeric_to_decimal(nres, (decimal *) (var + offset * act_tuple));
! PGTYPESnumeric_free(nres);
break;
case ECPGt_interval:
--
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] Streaming Replication patch for CommitFest 2009-09
Heikki Linnakangas wrote: > Heikki Linnakangas wrote: >> I'm thinking that walreceiver should be a stand-alone program that the >> startup process launches, similar to how it invokes restore_command in >> PITR recovery. Instead of using system(), though, it would use >> fork+exec, and a pipe to communicate. > > Here's a WIP patch to do that, over your latest posted patch. I've also > pushed this to my git repository at > git://git.postgresql.org/git/users/heikki/postgres.git, "replication" > branch. > > I'll continue reviewing... BTW, my modified patch doesn't correctly zero-fill new WAL segments. Needs to be fixed... -- 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
