Re: [HACKERS] PG 9.1 tentative timeline
On fre, 2010-06-11 at 08:15 -0400, Stephen Frost wrote: > * Pr, Solaiyappan (NSN - IN/Bangalore) (solaiyappan...@nsn.com) wrote: > > I understand this is very early to ask this.. but, is there any tentative > > timeline has been planned / available for the PostgreSQL 9.1 release, like > > for the alpha or beta releases before the general release? > > The tentative timeline is "more-or-less the same as 9.0 went". That is > to say, we're hopeful to start a commitfest July 15th, finish by Auguet > 15th, cut alpha1, then switch to GIT for the main repo, and start the > next commitfets September 15th. I wrote it down now: http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Development_Plan -- 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] pg_upgrade output directory
Andrew Dunstan wrote: > > Why does pg_upgrade create its output directory in the user's home > directory (or TMP on Windows)? I should have thought that the current > working directory would be a more suitable choice. At the very least > there should be an option for where to create it. Also, this location > doesn't seem to be referred to at all in the docs. Yeah, it is odd. I did it that way because the output files need to exist after the utility is run, and I worried that putting them in the current directory might cause them to be accidentally deleted or overlooked. However, I might have been too conservative. How do tools that generate multiple output files usually handle this situation? Do they output in to a subdirectory in $HOME, or in a subdirectory of the current directory, or just create multiple files without a subdirectory? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 9.0beta2 - server crash when using HS + SR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello I am testing HS + SR in a system running 9.0beta2. What I am doing is just trying all kind of crazy combinations and see how the system handles them. One of the test I knew was going to fail was to create a tablespace in the master node with the directory used by the tablespace existing in the master and not in the standby node. What I didn't expect was such a serious consequence. Postgres crashed in the standby node and it refused to start until the directory needed by the tablespace was created also in the standby. I suppose there is not an easy way of fixing this, but at least it would be a good idea to update the documentation with some information about how to fix this error situation (hot-standby.html#HOT-STANDBY-CAVEATS will be a nice place to have this information) Another thing is that the HINT message in the logs was a little misleading. The server is down and it will not start without fixing the cause of the problem. - FATAL: directory "/var/pgsql/ts_test" does not exist CONTEXT: xlog redo create ts: 20177 "/var/pgsql/ts_test" LOG: startup process (PID 10147) exited with exit code 1 LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. - regards, - -- Rafael Martinez, Center for Information Technology Services University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwS4ssACgkQBhuKQurGihQSfACePmzdjILYnPzKnk9NuDoB19YT b3YAn2ufyis1r819ow3KJ46OO0Kv0Hd0 =boIg -END PGP SIGNATURE- -- 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] warning message in standby
Robert Haas wrote: > > If my streaming replication stops working, I want to know about it as > > soon as possible. WARNING just doesn't cut it. > > > > This needs some better thought. > > > > If we PANIC, then surely it will PANIC again when we restart unless we > > do something. So we can't do that. But we need to do something better > > than > > > > WARNING there is a bug that will likely cause major data loss > > HINT you'll be sacked if you miss this message > > +1. I was making this same argument (less eloquently) upthread. > I particularly like the errhint(). I am wondering what action would be most likely to get the administrator's attention. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- 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] Proposal for 9.1: WAL streaming from WAL buffers
> Hm, but then Robert's failure case is real, and streaming replication might > break due to an OS-level crash of the master. Or am I missing something? Well, in the failover case this isn't a problem, it's a benefit: the standby gets a transaction which you would have lost off the master. However, I can see this as a problem in the event of a server-room powerout with very bad timing where there isn't a failover to the standby: 1) Master goes out 2) "floating" transaction applied to standby. 3) Standby goes out 4) Power back on 5) master comes up 6) standby comes up It seems like, in that sequence, the standby would have one transaction which the master doesn't have, yet the standby thinks it can continue getting WAL from the master. Or did I miss something which makes this impossible? -- -- Josh Berkus PostgreSQL Experts Inc. http://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] hstore ==> and deprecate =>
On Fri, Jun 11, 2010 at 5:23 PM, Tom Lane wrote:
> Joseph Adams writes:
>> To repeat an earlier question (which was in turn repeating an earlier
>> question), would it be possible to do one of these, yielding '
>> "key"=>"this", "key2"=>"that" '::hstore :
>
>> hstore(key := 'this', key2 := 'that')
>> hstore(key => 'this', key2 => 'that')
>> hstore(row('this' AS key, 'that' AS key2))
>
> The last of those is probably the easiest to get to. We already have
> hstore_from_record:
>
> contrib_regression=# select hstore(row('this', 'that'));
> hstore
>
> "f1"=>"this", "f2"=>"that"
> (1 row)
>
> and the only thing lacking is an easy way to specify the column names
> associated with the anonymous record type. Extending the ROW()
> construct with AS labels as suggested above might be a reasonable way.
+1
A couple of people were just requesting that very thing (ROW/AS) on
the IRC channel today. row() is a pretty useful mechanism and it
would be nice to have it more defensible vs. table changes.
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] Proposal for 9.1: WAL streaming from WAL buffers
On Jun 11, 2010, at 16:31 , Tom Lane wrote: > Fujii Masao writes: >> In 9.0, walsender reads WAL always from the disk and sends it to the standby. >> That is, we cannot send WAL until it has been written (and flushed) to the >> disk. > > I believe the above statement to be incorrect: walsender does *not* wait > for an fsync to occur. Hm, but then Robert's failure case is real, and streaming replication might break due to an OS-level crash of the master. Or am I missing something? best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] The smallest patch (vacuumdb.c)
Josh Berkus writes: >> Looks like someone accidentally deleted the -Z option from vacuumdb. Forgot to add it in the first place, looks like. >> Patch attached, one character. ;-) > Make that 3 characters; Jan pointed out that we ought to have the > command-string in the same order as the switch options. Applied. 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] The smallest patch (vacuumdb.c)
On 6/11/10 3:44 PM, Josh Berkus wrote:
> Folks,
>
> Looks like someone accidentally deleted the -Z option from vacuumdb.
> Patch attached, one character. ;-)
Make that 3 characters; Jan pointed out that we ought to have the
command-string in the same order as the switch options.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
diff -c -r1.37 vacuumdb.c
*** src/bin/scripts/vacuumdb.c 26 Feb 2010 04:14:36 - 1.37
--- src/bin/scripts/vacuumdb.c 11 Jun 2010 22:41:58 -
***
*** 74,80
handle_help_version_opts(argc, argv, "vacuumdb", help);
! while ((c = getopt_long(argc, argv, "h:p:U:wWeqd:zaFt:fv",
long_options, &optindex)) != -1)
{
switch (c)
{
--- 74,80
handle_help_version_opts(argc, argv, "vacuumdb", help);
! while ((c = getopt_long(argc, argv, "h:p:U:wWeqd:zZFat:fv",
long_options, &optindex)) != -1)
{
switch (c)
{
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] The smallest patch (vacuumdb.c)
Folks,
Looks like someone accidentally deleted the -Z option from vacuumdb.
Patch attached, one character. ;-)
(thanks Gabrielle, and Jan Urbanski)
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
? GNUmakefile
? config.log
? config.status
? force_quote_all-20090714.patch
? vacuumdb_Z_patch
? doc/src/sgml/features-supported.sgml
? doc/src/sgml/features-unsupported.sgml
? doc/src/sgml/release-8.4.2.sgml
? doc/src/sgml/release-8.5.jmb.sgml
? doc/src/sgml/version.sgml
? src/Makefile.global
? src/include/pg_config.h
? src/include/stamp-h
? src/interfaces/ecpg/include/ecpg_config.h
? src/interfaces/ecpg/include/stamp-h
Index: src/bin/scripts/vacuumdb.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/scripts/vacuumdb.c,v
retrieving revision 1.37
diff -c -r1.37 vacuumdb.c
*** src/bin/scripts/vacuumdb.c 26 Feb 2010 04:14:36 - 1.37
--- src/bin/scripts/vacuumdb.c 11 Jun 2010 22:41:58 -
***
*** 74,80
handle_help_version_opts(argc, argv, "vacuumdb", help);
! while ((c = getopt_long(argc, argv, "h:p:U:wWeqd:zaFt:fv",
long_options, &optindex)) != -1)
{
switch (c)
{
--- 74,80
handle_help_version_opts(argc, argv, "vacuumdb", help);
! while ((c = getopt_long(argc, argv, "h:p:U:wWeqd:zZaFt:fv",
long_options, &optindex)) != -1)
{
switch (c)
{
--
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] Proposal for 9.1: WAL streaming from WAL buffers
> Well, we're already not waiting for fsync, which is the slowest part. > If there's a performance problem, it may be because FADVISE_DONTNEED > disables kernel buffering so that we're forced to actually read the data > back from disk before sending it on down the wire. Well, that's fairly direct to solve, no? Just disable FADVISE_DONTNEED if walsenders > 0. -- -- Josh Berkus PostgreSQL Experts Inc. http://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] hstore ==> and deprecate =>
Joseph Adams writes:
> To repeat an earlier question (which was in turn repeating an earlier
> question), would it be possible to do one of these, yielding '
> "key"=>"this", "key2"=>"that" '::hstore :
> hstore(key := 'this', key2 := 'that')
> hstore(key => 'this', key2 => 'that')
> hstore(row('this' AS key, 'that' AS key2))
The last of those is probably the easiest to get to. We already have
hstore_from_record:
contrib_regression=# select hstore(row('this', 'that'));
hstore
"f1"=>"this", "f2"=>"that"
(1 row)
and the only thing lacking is an easy way to specify the column names
associated with the anonymous record type. Extending the ROW()
construct with AS labels as suggested above might be a reasonable way.
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] hstore ==> and deprecate =>
On Fri, Jun 11, 2010 at 10:59 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> How about no operator at all? It won't be as cool to read, but
>> consider, the arguments are text and text, not involving any hstore type
>> at all, so whatever operator you choose is in practice blocked from
>> everyone everywhere. No one could ever implement another key/value
>> system that uses a similar interface. Or use the operator for anything
>> else involving strings.
>
> Yeah, that's a good point. Maybe we should just deprecate the operator
> altogether.
>
> 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
>
To repeat an earlier question (which was in turn repeating an earlier
question), would it be possible to do one of these, yielding '
"key"=>"this", "key2"=>"that" '::hstore :
hstore(key := 'this', key2 := 'that')
hstore(key => 'this', key2 => 'that')
hstore(row('this' AS key, 'that' AS key2))
In my opinion, it's important to find a reasonably elegant way to
express hstore literals (rather than something like
hstore(hstore_kvp('key', 'this'), hstore_kvp('key2', 'that')) )
because something so basic shouldn't be so difficult to work with.
It'd be a bonus if there was a general form for arbitrary named
parameters that new functions could opt-in on (in particular,
json_object :-) ).
This type of function could be created by saying something like:
CREATE FUNCTION hstore(NAMED) RETURNS hstore AS ...
-- NAMED would be a new argtype
Also, if a user needs to name a field from a variable, perhaps there
should be a syntax that allows it, such as:
hstore(pg_deref(var) => 'this', pg_deref(var2) => 'that')
If implementing pg_deref would be problematic in general, perhaps it
could initially just be supported in keys of functions like this.
Only if we allow for functions with named parameters in this fashion
would I say +1 for deprecating the => operator from hstore without a
replacement operator like ==> .
Joey Adams
--
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] Command to prune archive at restartpoints
Heikki Linnakangas writes:
> So to clean up all WAL files older than those needed by that base backup,
> you would simply copy-paste that location and call pg_cleanuparchive:
>
> pg_cleanuparchive /walarchive/ 0001002F
Ok, idle though: what about having a superuser-only SRF doing the same?
So that we have internal command for simple case, and SRF for use in
scripts in more complex case.
> Of course, if there's a perl one-liner to do that, we can just put that in
> the docs and don't really need pg_cleanuparchive at all.
psql -c "SELECT * FROM pg_cleanup_archive('0001002F');"
>> Therefore my take on this problem is to provide internal commands here,
>> that maybe wouldn't need to be explicitly passed any argument. If
>> they're internal they certainly can access to the information they need?
>
> You want more flexibility in more advanced cases. Like if you have multiple
> standbys sharing the archive, you only want to remove old WAL files after
> they're not needed by *any* of the standbys anymore. Doing the cleanup
> directly in the archive_cleanup_command would cause the old WAL files to be
> removed prematurely, but you could put a shell script there to store the
> location to a file, and call pg_cleanuparchive with the max() of the
> locations reported by all standby servers.
Yes you still need to support external commands. That was not at all
what I'm proposing: I'm just after having the simple case dead simple to
setup. Like you don't write any script.
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] Error with GIT Repository
On Fri, Jun 11, 2010 at 19:12, Andres Freund wrote: > On Thursday 10 June 2010 19:30:00 Magnus Hagander wrote: >> On Thu, Jun 10, 2010 at 18:20, Stephen Frost wrote: >> > * Andrew Dunstan (and...@dunslane.net) wrote: >> >> I don't see why not. Buildfarm members are going to have to reset their >> >> repos when we finally cut over in a few months. Luckily, this is a >> >> fairly painless operation - blow away the repo and change the config >> >> file and the script will resync as if nothing had happened. >> > >> > Should we stop bothering to offer http://git.postgresql.org then..? Or >> >> No, we should not. >> >> Especially if someone has a clue how to do it. The last time I fixed >> it by runnin repack, but that didn't work this time. I have no clue >> why it's asking for a file that doesn't exist. > Does the repo run 'update-server-info' in some hook? Yup, it runs after every time it pulls from cvs. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Error with GIT Repository
On Thursday 10 June 2010 19:30:00 Magnus Hagander wrote: > On Thu, Jun 10, 2010 at 18:20, Stephen Frost wrote: > > * Andrew Dunstan (and...@dunslane.net) wrote: > >> I don't see why not. Buildfarm members are going to have to reset their > >> repos when we finally cut over in a few months. Luckily, this is a > >> fairly painless operation - blow away the repo and change the config > >> file and the script will resync as if nothing had happened. > > > > Should we stop bothering to offer http://git.postgresql.org then..? Or > > No, we should not. > > Especially if someone has a clue how to do it. The last time I fixed > it by runnin repack, but that didn't work this time. I have no clue > why it's asking for a file that doesn't exist. Does the repo run 'update-server-info' in some hook? Andres -- 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] hstore ==> and deprecate =>
On Jun 11, 2010, at 9:58 AM, Tom Lane wrote: >> That would make it so that the use of => in hstore strings would be less >> consistent. Makes sense to me. > > Less inconsistent, ITYM? But yeah, then we would have no reason to > fiddle with hstore_in, which is good. Yes, sorry. David -- 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] hstore ==> and deprecate =>
"David E. Wheeler" writes: > On Jun 11, 2010, at 7:59 AM, Tom Lane wrote: >> Yeah, that's a good point. Maybe we should just deprecate the operator >> altogether. > That would make it so that the use of => in hstore strings would be less > consistent. Makes sense to me. Less inconsistent, ITYM? But yeah, then we would have no reason to fiddle with hstore_in, which is good. 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] Error with GIT Repository
* Andrew Dunstan (and...@dunslane.net) wrote: > Luxenberg, Scott I. wrote: > >I have been trying to create/run a build farm as part of a project I am > >working on. > > That seems an odd thing to do since we have one ... To clarify, he's setting up a build farm *member*. :) > >However, I have noticed the primary git repostitory, > >git.postgresql.org/git, does not seem to be working. Namely, whenever I > >try to clone the directory, I receive this error: > > > >Error: Unable to find 5e4933c31d3cd2750ee1793efe6eca43055fb273e under > >http://git.postgresql.org/git/postgresql.git > >Cannot obtain needed blob 5e4933c31d3cd2750ee1793efe6eca4305fb273e while > >processing commit c5609c66ce2ee4fdb180be95721252b47f90499 > >Error: fetch failed. > > > >I thought it would be prudent to notify the list so someone could > >possibly check into this. > > > Why are you cloning over http? Here is the best way to clone, which > seems to be working: Unfortunately for us, the port that git uses isn't currently allowed outbound by our corporate firewall. I expect that to be true for other PG users who want git and for some build-farm members, so I think we really need to support git cloning over http. As a side-note, it works just fine from git-hub's http mirror and that's what we've been playing with, but I don't know if we want to recommend that for build-farm members.. Thanks! Stephen smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] hstore ==> and deprecate =>
On Jun 11, 2010, at 7:59 AM, Tom Lane wrote: >> How about no operator at all? It won't be as cool to read, but >> consider, the arguments are text and text, not involving any hstore type >> at all, so whatever operator you choose is in practice blocked from >> everyone everywhere. No one could ever implement another key/value >> system that uses a similar interface. Or use the operator for anything >> else involving strings. > > Yeah, that's a good point. Maybe we should just deprecate the operator > altogether. That would make it so that the use of => in hstore strings would be less consistent. Makes sense to me. Best, David -- 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] LLVM / clang
Takahiro Itagaki writes: > Peter Eisentraut wrote: >> max_locks_per_xact != max_locks_per_xact) >> >> Looks like a bug. > Ah, it should be compared with the same name field in ControlFile. Yeah, obvious typo, please commit. 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] Proposal for 9.1: WAL streaming from WAL buffers
On 06/11/2010 04:47 PM, Tom Lane wrote: Stefan Kaltenbrunner writes: hmm not sure that is what fujii tried to say - I think his point was that in the original case we would have serialized all the operations (first write+sync on the master, network afterwards and write+sync on the slave) and now we could try parallelizing by sending the wal before we have synced locally. Well, we're already not waiting for fsync, which is the slowest part. If there's a performance problem, it may be because FADVISE_DONTNEED disables kernel buffering so that we're forced to actually read the data back from disk before sending it on down the wire. hmm ok - but assuming sync rep we would end up with something like the following(hypotetically assuming each operation takes 1 time unit): originally: write 1 sync 1 network 1 write 1 sync 1 total: 5 whereas in the new case we would basically have the write+sync compete with network+write+sync in parallel(total 3 units) and we would only have to wait for the slower of those two sets of operations instead of the total time of both or am I missing something. Stefan -- 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] hstore ==> and deprecate =>
Peter Eisentraut writes: > How about no operator at all? It won't be as cool to read, but > consider, the arguments are text and text, not involving any hstore type > at all, so whatever operator you choose is in practice blocked from > everyone everywhere. No one could ever implement another key/value > system that uses a similar interface. Or use the operator for anything > else involving strings. Yeah, that's a good point. Maybe we should just deprecate the operator altogether. 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] pg_regress --use-existing does not appear in --help
Hi,
per $SUBJECT.
Cheers,
Jan
diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
index 9de4189..ebdf812 100644
--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -1870,6 +1870,7 @@ help(void)
printf(_("(can be used multiple times to concatenate)\n"));
printf(_(" --dlpath=DIR look for dynamic libraries in DIR\n"));
printf(_(" --temp-install=DIRcreate a temporary installation in DIR\n"));
+ printf(_(" --use-existinguse an existing installation\n"));
printf(_("\n"));
printf(_("Options for \"temp-install\" mode:\n"));
printf(_(" --no-locale use C locale\n"));
--
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] hstore ==> and deprecate =>
Peter Eisentraut writes: >>> Btw., the SQL standard also defines -> for something else, so if you >>> wanted to be really visionary, you could deprecate that one as an >>> operator at the same time. >> >> Ouch. What does it define it to mean? > Similar to C: Dereferencing a reference and accessing a member. But a reference would be a datatype no? So we could just regard that as an ordinary operator. I don't see a reason why it would conflict with use of the same operator name for other datatypes (unlike the situation with =>). 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] Proposal for 9.1: WAL streaming from WAL buffers
Stefan Kaltenbrunner writes: > hmm not sure that is what fujii tried to say - I think his point was > that in the original case we would have serialized all the operations > (first write+sync on the master, network afterwards and write+sync on > the slave) and now we could try parallelizing by sending the wal before > we have synced locally. Well, we're already not waiting for fsync, which is the slowest part. If there's a performance problem, it may be because FADVISE_DONTNEED disables kernel buffering so that we're forced to actually read the data back from disk before sending it on down the wire. 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] Proposal for 9.1: WAL streaming from WAL buffers
On 06/11/2010 04:31 PM, Tom Lane wrote: Fujii Masao writes: In 9.0, walsender reads WAL always from the disk and sends it to the standby. That is, we cannot send WAL until it has been written (and flushed) to the disk. I believe the above statement to be incorrect: walsender does *not* wait for an fsync to occur. I agree with the idea of trying to read from WAL buffers instead of the file system, but the main reason why is that the current behavior makes FADVISE_DONTNEED for WAL pretty dubious. It'd be a good idea to still (artificially) limit replication to not read ahead of the written-out data. ... Since we can write and send WAL simultaneously, in synchronous replication, a transaction commit has only to wait for either of them. So the performance would significantly increase. That performance claim, frankly, is ludicrous. There is no way that round trip network delay plus write+fsync on the slave is faster than local write+fsync. Furthermore, I would say that you are thinking exactly backwards about the requirements for synchronous replication: what that would mean is that transaction commit waits for *both*, not whichever one finishes first. hmm not sure that is what fujii tried to say - I think his point was that in the original case we would have serialized all the operations (first write+sync on the master, network afterwards and write+sync on the slave) and now we could try parallelizing by sending the wal before we have synced locally. Stefan -- 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] Proposal for 9.1: WAL streaming from WAL buffers
Fujii Masao writes: > In 9.0, walsender reads WAL always from the disk and sends it to the standby. > That is, we cannot send WAL until it has been written (and flushed) to the > disk. I believe the above statement to be incorrect: walsender does *not* wait for an fsync to occur. I agree with the idea of trying to read from WAL buffers instead of the file system, but the main reason why is that the current behavior makes FADVISE_DONTNEED for WAL pretty dubious. It'd be a good idea to still (artificially) limit replication to not read ahead of the written-out data. > ... Since we can write and send WAL simultaneously, in synchronous > replication, a transaction commit has only to wait for either of them. So the > performance would significantly increase. That performance claim, frankly, is ludicrous. There is no way that round trip network delay plus write+fsync on the slave is faster than local write+fsync. Furthermore, I would say that you are thinking exactly backwards about the requirements for synchronous replication: what that would mean is that transaction commit waits for *both*, not whichever one finishes first. 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] Proposal for 9.1: WAL streaming from WAL buffers
On Fri, Jun 11, 2010 at 9:57 AM, Fujii Masao wrote: > On Fri, Jun 11, 2010 at 10:22 PM, Robert Haas wrote: >> On Fri, Jun 11, 2010 at 9:14 AM, Fujii Masao wrote: >>> Thought? Comment? Objection? >> >> What happens if the WAL is streamed to the standby and then the master >> crashes without writing that WAL to disk? > > What are you concerned about? > > I think that the situation would be the same as 9.0 from users' perspective. > After failover, the transaction which a client regards as aborted (because > of the crash) might be visible or invisible on new master (i.e., original > standby). For now, we cannot control that. I think the failover case might be OK. But if the master crashes and restarts, the slave might be left thinking its xlog position is ahead of the xlog position on the master. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal for 9.1: WAL streaming from WAL buffers
On Fri, Jun 11, 2010 at 10:22 PM, Robert Haas wrote: > On Fri, Jun 11, 2010 at 9:14 AM, Fujii Masao wrote: >> Thought? Comment? Objection? > > What happens if the WAL is streamed to the standby and then the master > crashes without writing that WAL to disk? What are you concerned about? I think that the situation would be the same as 9.0 from users' perspective. After failover, the transaction which a client regards as aborted (because of the crash) might be visible or invisible on new master (i.e., original standby). For now, we cannot control that. 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] warning message in standby
On Fri, Jun 11, 2010 at 9:43 AM, Simon Riggs wrote: > On Thu, 2010-06-10 at 19:01 +0300, Heikki Linnakangas wrote: >> > >> > What "warning message" are we talking about? All the error cases I can >> > think of in WAL-application are ERROR, or likely even PANIC. >> >> We're talking about a corrupt record (incorrect CRC, incorrect backlink >> etc.), not errors within redo functions. During crash recovery, a >> corrupt record means you've reached end of WAL. In standby mode, when >> streaming WAL from master, that shouldn't happen, and it's not clear >> what to do if it does. PANIC is not a good idea, at least if the server >> uses hot standby, because that only makes the situation worse from >> availability point of view. So we log the error as a WARNING, and keep >> retrying. It's unlikely that the problem will just go away, but we keep >> retrying anyway in the hope that it does. However, it seems that we're >> too aggressive with the retries. > > If my streaming replication stops working, I want to know about it as > soon as possible. WARNING just doesn't cut it. > > This needs some better thought. > > If we PANIC, then surely it will PANIC again when we restart unless we > do something. So we can't do that. But we need to do something better > than > > WARNING there is a bug that will likely cause major data loss > HINT you'll be sacked if you miss this message +1. I was making this same argument (less eloquently) upthread. I particularly like the errhint(). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_upgrade output directory
Why does pg_upgrade create its output directory in the user's home directory (or TMP on Windows)? I should have thought that the current working directory would be a more suitable choice. At the very least there should be an option for where to create it. Also, this location doesn't seem to be referred to at all in the docs. 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] warning message in standby
On Thu, 2010-06-10 at 19:01 +0300, Heikki Linnakangas wrote: > > > > What "warning message" are we talking about? All the error cases I can > > think of in WAL-application are ERROR, or likely even PANIC. > > We're talking about a corrupt record (incorrect CRC, incorrect backlink > etc.), not errors within redo functions. During crash recovery, a > corrupt record means you've reached end of WAL. In standby mode, when > streaming WAL from master, that shouldn't happen, and it's not clear > what to do if it does. PANIC is not a good idea, at least if the server > uses hot standby, because that only makes the situation worse from > availability point of view. So we log the error as a WARNING, and keep > retrying. It's unlikely that the problem will just go away, but we keep > retrying anyway in the hope that it does. However, it seems that we're > too aggressive with the retries. If my streaming replication stops working, I want to know about it as soon as possible. WARNING just doesn't cut it. This needs some better thought. If we PANIC, then surely it will PANIC again when we restart unless we do something. So we can't do that. But we need to do something better than WARNING there is a bug that will likely cause major data loss HINT you'll be sacked if you miss this message -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] warning message in standby
On Fri, Jun 11, 2010 at 9:32 PM, Heikki Linnakangas wrote: > Hmm, right now it doesn't even reconnect when it sees a corrupt record > streamed from the master. It's really pointless to retry in that case, > reapplying the exact same piece of WAL surely won't work. I think it should > disconnect, and then retry reading from archive and pg_xlog, and then retry > streaming again. That's pretty hopeless too, but it's at least theoretically > possible that something went wrong in the transmission and the file in the > archive is fine. Yep, this makes more sense. 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] Proposal for 9.1: WAL streaming from WAL buffers
On Fri, Jun 11, 2010 at 9:14 AM, Fujii Masao wrote: > Thought? Comment? Objection? What happens if the WAL is streamed to the standby and then the master crashes without writing that WAL to disk? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] vacuum_defer_cleanup_age
On Fri, Jun 11, 2010 at 7:25 PM, Heikki Linnakangas wrote: > Yeah, there's clearly a mismatch. I think "Hot Standby" is the right place, > altough you could argue that it should be together with > vacuum_freeze_min_age and vacuum_freeze_table_age too. > > We seem to be missing an entry for "Write-Ahead Log / Hot Standby" in the > config_group_names list in guc.c. hot_standby GUC marked to beling in > WAL_SETTINGS in guc.c. > > What's the policy with that, should all the sections in the sample config > file and docs have a corresponding enum in config_group_names? I guess they > should, but many of them seem to be missing. There's no separate entry in > config_group_names for "Write-Ahead Log / Archiving", "Resource Usage / > Cost-Based Vacuum Delay" and "Resource Usage / Asynchronous Behavior" > either, for example. > > Should I add entries in the enum for all the missing ones? +1. This seems sensible. 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] warning message in standby
On Fri, Jun 11, 2010 at 8:19 AM, Simon Riggs wrote: > On Thu, 2010-06-10 at 09:57 -0400, Robert Haas wrote: >> On Mon, Jun 7, 2010 at 9:21 AM, Fujii Masao >> wrote: >> > When an error is found in the WAL streamed from the master, a >> warning >> > message is repeated without interval forever in the standby. This >> > consumes CPU load very much, and would interfere with read-only >> queries. >> > To fix this problem, we should add a sleep into >> emode_for_corrupt_record() >> > or somewhere? Or we should stop walreceiver and retry to read WAL >> from >> > pg_xlog or the archive? >> >> I ran into this problem at one point, too, but was in the middle of >> trying to investigate a different bug and didn't have time to track >> down what was causing it. > > So you saw a bug, but didn't report it? Why was that? Because it happened while I was in the middle of trying to investigate a different bug, and I didn't know precisely what I had done to cause it. I could have reported it anyway, but I thought it would not have been that helpful to report a bug that I didn't know for sure how to reproduce. Like everyone else here, I am working very hard and do not always have time to follow up on every issue. I had something else weird happen yesterday but I'm not sure I know exactly what I did and I'm not at all sure that it wasn't just pilot error. If I start reporting every pilot error as a bug, I'm going to get laughed out of town, because I make a pilot error *every time* I tried to set up SR w/HS. :-( -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Proposal for 9.1: WAL streaming from WAL buffers
Hi, In 9.0, walsender reads WAL always from the disk and sends it to the standby. That is, we cannot send WAL until it has been written (and flushed) to the disk. This degrades the performance of synchronous replication very much since a transaction commit must wait for the WAL write time *plus* the replication time. The attached patch enables walsender to read data from WAL buffers in addition to the disk. Since we can write and send WAL simultaneously, in synchronous replication, a transaction commit has only to wait for either of them. So the performance would significantly increase. Now three hackers (Zoltan, Simon and me) are planning to develop synchronous replication feature. I'm not sure whose patch will be committed at last. But since the attached patch provides just a infrastructure to optimize SR, it would work fine with any of them together and have a good effect. I'll add the patch into the next CF. AFAIK the ReviewFest will start Jun 15. During that, if you are interested in the patch, please feel free to review it. Also you can get the code change from my git repository: git://git.postgresql.org/git/users/fujii/postgres.git branch: read-wal-buffers >From here I talk about the detail of the change. At first, walsender reads WAL from the disk. If it has reached the current write location (i.e., there is no unsent WAL in the disk), then it attempts to read from WAL buffers. This buffer reading continues until the WAL to send has been purged from WAL buffers. IOW, If WAL buffers is large enough and walsender has been catching up with insertion of WAL, it can read WAL from the buffers forever. Then if WAL to send has purged from the buffers, walsender backs off and tries to read it from the disk. If we can find no WAL to send in the disk, walsender attempts to read WAL from the buffers again. Walsender repeats these operations. The location of the oldest record in the buffers is saved in the shared memory. This location is used to calculate whether the particular WAL is in the buffers or not. To avoid lock contention, walsender reads WAL buffers and XLogCtl->xlblocks without holding neither WALInsertLock nor WALWriteLock. Of course, they might be changed because of buffer replacement while being read. So after reading them, we check that what we read was valid by comparing the location of the read WAL with the location of the oldest record in the buffers. This logic is similar to what XLogRead() does at the end. This feature is required for preventing the performance of synchronous replication from dropping significantly. It can cut the time that a transaction committed on the master takes to become visible on the standby. So, it's also useful for asynchronous replication. Thought? Comment? Objection? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center read_wal_buffers_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] PG 9.1 tentative timeline
On 06/11/2010 02:25 PM, Devrim GÜNDÜZ wrote: On Fri, 2010-06-11 at 19:56 +0800, Pr, Solaiyappan (NSN - IN/Bangalore) wrote: Also, is there any synchronous replication patch planned for the PostgreSQL 9.0 version? Cybertec announced new version of Cybercluster, which includes sync replication -- I haven't tested it though. look at this thread for more info http://archives.postgresql.org/message-id/b058e23346b050bd0fa2d3981af6da58.squir...@internal.cybertec.at Andrea -- 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] SR slaves and .pgpass
On Fri, Jun 11, 2010 at 7:14 PM, Heikki Linnakangas wrote: > On 09/06/10 08:24, Fujii Masao wrote: >> >> On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstan >> wrote: >>> >>> There is precedent for .pgpass being a bit ambiguous. See the way >>> "localhost" is used. >> >> OK. The attached patch allows us to use "replication" in the database >> field of the .pgpass file, for the replication connection. > > Thanks, committed with some rewording of the docs and comments. I hope I > made them better, not worse. Yep. Thank a lot. 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] PG 9.1 tentative timeline
Devrim GÜNDÜZ wrote: On Fri, 2010-06-11 at 19:56 +0800, Pr, Solaiyappan (NSN - IN/Bangalore) wrote: Also, is there any synchronous replication patch planned for the PostgreSQL 9.0 version? Cybertec announced new version of Cybercluster, which includes sync replication -- I haven't tested it though. that one is basically 9.0beta + the sync rep patch posted on the list - not something you would want to use in production... Stefan -- 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] warning message in standby
On 11/06/10 07:18, Fujii Masao wrote:
On Fri, Jun 11, 2010 at 1:01 AM, Heikki Linnakangas
wrote:
We're talking about a corrupt record (incorrect CRC, incorrect backlink
etc.), not errors within redo functions. During crash recovery, a corrupt
record means you've reached end of WAL. In standby mode, when streaming WAL
from master, that shouldn't happen, and it's not clear what to do if it
does. PANIC is not a good idea, at least if the server uses hot standby,
because that only makes the situation worse from availability point of view.
So we log the error as a WARNING, and keep retrying. It's unlikely that the
problem will just go away, but we keep retrying anyway in the hope that it
does. However, it seems that we're too aggressive with the retries.
Right. The attached patch calms down the retries: if we found an invalid
record while streaming WAL from master, we sleep for 5 seconds (needs to
be reduced?) before retrying to replay the record which is in the same
location where the invalid one was found. Comments?
Hmm, right now it doesn't even reconnect when it sees a corrupt record
streamed from the master. It's really pointless to retry in that case,
reapplying the exact same piece of WAL surely won't work. I think it
should disconnect, and then retry reading from archive and pg_xlog, and
then retry streaming again. That's pretty hopeless too, but it's at
least theoretically possible that something went wrong in the
transmission and the file in the archive is fine.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--- src/backend/access/transam/xlog.c 10 Jun 2010 08:13:50 - 1.422
+++ src/backend/access/transam/xlog.c 11 Jun 2010 12:30:36 -
@@ -9271,6 +9271,22 @@
if (WalRcvInProgress())
{
/*
+ * If we find an invalid record in the WAL streamed from
+ * master, something is seriously wrong. There's little
+ * chance that the problem will just go away, but PANIC
+ * is not good for availability either, especially in
+ * hot standby mode. Disconnect, and retry from
+ * archive/pg_xlog again. The WAL in the archive should
+ * be identical to what was streamed, so it's unlikely
+ * that it helps, but one can hope...
+ */
+ if (failedSources & XLOG_FROM_STREAM)
+ {
+ ShutdownWalRcv();
+ continue;
+ }
+
+ /*
* While walreceiver is active, wait for new WAL to arrive
* from primary.
*/
--
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] PG 9.1 tentative timeline
On Fri, 2010-06-11 at 19:56 +0800, Pr, Solaiyappan (NSN - IN/Bangalore) wrote: > Also, is there any synchronous replication patch planned for the > PostgreSQL 9.0 version? Cybertec announced new version of Cybercluster, which includes sync replication -- I haven't tested it though. -- Devrim GÜNDÜZ PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [HACKERS] warning message in standby
On Thu, 2010-06-10 at 09:57 -0400, Robert Haas wrote: > On Mon, Jun 7, 2010 at 9:21 AM, Fujii Masao > wrote: > > When an error is found in the WAL streamed from the master, a > warning > > message is repeated without interval forever in the standby. This > > consumes CPU load very much, and would interfere with read-only > queries. > > To fix this problem, we should add a sleep into > emode_for_corrupt_record() > > or somewhere? Or we should stop walreceiver and retry to read WAL > from > > pg_xlog or the archive? > > I ran into this problem at one point, too, but was in the middle of > trying to investigate a different bug and didn't have time to track > down what was causing it. So you saw a bug, but didn't report it? Why was that? I find it amazing that such an obvious problem wasn't covered in testing, nor do we have a clear plan in the design for handling it. How many other things are known about but not reported? If anybody has bugs, report them now. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.1 tentative timeline
* Pr, Solaiyappan (NSN - IN/Bangalore) (solaiyappan...@nsn.com) wrote: > I understand this is very early to ask this.. but, is there any tentative > timeline has been planned / available for the PostgreSQL 9.1 release, like > for the alpha or beta releases before the general release? The tentative timeline is "more-or-less the same as 9.0 went". That is to say, we're hopeful to start a commitfest July 15th, finish by Auguet 15th, cut alpha1, then switch to GIT for the main repo, and start the next commitfets September 15th. All that said, this was the discussion at PGCon a few weeks ago on the assumption we were going to get 9.0 out sometime in the July timeframe.. I'm slightly less optomistic about that at this particular time. :) > Also, is there any synchronous replication patch planned for the PostgreSQL > 9.0 version? No. Sync-Rep didn't make it in for 9.0 and we're way, way, wa past feature freeze on that. The hope/plan is to get it included in 9.1 (released "summer 2011", hopefully :). Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] server authentication over Unix-domain sockets
* Magnus Hagander (mag...@hagander.net) wrote: > On Fri, Jun 11, 2010 at 14:07, Stephen Frost wrote: > > I definitely like the idea but I dislike requiring the user to do > > something to implement it. Thinking about how packagers might want to > > use it, could we make it possible to build it defaulted to a specific > > value (eg: 'postgres' on Debian) and allow users a way to override > > and/or unset it? > > Well, even if we don't put that in, the packager could export a global > PGREQUIREPEER environment variable. Yea, no, that's a crappy solution, sorry. :) I've been down that road with people trying to monkey with /etc/bashrc; oh wait, not everyone uses bash, and having every package screw with that stuff is equally horrible. Admittedly, in this specific case, Debian could implement what you're talking about in it's wrapper system, maybe, but I still don't like it and if people don't use the wrapper (I can imagine cases why that might happen, tho I havn't ever had to myself), they wouldn't get the benefit.. Thanks, Stephen signature.asc Description: Digital signature
[HACKERS] PG 9.1 tentative timeline
Hi, I understand this is very early to ask this.. but, is there any tentative timeline has been planned / available for the PostgreSQL 9.1 release, like for the alpha or beta releases before the general release? Also, is there any synchronous replication patch planned for the PostgreSQL 9.0 version? Regards, Solai
Re: [HACKERS] server authentication over Unix-domain sockets
On Fri, Jun 11, 2010 at 14:07, Stephen Frost wrote: > * Peter Eisentraut (pete...@gmx.net) wrote: >> The patch needs some portability work and possible refactoring because >> of that, but before I embark on that, comments on the concept? > > I definitely like the idea but I dislike requiring the user to do > something to implement it. Thinking about how packagers might want to > use it, could we make it possible to build it defaulted to a specific > value (eg: 'postgres' on Debian) and allow users a way to override > and/or unset it? Well, even if we don't put that in, the packager could export a global PGREQUIREPEER environment variable. > Having the option wouldn't do much unless users know of it and use it > and it strikes that will very often not be the case. > > I'm impartial towards whatever PG wants to do with the default, just so > long as packagers can override it and set it to something specific. > Also, to that end, it's got to be name-based. Exim in Debian did > something similar and actually tried to force a particular UID.. that > was horrid. :) On Debian, at least, the user is almost always > 'postgres', but the UID will vary depending on exactly when the packages > were installed (before or after other system-user-creating packages). Oh yes, absolutely name-based. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] server authentication over Unix-domain sockets
* Peter Eisentraut (pete...@gmx.net) wrote: > The patch needs some portability work and possible refactoring because > of that, but before I embark on that, comments on the concept? I definitely like the idea but I dislike requiring the user to do something to implement it. Thinking about how packagers might want to use it, could we make it possible to build it defaulted to a specific value (eg: 'postgres' on Debian) and allow users a way to override and/or unset it? Having the option wouldn't do much unless users know of it and use it and it strikes that will very often not be the case. I'm impartial towards whatever PG wants to do with the default, just so long as packagers can override it and set it to something specific. Also, to that end, it's got to be name-based. Exim in Debian did something similar and actually tried to force a particular UID.. that was horrid. :) On Debian, at least, the user is almost always 'postgres', but the UID will vary depending on exactly when the packages were installed (before or after other system-user-creating packages). Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Functional dependencies and GROUP BY
On tis, 2010-06-08 at 10:05 -0400, Tom Lane wrote: > Perhaps the correct fix would be to mark stored query trees as having > a > dependency on the index, so that dropping the index/constraint would > force a drop of the rule too. Just pushing the check to plan time, as > I suggested yesterday, isn't a very nice fix because it would result > in the rule unexpectedly starting to fail at execution. There are actually pretty explicit instructions about this in the SQL standard: 4) If QS is a that contains an implicit or explicit and that contains a column reference to a column C in its that is not contained in an aggregated argument of a , and if G is the set of grouping columns of QS, and if the table constraint TC is needed to conclude that G ↦ C is a known functional dependency in QS, then QS is said to be dependent on TC. 5) If V is a view that contains a that is dependent on a table constraint TC, then V is said to be dependent on TC. So the dependency between the view/rule and the constraint/index needs to be stored in the dependency system, and RESTRICT/CASCADE will take effect. -- 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] Functional dependencies and GROUP BY
On tis, 2010-06-08 at 10:21 -0400, Tom Lane wrote: > The question is why bother to recognize *any* cases of this form. > I find it really semantically ugly to have the parser effectively > doing one deduction of this form when the main engine for that type > of deduction is elsewhere; so unless there is a really good argument > why we have to do this case (and NOT "it was pretty easy"), I don't > want to do it. Yeah, I'm not horribly attached to it. I began to structure the code to support multiple kinds of checks, and at the end only two kinds were reasonably doable and useful. We can remove it if no one is interested in it, which appears to be the case. -- 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] server authentication over Unix-domain sockets
On Sun, May 30, 2010 at 13:00, Peter Eisentraut wrote: > It has been discussed several times in the past that there is no way for > a client to authenticate a server over Unix-domain sockets. So > depending on circumstances, a local user could easily insert his own > server and collect passwords and data. Suggestions for possible > remedies included: > > You can put the socket file in a sufficiently write-protected directory. > But that would strongly deviate from the default setup, and anyway the > client still cannot readily verify that the server is the right one. > > You can also run SSL over Unix-domain sockets. This is currently > disabled in the code, but it would work just fine. But it's obviously > kind of awkward, and the connection overhead was noticeable in tests. > > Then it was suggested to use the local "ident" mechanism in reverse, so > the client could verify what user the server runs under. I have > implemented a prototype of this. You can put, e.g., > > requirepeer=postgres > > into the connection parameters, and the connection will be rejected > unless the process at the other end of the socket is running as > postgres. > > The patch needs some portability work and possible refactoring because > of that, but before I embark on that, comments on the concept? > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > > -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] server authentication over Unix-domain sockets
On Sun, May 30, 2010 at 13:00, Peter Eisentraut wrote: > It has been discussed several times in the past that there is no way for > a client to authenticate a server over Unix-domain sockets. So > depending on circumstances, a local user could easily insert his own > server and collect passwords and data. Suggestions for possible > remedies included: > > You can put the socket file in a sufficiently write-protected directory. > But that would strongly deviate from the default setup, and anyway the > client still cannot readily verify that the server is the right one. > > You can also run SSL over Unix-domain sockets. This is currently > disabled in the code, but it would work just fine. But it's obviously > kind of awkward, and the connection overhead was noticeable in tests. > > Then it was suggested to use the local "ident" mechanism in reverse, so > the client could verify what user the server runs under. I have > implemented a prototype of this. You can put, e.g., > > requirepeer=postgres > > into the connection parameters, and the connection will be rejected > unless the process at the other end of the socket is running as > postgres. > > The patch needs some portability work and possible refactoring because > of that, but before I embark on that, comments on the concept? I like it. ISTM like something that would be very useful - an easy way to get a fair amount of extra security in the case of local connections, at almost zero cost. Just an "export PGREQUIREPEER=postgres" in .profile goes a long way :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] hstore ==> and deprecate =>
On tis, 2010-06-08 at 15:38 -0400, Robert Haas wrote:
> I'm happy to do whatever the consensus is. I thought it would be
> easier to remember if the two operators were spelled at least somewhat
> similarly, but I just work here.
How about no operator at all? It won't be as cool to read, but
consider, the arguments are text and text, not involving any hstore type
at all, so whatever operator you choose is in practice blocked from
everyone everywhere. No one could ever implement another key/value
system that uses a similar interface. Or use the operator for anything
else involving strings.
Why not just write:
hstore('this', 'that')
hstore(key := 'this', value := 'that')
--
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] hstore ==> and deprecate =>
On fre, 2010-06-11 at 07:10 -0400, Robert Haas wrote: > On Fri, Jun 11, 2010 at 2:51 AM, Peter Eisentraut wrote: > > On tis, 2010-06-08 at 16:17 -0400, Robert Haas wrote: > >> > Perhaps > >> > -> > >> > >> That's already in use to mean something else. > > > > Btw., the SQL standard also defines -> for something else, so if you > > wanted to be really visionary, you could deprecate that one as an > > operator at the same time. > > Ouch. What does it define it to mean? Similar to C: Dereferencing a reference and accessing a member. -- 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] hstore ==> and deprecate =>
On Fri, Jun 11, 2010 at 2:51 AM, Peter Eisentraut wrote: > On tis, 2010-06-08 at 16:17 -0400, Robert Haas wrote: >> > Perhaps >> > -> >> >> That's already in use to mean something else. > > Btw., the SQL standard also defines -> for something else, so if you > wanted to be really visionary, you could deprecate that one as an > operator at the same time. Ouch. What does it define it to mean? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] vacuum_defer_cleanup_age
On 11/06/10 05:36, Fujii Masao wrote: vacuum_defer_cleanup_age is categorized as "Statement Behavior" parameter in the document. On the other hand, it's categorized as "Hot Standby" one in postgresql.conf. Why do we need to do so? Yeah, there's clearly a mismatch. I think "Hot Standby" is the right place, altough you could argue that it should be together with vacuum_freeze_min_age and vacuum_freeze_table_age too. We seem to be missing an entry for "Write-Ahead Log / Hot Standby" in the config_group_names list in guc.c. hot_standby GUC marked to beling in WAL_SETTINGS in guc.c. What's the policy with that, should all the sections in the sample config file and docs have a corresponding enum in config_group_names? I guess they should, but many of them seem to be missing. There's no separate entry in config_group_names for "Write-Ahead Log / Archiving", "Resource Usage / Cost-Based Vacuum Delay" and "Resource Usage / Asynchronous Behavior" either, for example. Should I add entries in the enum for all the missing ones? -- 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] SR slaves and .pgpass
On 09/06/10 08:24, Fujii Masao wrote: On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstan wrote: There is precedent for .pgpass being a bit ambiguous. See the way "localhost" is used. OK. The attached patch allows us to use "replication" in the database field of the .pgpass file, for the replication connection. Thanks, committed with some rewording of the docs and comments. I hope I made them better, not worse. -- 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] Error with GIT Repository
> Why are you cloning over http? Me too I've used http, since I'm behind a proxy and I couldn't find a "simple" way of having the git:// method working behind a proxy... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
