Hello Hongchan,
You need go to through following steps :
1. Debug Perspective = Run = Debug Configuration
2. On left side of menu you can see C/C++ Attach to Application
3. Right click on C/C++ Attach to Application and create new debug
configuration,
4. Set Project, Build
Looking at the changes to StartupMultiXact, you're changing the locking
so that both MultiXactOffsetControlLock and MultiXactMemberControlLock
are acquire first before changing anything. Why? Looking at the other
functions in that file, all others that access both files are happy to
acquire one
Looking at the changes to StartupMultiXact, you're changing the locking
so that both MultiXactOffsetControlLock and MultiXactMemberControlLock
are acquired first before changing anything. Why? Looking at the other
functions in that file, all others that access both files are happy to
acquire one
On Mon, 2009-09-28 at 10:44 -0700, John Naylor wrote:
+
errmsg(statement FETCH returns more rows.),
+
errhint(Multirows fetch are not allowed in PL/pgSQL.)));
This might sound better as statement FETCH returns multiple rows.,
errmsg should be without period.
and Multirow FETCH is not
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Stephen Frost wrote:
The scenario you outline could happen without SE-PG, couldn't it?
Specifically, if a user makes a connection, creates a temporary table,
and then their rights to create temporary tables are revoked? What
should happen in
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The attached patch eliminates permission checks in FindConversion()
and EnableDisableRule(), because these are nonsense or redundant.
It is an separated issue from the ac_*() routines.
For now, we decided not to touch these stuffs in the
Peter Eisentraut pete...@gmx.net writes:
On Mon, 2009-09-28 at 10:44 -0700, John Naylor wrote:
+ errmsg(statement FETCH returns more rows.),
+ errhint(Multirows fetch are not allowed in PL/pgSQL.)));
This might sound better as statement FETCH returns multiple rows.,
errmsg should be
And here's the last necessary bit, which is pg_dump support for all
this.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
*** src/bin/pg_dump/pg_dumpall.c 11 Jun 2009 14:49:07 - 1.126
---
On Tue, Sep 29, 2009 at 04:28:57PM -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Tue, 2009-09-29 at 12:01 -0400, Tom Lane wrote:
The bigger question is exactly how we expect this stuff to interact with
pg_regress' --no-locale switch. We already do clear all these
Roger Leigh wrote:
Here we just force the locale to C. This does have the disadvantage
that --no-locale is made redundant, and any tests which are dependent
upon locale (if any?) will be run in the C locale.
That is not a solution. We have not that long ago gone to some lengths
to
Andrew Dunstan and...@dunslane.net writes:
Roger Leigh wrote:
Here we just force the locale to C. This does have the disadvantage
that --no-locale is made redundant, and any tests which are dependent
upon locale (if any?) will be run in the C locale.
That is not a solution.
Right. I think
On Tue, Sep 29, 2009 at 04:32:49PM -0400, Tom Lane wrote:
Roger Leigh rle...@codelibre.net writes:
C locale means POSIX behavior and nothing but.
Indeed it does. However, making LC_CTYPE be UTF-8 rather than
ASCII is both possible and still strictly conforming to the
letter of the
Andrew Dunstan wrote:
Roger Leigh wrote:
Here we just force the locale to C. This does have the disadvantage
that --no-locale is made redundant, and any tests which are dependent
upon locale (if any?) will be run in the C locale.
That is not a solution. We have not that long ago
Roger Leigh rle...@codelibre.net writes:
The language in SUSv2 in fact explicitly states that this is
allowed. In fact, I've seen documentation that some UNIX systems such
as HPUX already do have a UTF-8 C locale as an option.
I don't argue with the concept of a C.UTF8 locale --- in fact I
Andrew Dunstan and...@dunslane.net writes:
Thinking about this some more, ISTM a much better way of approaching it
would be to provide a flag for psql to turn off the fancy formatting,
and have pg_regress use that flag.
Yeah, that's not a bad idea. There are likely to be other client
Robert Haas wrote:
- Hot Standby and Streaming Replication are both huge new features in
this CommitFest, and there seems to be a fair amount of activity
around both patches. Heikki previously expressed optimism about
getting Hot Standby done this CommitFest, but I am not sure whether he
is
Alvaro Herrera alvhe...@commandprompt.com writes:
And here's the last necessary bit, which is pg_dump support for all
this.
+ /* Dump role/database settings */
+ if (!tablespaces_only)
+ {
+ if (server_version = 80500)
+
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
OTOH, I'd hate to hold the commitfest hostage for that. Perhaps it
should be returned to author at this point, I should move on to other
patches to get the commitfest closed ASAP, and continue reviewing and
polishing that right
Regarding this in InitStandbyDelayTimers:
+ /*
+* If replication delay is enormously huge, just treat that as
+* zero and work up from there. This prevents us from acting
+* foolishly when replaying old log files.
+*/
+ if (*currentDelay_ms 0)
+ *currentDelay_ms = 0;
+
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
And here's the last necessary bit, which is pg_dump support for all
this.
+ /* Dump role/database settings */
+ if (!tablespaces_only)
+ {
+ if (server_version =
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
And here's the last necessary bit, which is pg_dump support for all
this.
+ /* Dump role/database settings */
+ if (!tablespaces_only)
+ {
+ if (server_version =
On Wed, Sep 30, 2009 at 11:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
OTOH, I'd hate to hold the commitfest hostage for that. Perhaps it
should be returned to author at this point, I should move on to other
patches to get the
On Wed, Sep 30, 2009 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Thinking about this some more, ISTM a much better way of approaching it
would be to provide a flag for psql to turn off the fancy formatting,
and have pg_regress use that flag.
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Hmm ... I would kind of think that --roles-only should suppress this too.
Otherwise you're going to be dumping commands that might refer to
nonexistent databases.
Hmm. The problem I have with this idea is that the only way
Robert Haas wrote:
On Wed, Sep 30, 2009 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Thinking about this some more, ISTM a much better way of approaching it
would be to provide a flag for psql to turn off the fancy formatting,
and have
Tom Lane wrote:
I was just poking at this.
Thanks for trying it out.
It seems to need rather a lot of
editorialization (eg to fix the lack of consistency about whether
nonstandard headers have configure tests, or bother to make use of the
tests that did get added).
I've now added tests
Robert Haas wrote:
- There is one dblink pach left over from last CommitFest. Joe Conway
was going to review it the weekend of July 18th-19th, but that didn't
end up happening and so that patch is still waiting. We might be able
to find someone else to review it, but I'm not sure whether
Robert Haas wrote:
On Wed, Sep 30, 2009 at 11:36 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
OTOH, I'd hate to hold the commitfest hostage for that. Perhaps it
should be returned to author at this point, I should move on to other
Joe Conway m...@joeconway.com writes:
Robert Haas wrote:
- There is one dblink pach left over from last CommitFest. Joe Conway
was going to review it the weekend of July 18th-19th, but that didn't
end up happening and so that patch is still waiting. We might be able
to find someone else to
Robert Haas robertmh...@gmail.com writes:
... (and many of the more
significant remaining patches look like they are right up Tom's alley
anyway).
FWIW, if left to my own devices I will eventually get to everything
except the dblink, ecpg, and encoding/win32 patches. I don't intend
to touch
On Wed, Sep 30, 2009 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joe Conway m...@joeconway.com writes:
Robert Haas wrote:
- There is one dblink pach left over from last CommitFest. Joe Conway
was going to review it the weekend of July 18th-19th, but that didn't
end up happening and so
Robert Haas robertmh...@gmail.com wrote:
Peter Eisentraut pete...@gmx.net wrote:
On Sun, 2009-09-20 at 22:54 -0400, Robert Haas wrote:
It seems like there is some support for what this patch is trying
to do, but much disagreement about the details of how to get
there. Where do we go from
On Wed, Sep 30, 2009 at 12:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
... (and many of the more
significant remaining patches look like they are right up Tom's alley
anyway).
FWIW, if left to my own devices I will eventually get to everything
except
On Wed, Sep 30, 2009 at 10:34 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
And here's the last necessary bit, which is pg_dump support for all
this.
I think it would be helpful if you could post ONE patch with all the
changes and all the new files in the diff. AIUI, the patch is now
Robert Haas wrote:
On Wed, Sep 30, 2009 at 12:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
... (and many of the more
significant remaining patches look like they are right up Tom's alley
anyway).
FWIW, if left to my own devices I will
On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
Thinking about this some more, ISTM a much better way of approaching it
would be to provide a flag for psql to turn off the fancy formatting,
and have pg_regress use that flag.
Well, it might not be a bad idea, but adding a feature
On Wed, 2009-09-30 at 12:06 -0400, Robert Haas wrote:
On Wed, Sep 30, 2009 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Thinking about this some more, ISTM a much better way of approaching it
would be to provide a flag for psql to turn off the
Peter Eisentraut wrote:
On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
Thinking about this some more, ISTM a much better way of approaching it
would be to provide a flag for psql to turn off the fancy formatting,
and have pg_regress use that flag.
Well, it might not be a
On Wed, 2009-09-30 at 11:58 -0500, Kevin Grittner wrote:
Right. It seems that, in addition to the above, there also remains
some disagreement about:
(1) how much checking the script should do to provide error messages
and exit codes which target the specific problems versus generic I'm
Robert Haas wrote:
On Wed, Sep 30, 2009 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joe Conway m...@joeconway.com writes:
Robert Haas wrote:
- There is one dblink pach left over from last CommitFest. Joe Conway
was going to review it the weekend of July 18th-19th, but that didn't
end up
At 2009-09-30 11:16:57 -0500, stef-l...@memberwebs.com wrote:
I've now added tests for sys/ioctl.h and net/if.h even though these
headers seemed to be common to all the unixes investigated.
Thanks. I've marked this ready for committer now.
FWIW, there are checks for various bad netmasks. I
Andrew Dunstan escribió:
Peter Eisentraut wrote:
On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
Thinking about this some more, ISTM a much better way of
approaching it would be to provide a flag for psql to turn off
the fancy formatting, and have pg_regress use that flag.
On Wed, Sep 30, 2009 at 18:34, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
... (and many of the more
significant remaining patches look like they are right up Tom's alley
anyway).
FWIW, if left to my own devices I will eventually get to everything
except the
Magnus Hagander escribió:
On Wed, Sep 30, 2009 at 18:34, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
... (and many of the more
significant remaining patches look like they are right up Tom's alley
anyway).
FWIW, if left to my own devices I will
On Wed, Sep 30, 2009 at 1:27 PM, Peter Eisentraut pete...@gmx.net wrote:
On Wed, 2009-09-30 at 12:06 -0400, Robert Haas wrote:
On Wed, Sep 30, 2009 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Thinking about this some more, ISTM a much better way
On Wed, Sep 30, 2009 at 01:30:17PM -0400, Andrew Dunstan wrote:
Peter Eisentraut wrote:
On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
Thinking about this some more, ISTM a much better way of approaching
it would be to provide a flag for psql to turn off the fancy
On Mon, 2009-09-14 at 18:58 +0900, Itagaki Takahiro wrote:
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp wrote:
Ok, the attached patch implements standard-compliant version of
column trigger.
Here is an updated version of column-level trigger patch.
I forgot to adjust
On Wed, 2009-09-30 at 14:02 -0400, Alvaro Herrera wrote:
All scripts I've seen parsing psql output use unaligned, undecorated
mode. I have yet to see one messing with the |'s.
Plus, we would have broken that with the : continuation lines.
--
Sent via pgsql-hackers mailing list
Hi all,
because it seems like merging privileges seems to be acceptable for most
(although I am not sure I like it, but I don't have better solution for
managing conflicts), I changed the patch to do just that.
Also I think I addressed all other problems pointed out by Tom. Namely I
added
Magnus Hagander mag...@hagander.net writes:
I can certainly review the win32 encoding patch, but I was rather
hoping for some comments from others on if we're interested in a win32
only solution, or if we want something more generic. Should we just go
with the win32-only one for now?
That was
Robert Haas robertmh...@gmail.com writes:
The way it works right now (and has worked for the last 5 years or
more) is reliable, familiar, and, at least IME, bullet-proof. I don't
even see a good case for changing the default, let alone not providing
a way to retreat to the old behavior.
This
On Wed, Sep 30, 2009 at 21:38, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
I can certainly review the win32 encoding patch, but I was rather
hoping for some comments from others on if we're interested in a win32
only solution, or if we want something more
Andrew Gierth and...@tao11.riddles.org.uk writes:
Hstore patch incorporating changes as previously discussed.
In addition the requested new features of conversions to and from
array formats have been added (with docs).
Applied with some mostly-cosmetic editorialization.
Tom Lane escribió:
BTW, have we thought much about the simplest possible solution,
which is to not have the view? How badly do we need it? Seems
like dropping the functionality into a psql \d command might be
a viable alternative.
FWIW I came up with a preliminary patch for a new psql
Alvaro Herrera alvhe...@commandprompt.com writes:
FWIW I came up with a preliminary patch for a new psql command \dus that
shows settings. It takes a pattern that's used to constrain on roles.
Thus there is no way to view settings for a database. If there's a need
for that we could use
On Sep 30, 2009, at 12:52 PM, Tom Lane wrote:
Applied with some mostly-cosmetic editorialization.
And there was much rejoicing…
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Joe Conway m...@joeconway.com writes:
The issue is not so much technical as it is philosophical.
The patch basically forces all use of libpq by dblink to be asynchronous
(internally) so that a cancel can be sensed and passed down to the
remote side and everything cleaned up. Possibly the
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
FWIW I came up with a preliminary patch for a new psql command \dus that
shows settings. It takes a pattern that's used to constrain on roles.
Thus there is no way to view settings for a database. If there's a need
for
David E. Wheeler da...@kineticode.com writes:
On Sep 30, 2009, at 12:52 PM, Tom Lane wrote:
Applied with some mostly-cosmetic editorialization.
And there was much rejoicing
... except in the buildfarm. Must be some platform dependency we both
missed ...
regards, tom
Peter Eisentraut pete...@gmx.net writes:
On Wed, 2009-09-30 at 14:02 -0400, Alvaro Herrera wrote:
All scripts I've seen parsing psql output use unaligned, undecorated
mode. I have yet to see one messing with the |'s.
Plus, we would have broken that with the : continuation lines.
Only for
decibel deci...@decibel.org wrote:
*any* step that improves dealing with table bloat is extremely
welcome, as right now you're basically stuck rebuilding the table.
+1
Although, possibly more irritating than actually rebuilding it is
evaluating borderline bloat situations to determine if
Roger Leigh rle...@codelibre.net writes:
On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
Thinking about this some more, ISTM a much better way of approaching
it would be to provide a flag for psql to turn off the fancy
formatting, and have pg_regress use that flag.
The attached
Tom == Tom Lane t...@sss.pgh.pa.us writes:
And there was much rejoicing
Tom ... except in the buildfarm. Must be some platform dependency
Tom we both missed ...
oops
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
daveg da...@sonic.net wrote:
On Tue, Sep 22, 2009 at 10:27:19AM +0530, Jeevan Chalke wrote:
It seems that Oracle reads formatting string from right-to-left.
Here are few results:
('number','format') == Oracle PG
('34,50','999,99') ==
Kevin Grittner kevin.gritt...@wicourts.gov writes:
daveg da...@sonic.net wrote:
On Tue, Sep 22, 2009 at 10:27:19AM +0530, Jeevan Chalke wrote:
It seems that Oracle reads formatting string from right-to-left.
It seems worse to to give a wrong answer silently then to throw an
error. What we
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
daveg da...@sonic.net wrote:
On Tue, Sep 22, 2009 at 10:27:19AM +0530, Jeevan Chalke wrote:
It seems that Oracle reads formatting string from right-to-left.
It seems worse to to give a wrong answer
On Wed, 2009-09-30 at 19:08 -0500, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
daveg da...@sonic.net wrote:
On Tue, Sep 22, 2009 at 10:27:19AM +0530, Jeevan Chalke wrote:
It seems that Oracle reads formatting string from
Joshua D. Drake j...@commandprompt.com wrote:
On Wed, 2009-09-30 at 19:08 -0500, Kevin Grittner wrote:
I don't currently have access to an Oracle database
Just download developer edition?
[quick google search]
Looks like that would do it. Thanks.
-Kevin
--
Sent via pgsql-hackers
Peter Eisentraut pete...@gmx.net wrote:
What is the purpose of the new pg_get_triggerdef() variant? OK, the
parameter name pretty_bool gives a hint, but what does this have to do
with column triggers? Maybe you could try to explain this in more
detail. Ideally split the patch into two:
Alvaro Herrera alvhe...@commandprompt.com wrote:
Hmm, so it works to specify LIKE t1 INCLUDING COMMENTS EXCLUDING COMMENTS?
Only last specifer is applied, which is the same behavior as of now.
EXCLUDING is typically useless because all of the default values are
EXCLUDING, but INCLUDING ALL
Stephen Frost wrote:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Stephen Frost wrote:
The scenario you outline could happen without SE-PG, couldn't it?
Specifically, if a user makes a connection, creates a temporary table,
and then their rights to create temporary tables are revoked? What
Peter Eisentraut pete...@gmx.net wrote:
If you want a pretty option on pg_get_triggerdef(), you could nowadays
also implement that via a parameter default value instead of a second
function.
OK, I'll rewrite it to use default parameter.
I tried to remove pg_get_triggerdef_ext() and add
Joe Conway m...@joeconway.com wrote:
The patch basically forces all use of libpq by dblink to be asynchronous
(internally) so that a cancel can be sensed and passed down to the
remote side and everything cleaned up. Possibly the right thing to do,
but dblink already allows the use of async
Stef Walter stef-l...@memberwebs.com writes:
[ postgres-hba-samenet-8.patch ]
Applied with some mostly-cosmetic editorialization.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Now that the samehost/samenet patch is in, I wonder if it wouldn't be
a good idea to replace this part of the default pg_hba.conf file:
# IPv4 local connections:
hostall all 127.0.0.1/32 @authmethod@
# IPv6 local connections:
hostall all ::1/128
Magnus Hagander mag...@hagander.net wrote:
I can certainly review the win32 encoding patch, but I was rather
hoping for some comments from others on if we're interested in a win32
only solution, or if we want something more generic. Should we just go
with the win32-only one for now?
Yes,
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Yes, it is reasonable both of MAC/DAC to handle temporary schema as
an exception of access controls on schemas.
Great.
I know it doesn't hide existence of major database objects. Depending
on the situation, there might be other
On Thu, Sep 17, 2009 at 5:08 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Walreceiver is really a slave to the startup process. The startup
process decides when it's launched, and it's the startup process that
then waits for it to advance. But the way it's set up at the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Now that the samehost/samenet patch is in, I wonder if it wouldn't be
a good idea to replace this part of the default pg_hba.conf file:
# IPv4 local connections:
hostall all 127.0.0.1/32 @authmethod@
# IPv6 local
On Wed, Sep 30, 2009 at 10:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The advantage of this is that connections made with -h machine_name
instead of -h localhost would work without customization. I can't
see any disadvantage to it. Making the change now would also give
us an opportunity to
Euler Taveira de Oliveira eu...@timbira.com wrote:
But there are some confusions in postgres; ReadBufferCount and
BufferHitCount are used for get and hit, but heap_blks_read
and heap_blks_hit are used for read and hit in pg_statio_all_tables.
I see. :(
I fixed the confusions of get, hit
On 09/30/2009 10:08 PM, Tom Lane wrote:
Now that the samehost/samenet patch is in, I wonder if it wouldn't be
a good idea to replace this part of the default pg_hba.conf file:
# IPv4 local connections:
hostall all 127.0.0.1/32 @authmethod@
# IPv6 local connections:
Stephen Frost wrote:
I know it doesn't hide existence of major database objects. Depending
on the situation, there might be other information that could be leaked.
I realize that's not the case here, but I still want to catch and
document any behavioral changes, even if it's clear they
Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The attached patch eliminates permission checks in FindConversion()
and EnableDisableRule(), because these are nonsense or redundant.
It is an separated issue from the ac_*() routines.
For now, we decided not to
Stephen Frost sfr...@snowman.net writes:
I'm not sure if it out-ranks the advantages of the change for buildfarm
support, but the above change isn't actually without any disadvantage.
Specifically, not every auth mechanism that works with -h machine_name
works with -h localhost, but the first
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Stephen Frost wrote:
Thanks. To make sure it gets picked up, you might respond to Tom's
message above with this same email. Just a thought.
The following message was my reply.
Robert Haas robertmh...@gmail.com writes:
I don't see much advantage in this proposal, at least not immediately.
If it turns out to be a wildly popular feature and doesn't turn out
to introduce security vulnerabilities or breakage, we can always make
this change later.
The advantage is to
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
I'm not sure if it out-ranks the advantages of the change for buildfarm
support, but the above change isn't actually without any disadvantage.
Specifically, not every auth mechanism that works with -h
Mark Mielke m...@mark.mielke.cc writes:
I would like to see the default of trust abolished.
We've been around on that point before and I don't see any reason to
think that the outcome of the argument would be different now. The only
reason I brought all this up is that samehost does change the
On Wed, 2009-09-30 at 18:50 -0400, Tom Lane wrote:
It would be a good idea to tie this to a psql magic variable (like
ON_ERROR_STOP) so that it could conveniently be set in ~/.psqlrc.
I'm not actually sure that we need a dedicated command line switch
for it, since you could use -v varname
On Wed, 2009-09-30 at 22:08 -0400, Tom Lane wrote:
# local connections via TCP/IP:
hostall all samehost @authmethod@
The advantage of this is that connections made with -h machine_name
instead of -h localhost would work without customization. I can't
see
Peter Eisentraut pete...@gmx.net writes:
(Note that you would still need a non-default setting of
listen_addresses for -h machine_name to actually work.)
Which makes this proposal kind of uninteresting.
Well, it's one less thing that has to be fixed for local connections
to work smoothly.
Peter Eisentraut pete...@gmx.net writes:
On Wed, 2009-09-30 at 22:08 -0400, Tom Lane wrote:
(Note that you would still need a non-default setting of
listen_addresses for -h machine_name to actually work.)
Which makes this proposal kind of uninteresting.
Although come to think of it ... is
On 1 okt 2009, at 06.53, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On Wed, 2009-09-30 at 22:08 -0400, Tom Lane wrote:
(Note that you would still need a non-default setting of
listen_addresses for -h machine_name to actually work.)
Which makes this proposal
On Wed, Sep 30, 2009 at 11:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Although come to think of it ... is there any reason besides sheer
conservatism to not make the default listen_addresses value '*'?
just my 2 cents. but i always wondered about the existence of
listen_addresses at all... to
95 matches
Mail list logo
