| Commit message (Collapse) | Author | Age |
|
|
|
| |
the bulk of the heavy lifting ...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
>>ISTM that "source" is worth knowing.
>
> Hm, possibly. Any other opinions?
This version has the seven fields I proposed, including "source". Here's
an example that shows why I think it's valuable:
regression=# \x
Expanded display is on.
regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name | enable_seqscan
setting | on
context | user
vartype | bool
source | default
min_val |
max_val |
regression=# update pg_settings set setting = 'off' where name =
'enable_seqscan';
-[ RECORD 1 ]---
set_config | off
regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name | enable_seqscan
setting | off
context | user
vartype | bool
source | session
min_val |
max_val |
regression=# alter user postgres set enable_seqscan to 'off';
ALTER USER
(log out and then back in again)
regression=# \x
Expanded display is on.
regression=# select * from pg_settings where name = 'enable_seqscan';
-[ RECORD 1 ]-----------
name | enable_seqscan
setting | off
context | user
vartype | bool
source | user
min_val |
max_val |
In the first case, enable_seqscan is set to its default value. After
setting it to off, it is obvious that the value has been changed for the
session only. In the third case, you can see that the value has been set
specifically for the user.
Joe Conway
|
|
|
|
|
|
| |
tested on both redhat 8 and FreebSD.
--
Mike Nolan
|
| |
|
|
|
|
|
|
| |
doing '2003-07-30' -> '2003-04-01', '2003-11-30' ->'2003-07-01'
B?jthe Zolt?n
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
modes (and replace the requiressl boolean). The four options were first
spelled out by Magnus Hagander <mha@sollentuna.net> on 2000-08-23 in email
to pgsql-hackers, archived here:
http://archives.postgresql.org/pgsql-hackers/2000-08/msg00639.php
My original less-flexible patch and the ensuing thread are archived at:
http://dbforums.com/t623845.html
Attached is a new patch, including documentation.
To sum up, there's a new client parameter "sslmode" and environment
variable "PGSSLMODE", with these options:
sslmode description
------- -----------
disable Unencrypted non-SSL only
allow Negotiate, prefer non-SSL
prefer Negotiate, prefer SSL (default)
require Require SSL
The only change to the server is a new pg_hba.conf line type,
"hostnossl", for specifying connections that are not allowed to use SSL
(for example, to prevent servers on a local network from accidentally
using SSL and wasting cycles). Thus the 3 pg_hba.conf line types are:
pg_hba.conf line types
----------------------
host applies to either SSL or regular connections
hostssl applies only to SSL connections
hostnossl applies only to regular connections
These client and server options, the postgresql.conf ssl = false option,
and finally the possibility of compiling with no SSL support at all,
make quite a range of combinations to test. I threw together a test
script to try many of them out. It's in a separate tarball with its
config files, a patch to psql so it'll announce SSL connections even in
absence of a tty, and the test output. The test is especially informative
when run on the same tty the postmaster was started on, so the FATAL:
errors during negotiation are interleaved with the psql client output.
I saw Tom write that new submissions for 7.4 have to be in before midnight
local time, and since I'm on the east coast in the US, this just makes it
in before the bell. :)
Jon Jensen
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
was modified for IPv6. Use a robust definition of struct sockaddr_storage,
do a proper configure test to see if ss_len exists, don't assume that
getnameinfo() will handle AF_UNIX sockets, don't trust getaddrinfo to
return the protocol we ask for, etc. This incorporates several outstanding
patches from Kurt Roeckx, but I'm to blame for anything that doesn't
work ...
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Along the way, fix some logic problems in pgstat_initstats, notably the
bogus assumption that malloc returns zeroed memory.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
xid when we fail to access pg_clog.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
does not dump core.
|
| |
|
|
|
|
|
|
| |
database, emit a WARNING and do nothing, rather than raising ERROR.
Per recent discussion in which we concluded this is the best way to deal
with database dumps that are reloaded into a database of a new name.
|
|
|
|
|
|
|
|
| |
fixed incorrect initial setting of StartUpID. The logic in XLogWrite()
expects that Write->curridx is advanced to the next page as soon as
LogwrtResult points to the end of the current page, but StartupXLOG()
failed to make that happen when the old WAL ended exactly on a page
boundary. Per trouble report from Hannu Krosing.
|
|
|
|
|
|
| |
for the sign of timezone offsets, ie, positive is east from UTC. These
were previously out of step with other operations that accept or show
timezones, such as I/O of timestamptz values.
|
|
|
|
|
|
| |
query node, since that won't work unless the planner is upgraded.
Someday we should try to support at least some cases of this, but for
now just plug the hole in the dike. Per discussion with Dmitry Tkach.
|
|
|
|
| |
with SET TRANSACTION_ISOLATION, either.
|
|
|
|
|
|
| |
DATESTYLE, for instance 'SQL, European' instead of
'SQL with European conventions'. Per gripe a month or two back from
Barry Lind.
|
|
|
|
|
|
|
|
| |
shared_buffers and max_connections values to use before we run the
bootstrap process. Without this, initdb would fail on platforms where
the hardwired default values are too large. (We could get around that
by making the hardwired defaults tiny, perhaps, but why slow down
bootstrap by starving it for buffers...)
|
|
|
|
|
| |
for each row processed, and don't forget the evaluation cost of any
restriction clauses attached to the node. Per discussion with Greg Stark.
|
|
|
|
|
|
|
|
|
| |
and 100 respectively, if the platform will allow it. initdb selects
values that are not too large to allow the postmaster to start, and
places these values in the installed postgresql.conf file. This allows
us to continue to start up out-of-the-box on platforms with small SHMMAX,
while having somewhat-realistic default settings on platforms with
reasonable SHMMAX. Per recent pghackers discussion.
|
| |
|
|
|
|
| |
Aizaz Ahmed
|
|
|
|
| |
to zero.
|
|
|
|
|
|
|
| |
or increased only by super-users.
This fixes problems caused by making certain variables SUSET for
security reasons.
|
|
|
|
|
| |
this is merely an API inconsistency, but in ecpg it's fatal.) Also,
fix misconceived overflow test in HAVE_INT64_TIMESTAMP case.
|
|
|
|
|
|
| |
without needing a running backend. Reorder postgresql.conf.sample
to match new layout of runtime.sgml. This commit re-adds work lost
in Wednesday's crash.
|
|
|
|
|
| |
function-not-found messages now distinguish the cases no-match and
ambiguous-match, and they follow the style guidelines too.
|
|
|
|
|
| |
integer conversions gave the wrong answer for values with stripped
trailing zeroes, such as 10000000.
|
|
|
|
|
|
|
|
| |
instead of the former kluge whereby gram.y emitted already-transformed
expressions. This is needed so that Params appearing in these clauses
actually work correctly. I suppose some might claim that the side effect
of 'SELECT ... LIMIT 2+2' working is a new feature, but I say this is
a bug fix.
|
|
|
|
| |
so it has some chance of working in rules ...
|
|
|
|
|
|
| |
It also works to create a non-polymorphic aggregate from polymorphic
functions, should you want to do that. Regression test added, docs still
lacking. By Joe Conway, with some kibitzing from Tom Lane.
|