Re: [BUGS] BUG #7514: postgres -k no longer works with spaces in the path
Peter Eisentraut writes: > Maybe it would be easier if multiple -k options accumulated. After further thought I'm not very enamored of that concept. We've made considerable compromises to ensure that every postmaster command-line option corresponds exactly to some GUC parameter; it does not seem to me that -k is important enough to deserve an exception. However, it occurs to me that Murray's original complaint about spaces in -k pathnames could be dealt with via very narrow changes in SplitDirectoriesString. That function was modeled on SplitIdentifierString, with perhaps not enough thought about the differences between identifiers and pathnames. In particular, I suggest that there's no need to reject embedded spaces in pathnames, and plenty of systems on which it's important not to. (Think "Program Files" on Windows, for instance.) It probably still makes sense to trim leading and trailing whitespace, but let's allow embedded spaces. If we did that, the new code would be incompatible with the old only for paths including commas, leading double quotes, or leading/trailing whitespace. I submit that all of those cases are pretty uncommon, especially compared to embedded space. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7514: postgres -k no longer works with spaces in the path
Peter Eisentraut writes: > Maybe it would be easier if multiple -k options accumulated. Hm, interesting thought, but how would we make that play in the generic GUC support? Or are you imagining that we'd just kluge up -k with some single-purpose code? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7514: postgres -k no longer works with spaces in the path
On 9/4/12 2:22 PM, Murray Cumming wrote:
> On Tue, 2012-09-04 at 10:31 -0400, Tom Lane wrote:
>> murr...@murrayc.com writes:
>>> At some point, probably in 9.1.5, the -k option to Postgres ("Unix-domain
>>> socket location" in --help), stopped accepting paths that contain spaces.
>>
>>> For instance,
>>> -k '/tmp/testglom2FPDKW/path with spaces/some_postgres_data'
>>
>>> It now fails with this error:
>>> FATAL: invalid list syntax for "unix_socket_directories"
>>
>> Ah, you're using the latest Fedora packaging of 9.1.x, which includes a
>> back-ported version of the unix_socket_directories change that's in
>> HEAD. -k now effectively takes a list of directory names, not just
>> one, and it's pickier about whitespace.
>>
>> IIRC, you can make it work if you put double quotes around the
>> space-containing name, so it'd look like this:
>>
>> -k '"/blah blah blah"'
>
> Yes, thanks, that works for spaces, though it's rather odd.
>
> However, how should I now specify a path that has a " or a /, or \,
> which now cause similar errors with -k? Previously I could just use
> g_shell_quote() and forget about it:
> http://developer.gnome.org/glib/stable/glib-Shell-related-Utilities.html#g-shell-quote
>
> To be honest, I don't have much interest in, or understanding of, this
> -k option anyway. I just use it because, when starting my temporary
> postgresql instance, it otherwise defaults to /var/run/postgresql/ (at
> least in this distro build) which is not available to normal users. I
> currently just specify the same directory that the postgresql data is
> in. Maybe I should just use /tmp instead.
Maybe it would be easier if multiple -k options accumulated. That would
make the whole quoting business easier, and it would avoid breaking
compatibility.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7516: PL/Perl crash
Hi, On 03/09/2012 18:06, Tom Lane wrote: pgm...@joh.to writes: We had a segmentation fault in PostgreSQL 9.1.5 with PL/PerlU. ... It seems to have happened when a PL/PerlU executed a prepared statement which calls another PL/PerlU function. Hm. Is it possible that the prepared statement recursively called the *same* plperl function? And that somebody did a CREATE OR REPLACE on that function meanwhile? No, that doesn't seem possible in this case. The function calls some prepared statements repeatedly, but no recursion should occur. This might be the wrong theory. You seem to have debug symbols for that core dump --- can you tell which of the dereferences in line 3373 caused the crash? The current_call_data->prodesc->fn_readonly one. Please let me know if I can be of more assistance. Regards, Marko Tiikkaja -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7521: Cannot disable WAL log while using pg_dump
The following bug has been logged on the website: Bug reference: 7521 Logged by: Boy de Laat Email address: b...@atsc.nl PostgreSQL version: 9.1.4 Operating system: CentOS 6.2 x86_64 Description: I've setup some slave replication and just to be sure i use pg_dump as a backup mechanism besides replication. But when the pg_dump command is issued much WAL logs will be generated and this is causing my slave to stop replicating because it is to far behind. So it would be nice if there is an option to disable WAL logging while running pg_dump. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7519: incresed data base size and query performance lost
"Lokendra Dixit" wrote: > RAM: 2 GB You do realize how small that is for a database server, I hope. Many people are walking around with cell phones in their pockets that have a lot more. This could contribute to severe slowdown with even minimal growth of the database, as cached access will suddenly become disk access, which is orders of magnitude slower. > (Embedded image moved to file: pic00041.jpg) It's much better to include such information in text form than to use a screen image. Anyway, according to that you didn't change autovacuum values from the defaults. You might want to make autovacuum a bit more aggressive to try to keep table sizes down; but I think the root of the problem is that a pg_dump and restore will normally pack the data very tightly on disk. In normal operations thing become less tight as index pages split, etc., and you are probably going from a very high cache hit ratio to a lower one, causing the slowdown. For about $35 you could probably double or triple the amount of RAM you have available and totally eliminate the problem. You have probably spent a lot more money on staff time to deal with the problem than the RAM will cost. -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
