* Thom Brown (t...@linux.com) wrote:
On 5 March 2014 06:33, Stephen Frost sfr...@snowman.net wrote:
Fix issues with pg_ctl
[...]
thom@swift ~/dbtest $ sh: 1: ���: not found
Yeesh. Always with the simple ones it seems. Yeah, I see what the
issue here is, will fix.
Thanks!
Stephen
Allocate fresh memory for post_opts/exec_path
Instead of having read_post_opts() depend on the memory allocated for
the config file (which is now getting free'd), pg_strdup() for
post_opts and exec_path (similar to how it's being done elsewhere).
Noted by Thom Brown.
Branch
--
master
K, will check it out. Thanks!
On Tuesday, March 4, 2014, Bruce Momjian br...@momjian.us wrote:
On Sun, Mar 2, 2014 at 03:14:35AM +, Stephen Frost wrote:
Various Coverity-spotted fixes
A number of issues were identified by the Coverity scanner and are
addressed in this patch. None
Fix issues with pg_ctl
The new, small, free_readfile managed to have bug in it which could
cause it to try and free something it shouldn't, and fix the case
where it was being called with an invalid pointer leading to a
segfault.
Noted by Bruce, issues introduced and fixed by me.
Branch
--
Another round of Coverity fixes
Additional non-security issues/improvements spotted by Coverity.
In backend/libpq, no sense trying to protect against port-hba being
NULL after we've already dereferenced it in the switch() statement.
Prevent against possible overflow due to 32bit arithmitic in
Various Coverity-spotted fixes
A number of issues were identified by the Coverity scanner and are
addressed in this patch. None of these appear to be security issues
and many are mostly cosmetic changes.
Short comments for each of the changes follows.
Correct the semi-colon placement in
* Jeff Davis (jda...@postgresql.org) wrote:
Fix crash in json_to_record().
json_to_record() depends on get_call_result_type() for the tuple
descriptor of the record that should be returned, but in some cases
that cannot be determined. Add a guard to check if the tuple
descriptor has been
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
Minor pg_dump improvements
I'm pretty sure you broke _CloseArchive with this hunk:
That'd be pretty frustrating as my testing didn't exhibit any issues.
@@ -708,6 +708,9 @@ _CloseArchive(ArchiveHandle *AH
Focus on ftello result 0 instead of errno
Rather than reset errno (or just hope that its cleared already),
check just the result of the ftello for 0 to determine if there
was an issue.
Oversight by me, pointed out by Tom.
Branch
--
master
Details
---
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I'm pretty sure you broke _CloseArchive with this hunk:
That'd be pretty frustrating as my testing didn't exhibit any issues.
It's possible that errno is accidentally
* Tom Lane (t...@sss.pgh.pa.us) wrote:
grep shows me a couple of other places where the result of ftello doesn't
seem to be getting checked for error. Odd that Coverity didn't notice
those.
At least two of those are in a #if 0 block... since 2001
(pg_backup_tar.c:_tarGetHeader). I'm thinking
Further pg_dump / ftello improvements
Make ftello error-checking consistent to all calls and remove a
bit of ftello-related code which has been #if 0'd out since 2001.
Note that we are not concerned with the ftello() call under
snprintf() failing as it is just building a string to call
Minor pg_dump improvements
Improve pg_dump by checking results on various fgetc() calls which
previously were unchecked, ditto for ftello. Also clean up a couple
of very minor memory leaks by waiting to allocate structures until
after the initial check(s).
Issues spotted by Coverity.
Branch
Revert dup2() checking in syslogger.c
Per the expanded comment-
As we're just trying to reset these to go to DEVNULL, there's not
much point in checking for failure from the close/dup2 calls here,
if they fail then presumably the file descriptors are closed and
any writes will go into the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
In short, this patch was ill considered. Please revert. If we need
to silence a Coverity complaint, perhaps a cast-to-void will do?
Sure, I'll adjust it accordingly
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
Check dup2() results in syslogger
Consistently check the dup2() call results throughout syslogger.c.
It's pretty unlikely that they'll error out, but if they do,
ereport(FATAL) instead of blissfully continuing
* Tom Lane (t...@sss.pgh.pa.us) wrote:
You shouldn't really raise that argument against the guy who made the
original commit in question ;-).
Figures. :) Not sure how I missed that.
[...]
Right, I had followed that.
Now ideally, the way we do that is to reconnect its stderr to /dev/null,
Use E, not e, for escaping in example docs
From the Department of Nitpicking, be consistent with other escaping
and use 'E' instead of 'e' to escape the string in the example docs
for GET DISAGNOSTICS stack = PG_CONTEXT.
Noticed by Department Chief Magnus Hagander.
Branch
--
master
Details
Check dup2() results in syslogger
Consistently check the dup2() call results throughout syslogger.c.
It's pretty unlikely that they'll error out, but if they do,
ereport(FATAL) instead of blissfully continuing on.
Spotted by the Coverity scanner.
Branch
--
master
Details
---
Fix minor leak in pg_dump
Move allocation to after we check the remote server version, to avoid
a possible, very minor, memory leak. This makes us more consistent
throughout as most places in pg_dump are done in the same way (due, in
part, to previous fixes like this).
Spotted by the Coverity
Avoid minor leak in parallel pg_dump
During parallel pg_dump, a worker process closing the connection caused
a minor memory leak (particularly minor as we are likely about to exit
anyway). Instead, free the memory in this case prior to returning NULL
to indicate connection closed.
Spotting by
Avoid minor leak in parallel pg_dump
During parallel pg_dump, a worker process closing the connection caused
a minor memory leak (particularly minor as we are likely about to exit
anyway). Instead, free the memory in this case prior to returning NULL
to indicate connection closed.
Spotting by
ALTER TABLESPACE ... MOVE ... OWNED BY
Add the ability to specify the objects to move by who those objects are
owned by (as relowner) and change ALL to mean ALL objects. This
makes the command always operate against a well-defined set of objects
and not have the objects-to-be-moved based on the
Allow type_func_name_keywords in even more places
A while back, 2c92edad48796119c83d7dbe6c33425d1924626d allowed
type_func_name_keywords to be used in more places, including role
identifiers. Unfortunately, that commit missed out on cases where
name_list was used for lists-of-roles, eg: for DROP
Allow type_func_name_keywords in even more places
A while back, 2c92edad48796119c83d7dbe6c33425d1924626d allowed
type_func_name_keywords to be used in more places, including role
identifiers. Unfortunately, that commit missed out on cases where
name_list was used for lists-of-roles, eg: for DROP
Allow type_func_name_keywords in even more places
A while back, 2c92edad48796119c83d7dbe6c33425d1924626d allowed
type_func_name_keywords to be used in more places, including role
identifiers. Unfortunately, that commit missed out on cases where
name_list was used for lists-of-roles, eg: for DROP
Allow type_func_name_keywords in even more places
A while back, 2c92edad48796119c83d7dbe6c33425d1924626d allowed
type_func_name_keywords to be used in more places, including role
identifiers. Unfortunately, that commit missed out on cases where
name_list was used for lists-of-roles, eg: for DROP
Allow type_func_name_keywords in even more places
A while back, 2c92edad48796119c83d7dbe6c33425d1924626d allowed
type_func_name_keywords to be used in more places, including role
identifiers. Unfortunately, that commit missed out on cases where
name_list was used for lists-of-roles, eg: for DROP
Allow SET TABLESPACE to database default
We've always allowed CREATE TABLE to create tables in the database's default
tablespace without checking for CREATE permissions on that tablespace.
Unfortunately, the original implementation of ALTER TABLE ... SET TABLESPACE
didn't pick up on that
Allow SET TABLESPACE to database default
We've always allowed CREATE TABLE to create tables in the database's default
tablespace without checking for CREATE permissions on that tablespace.
Unfortunately, the original implementation of ALTER TABLE ... SET TABLESPACE
didn't pick up on that
Allow SET TABLESPACE to database default
We've always allowed CREATE TABLE to create tables in the database's default
tablespace without checking for CREATE permissions on that tablespace.
Unfortunately, the original implementation of ALTER TABLE ... SET TABLESPACE
didn't pick up on that
Allow SET TABLESPACE to database default
We've always allowed CREATE TABLE to create tables in the database's default
tablespace without checking for CREATE permissions on that tablespace.
Unfortunately, the original implementation of ALTER TABLE ... SET TABLESPACE
didn't pick up on that
Allow SET TABLESPACE to database default
We've always allowed CREATE TABLE to create tables in the database's default
tablespace without checking for CREATE permissions on that tablespace.
Unfortunately, the original implementation of ALTER TABLE ... SET TABLESPACE
didn't pick up on that
Allow SET TABLESPACE to database default
We've always allowed CREATE TABLE to create tables in the database's default
tablespace without checking for CREATE permissions on that tablespace.
Unfortunately, the original implementation of ALTER TABLE ... SET TABLESPACE
didn't pick up on that
Add ALTER TABLESPACE ... MOVE command
This adds a 'MOVE' sub-command to ALTER TABLESPACE which allows moving sets of
objects from one tablespace to another. This can be extremely handy and avoids
a lot of error-prone scripting. ALTER TABLESPACE ... MOVE will only move
objects the user owns,
Add CREATE TABLESPACE ... WITH ... Options
Tablespaces have a few options which can be set on them to give PG hints
as to how the tablespace behaves (perhaps it's faster for sequential
scans, or better able to handle random access, etc). These options were
only available through the ALTER
Fix SSL deadlock risk in libpq
In libpq, we set up and pass to OpenSSL callback routines to handle
locking. When we run out of SSL connections, we try to clean things
up by de-registering the hooks. Unfortunately, we had a few calls
into the OpenSSL library after these hooks were de-registered
Fix SSL deadlock risk in libpq
In libpq, we set up and pass to OpenSSL callback routines to handle
locking. When we run out of SSL connections, we try to clean things
up by de-registering the hooks. Unfortunately, we had a few calls
into the OpenSSL library after these hooks were de-registered
Fix SSL deadlock risk in libpq
In libpq, we set up and pass to OpenSSL callback routines to handle
locking. When we run out of SSL connections, we try to clean things
up by de-registering the hooks. Unfortunately, we had a few calls
into the OpenSSL library after these hooks were de-registered
Fix SSL deadlock risk in libpq
In libpq, we set up and pass to OpenSSL callback routines to handle
locking. When we run out of SSL connections, we try to clean things
up by de-registering the hooks. Unfortunately, we had a few calls
into the OpenSSL library after these hooks were de-registered
Fix SSL deadlock risk in libpq
In libpq, we set up and pass to OpenSSL callback routines to handle
locking. When we run out of SSL connections, we try to clean things
up by de-registering the hooks. Unfortunately, we had a few calls
into the OpenSSL library after these hooks were de-registered
Improve handling of pthread_mutex_lock error case
We should really be reporting a useful error along with returning
a valid return code if pthread_mutex_lock() throws an error for
some reason. Add that and back-patch to 9.0 as the prior patch.
Pointed out by Alvaro Herrera
Branch
--
Improve handling of pthread_mutex_lock error case
We should really be reporting a useful error along with returning
a valid return code if pthread_mutex_lock() throws an error for
some reason. Add that and back-patch to 9.0 as the prior patch.
Pointed out by Alvaro Herrera
Branch
--
Improve handling of pthread_mutex_lock error case
We should really be reporting a useful error along with returning
a valid return code if pthread_mutex_lock() throws an error for
some reason. Add that and back-patch to 9.0 as the prior patch.
Pointed out by Alvaro Herrera
Branch
--
master
Improve handling of pthread_mutex_lock error case
We should really be reporting a useful error along with returning
a valid return code if pthread_mutex_lock() throws an error for
some reason. Add that and back-patch to 9.0 as the prior patch.
Pointed out by Alvaro Herrera
Branch
--
Improve handling of pthread_mutex_lock error case
We should really be reporting a useful error along with returning
a valid return code if pthread_mutex_lock() throws an error for
some reason. Add that and back-patch to 9.0 as the prior patch.
Pointed out by Alvaro Herrera
Branch
--
Allow a context to be passed in for error handling
As pointed out by Tom Lane, we can allow other users of the error
handler callbacks to provide their own memory context by adding
the context to use to ErrorData and using that instead of explicitly
using ErrorContext.
This then allows
() and all of the other
users of SSL_context which weren't already protected.
Nick Phillips, much reworked by Stephen Frost
Back-patch to 9.0 where we started loading the cert directly instead of
using a callback.
Branch
--
REL9_3_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff
() and all of the other
users of SSL_context which weren't already protected.
Nick Phillips, much reworked by Stephen Frost
Back-patch to 9.0 where we started loading the cert directly instead of
using a callback.
Branch
--
REL9_2_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff
() and all of the other
users of SSL_context which weren't already protected.
Nick Phillips, much reworked by Stephen Frost
Back-patch to 9.0 where we started loading the cert directly instead of
using a callback.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff
() and all of the other
users of SSL_context which weren't already protected.
Nick Phillips, much reworked by Stephen Frost
Back-patch to 9.0 where we started loading the cert directly instead of
using a callback.
Branch
--
REL9_1_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff
() and all of the other
users of SSL_context which weren't already protected.
Nick Phillips, much reworked by Stephen Frost
Back-patch to 9.0 where we started loading the cert directly instead of
using a callback.
Branch
--
REL9_0_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff
Improvements to GetErrorContextStack()
As GetErrorContextStack() borrowed setup and tear-down code from other
places, it was less than clear that it must only be called as a
top-level entry point into the error system and can't be called by an
exception handler (unlike the rest of the error
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I'm not following your reasoning here. This *has* to be called in an
error case, before you're outside the error processing context.
Otherwise there would be no data available to be printed.
In short: FlushErrorState, by definition, destroys the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
1. Just run the whole business in the caller's context and leave it up
to the caller to worry about whether it needs to clean up memory usage.
I'd certainly be fine with that, and had considered it, but it looks
like errcontext_msg() (which is called by
Pavel,
First, please only quote the relevant parts of the email when
responding.
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
I used a ErrorContext because I wasn't sure so errcontext and similar
function can work in different context. Now I look there and there
should be well initialized
* Tom Lane (t...@sss.pgh.pa.us) wrote:
[...] a better idea is to add a memory-context-to-use field to struct
ErrorData. We'd initialize it to ErrorContext when pushing a stack
entry for normal error processing, but GetErrorContextStack could
do something different. This would eliminate most
Tom,
On Wednesday, July 24, 2013, Tom Lane wrote:
Stephen Frost sfr...@snowman.net javascript:; writes:
Add GET DIAGNOSTICS ... PG_CONTEXT in PL/PgSQL
I don't find it to be a terribly good idea that GetErrorContextStack
does FlushErrorState(). Doesn't that imply that it can't safely
On Wednesday, July 24, 2013, Stephen Frost wrote:
Still, if there's a reasonable way to collect the stack info without going
through the error callbacks, without implementing a duplicate system, I'm
all ears.
That said, I'll work on making this more independent of the error handling
and see
On Wednesday, July 24, 2013, Tom Lane wrote:
Stephen Frost sfr...@snowman.net javascript:; writes:
That said, I'll work on making this more independent of the error
handling
and see if it can be made to use an independent memory context and try to
tighten it up to ensure it isn't called
On Wednesday, July 24, 2013, Stephen Frost wrote:
Unfortunately, I don't have the code in front of me at the moment, but I
was pretty sure FlushErrorState cleans up the intermediate information set
up during an individual error call and doesn't completely clear the stack
info (tho I can't
On Thursday, July 25, 2013, Stephen Frost wrote:
On Wednesday, July 24, 2013, Stephen Frost wrote:
Unfortunately, I don't have the code in front of me at the moment, but I
was pretty sure FlushErrorState cleans up the intermediate information set
up during an individual error call
WITH CHECK OPTION support for auto-updatable VIEWs
For simple views which are automatically updatable, this patch allows
the user to specify what level of checking should be done on records
being inserted or updated. For 'LOCAL CHECK', new tuples are validated
against the conditionals of the
Correct off-by-one when reading from pipe
In pg_basebackup.c:reached_end_position(), we're reading from an
internal pipe with our own background process but we're possibly
reading more bytes than will actually fit into our buffer due to
an off-by-one error. As we're reading from an internal pipe
Correct off-by-one when reading from pipe
In pg_basebackup.c:reached_end_position(), we're reading from an
internal pipe with our own background process but we're possibly
reading more bytes than will actually fit into our buffer due to
an off-by-one error. As we're reading from an internal pipe
Correct off-by-one when reading from pipe
In pg_basebackup.c:reached_end_position(), we're reading from an
internal pipe with our own background process but we're possibly
reading more bytes than will actually fit into our buffer due to
an off-by-one error. As we're reading from an internal pipe
Clean up pg_basebackup libpq usage
When using libpq, it's generally preferrable to just use the strings
which are in the PQ structures instead of copying them out, so do
that instead in BaseBackup(), eliminating the strcpy()'s used there.
Also, in ReceiveAndUnpackTarFile(), check the string
Check get_tle_by_resno() result before deref
When creating a sort to support a group by, we need to look up the
target entry in the target list by the resno using get_tle_by_resno().
This particular code-path didn't check the result prior to attempting
to dereference it, while all other callers
During parallel pg_dump, free commands from master
The command strings read by the child processes during parallel
pg_dump, after being read and handled, were not being free'd.
This patch corrects this relatively minor memory leak.
Leak found by the Coverity scanner.
Back patch to 9.3 where
During parallel pg_dump, free commands from master
The command strings read by the child processes during parallel
pg_dump, after being read and handled, were not being free'd.
This patch corrects this relatively minor memory leak.
Leak found by the Coverity scanner.
Back patch to 9.3 where
pg_receivexlog - Exit on failure to parse
In streamutil.c:GetConnection(), upgrade failure to parse the
connection string to an exit(1) instead of simply returning NULL.
Most callers already immediately exited, but pg_receivexlog would
loop on this case, continually trying to re-parse the
pg_receivexlog - Exit on failure to parse
In streamutil.c:GetConnection(), upgrade failure to parse the
connection string to an exit(1) instead of simply returning NULL.
Most callers already immediately exited, but pg_receivexlog would
loop on this case, continually trying to re-parse the
Ensure 64bit arithmetic when calculating tapeSpace
In tuplesort.c:inittapes(), we calculate tapeSpace by first figuring
out how many 'tapes' we can use (maxTapes) and then multiplying the
result by the tape buffer overhead for each. Unfortunately, when
we are on a system with an 8-byte long, we
Ensure 64bit arithmetic when calculating tapeSpace
In tuplesort.c:inittapes(), we calculate tapeSpace by first figuring
out how many 'tapes' we can use (maxTapes) and then multiplying the
result by the tape buffer overhead for each. Unfortunately, when
we are on a system with an 8-byte long, we
Ensure 64bit arithmetic when calculating tapeSpace
In tuplesort.c:inittapes(), we calculate tapeSpace by first figuring
out how many 'tapes' we can use (maxTapes) and then multiplying the
result by the tape buffer overhead for each. Unfortunately, when
we are on a system with an 8-byte long, we
Ensure 64bit arithmetic when calculating tapeSpace
In tuplesort.c:inittapes(), we calculate tapeSpace by first figuring
out how many 'tapes' we can use (maxTapes) and then multiplying the
result by the tape buffer overhead for each. Unfortunately, when
we are on a system with an 8-byte long, we
Ensure 64bit arithmetic when calculating tapeSpace
In tuplesort.c:inittapes(), we calculate tapeSpace by first figuring
out how many 'tapes' we can use (maxTapes) and then multiplying the
result by the tape buffer overhead for each. Unfortunately, when
we are on a system with an 8-byte long, we
Ensure 64bit arithmetic when calculating tapeSpace
In tuplesort.c:inittapes(), we calculate tapeSpace by first figuring
out how many 'tapes' we can use (maxTapes) and then multiplying the
result by the tape buffer overhead for each. Unfortunately, when
we are on a system with an 8-byte long, we
Fix resource leak in initdb -X option
When creating the symlink for the xlog directory, free the string
which stores the link location. Not really an issue but it doesn't
hurt to be good about this- prior cleanups have fixed similar
issues.
Leak found by the Coverity scanner.
Not back-patching
Check version before allocating PQExpBuffer
In pg_dump.c:getEventTriggers, check what major version we are on
before calling createPQExpBuffer() to avoid leaking that bit of
memory.
Leak discovered by the Coverity scanner.
Back-patch to 9.3 where support for dumping event triggers was
added.
Check version before allocating PQExpBuffer
In pg_dump.c:getEventTriggers, check what major version we are on
before calling createPQExpBuffer() to avoid leaking that bit of
memory.
Leak discovered by the Coverity scanner.
Back-patch to 9.3 where support for dumping event triggers was
added.
Additional spelling corrections
A few more minor spelling corrections, no functional changes.
Thom Brown
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/f129615fe72f70868a86862b663dd7d78dd5cb71
Modified Files
--
src/backend/access/hash/README |
Post-pgindent cleanup
Make slightly better decisions about indentation than what pgindent
is capable of. Mostly breaking out long function calls into one
line per argument, with a few other minor adjustments.
No functional changes- all whitespace.
pgindent ran cleanly (didn't change anything)
Minor spelling fixes
Fix a few spelling mistakes.
Per bug report #8193 from Lajos Veres.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/c9fc28a7f12e27d530e2657c9dc6080fbfbe8a14
Modified Files
--
contrib/pg_upgrade/relfilenode.c|2 +-
Documentation fix for ALTER TYPE .. RENAME
The documentation for ALTER TYPE .. RENAME claimed to support a
RESTRICT/CASCADE option at the 'type' level, which wasn't implemented
and doesn't make a whole lot of sense to begin with. What is supported,
and previously undocumented, is
ALTER TYPE ..
Documentation fix for ALTER TYPE .. RENAME
The documentation for ALTER TYPE .. RENAME claimed to support a
RESTRICT/CASCADE option at the 'type' level, which wasn't implemented
and doesn't make a whole lot of sense to begin with. What is supported,
and previously undocumented, is
ALTER TYPE ..
* Tom Lane ([EMAIL PROTECTED]) wrote:
Oleg Bartunov oleg@sai.msu.su writes:
Do we follow RBAC (http://csrc.nist.gov/rbac/) ?
Personally, I'm reading SQL99 for this.
I've been following an SQL2003 draft... That looks interesting but I
think we probably want to stick to SQL..
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Thanks, TODO item readded with a clearer description:
* Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
index using a sequential scan for highest/lowest values
Right now, if no index
401 - 488 of 488 matches
Mail list logo
