On 1 August 2013 01:53, Noah Misch n...@leadboat.com wrote:
I was able to distill the above hypothesis into an actual crash with
reduce_lock_levels.v13.patch. Test recipe:
Thank you for the report; thank you again for reporting in sufficient
time to allow me to investigate and fix by the next
Hi all,
I've come across an issue within pg_hba configuration which it seems
cannot not set the record of a database name where there is a
newline(\n) in the name.
I created the database whihin psql like this:
create database ab
cd;
I have tried all the following records, but seems not to work:
Hello,
initdb using the latest HEAD (9.4dev) fails with:
[amit@centos64vm postgresql]$ initdb -D ~/dev/pgdata/
The files belonging to this database system will be owned by user amit.
This user must also own the server process.
The database cluster will be initialized with locale en_US.utf8.
The
Build using:
CFLAGS=-g -O0 ./configure --with-pam --enable-cassert --enable-debug
--prefix=/home/amit/dev/pginstall/
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Jul 31, 2013 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeevan Chalke jeevan.cha...@enterprisedb.com writes:
Oops forgot patch.
Attached now.
Hmm ... I think the logic change is good, but two demerits for not fixing
the adjacent comment.
I had a look over comments and
On Thu, Aug 1, 2013 at 3:52 PM, Amit Langote amitlangot...@gmail.com wrote:
Build using:
CFLAGS=-g -O0 ./configure --with-pam --enable-cassert --enable-debug
--prefix=/home/amit/dev/pginstall/
--
Amit Langote
Umm, I guess I forgot to make clean before building with the latest
HEAD. Now, I
On Thu, Aug 1, 2013 at 12:25 PM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
On Wed, Jul 31, 2013 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeevan Chalke jeevan.cha...@enterprisedb.com writes:
Oops forgot patch.
Attached now.
Hmm ... I think the logic change is good, but
While checking something, I noticed that opfamilies 3626, 3683, 3901
(all btree AM), 3903 (hash) and 3919 (gist) are all defined in the
section marked as gin.
(I'm not sure if it helps to deliver a patch - it may be easier for the
committer to move the items himself than to check if the diff
On Tuesday, July 30, 2013 10:25 PM Josh Berkus wrote:
Amit,
I had already sent the updated patch based on recent suggestions.
Yes, but there is no consensus yet on certain fundamental issues, such
as:
1. what directory should postgresql.auto.conf live in?
Current situation is that
Hi,
People, including me, every now and then forget to pass --enable-depend
to configure (when not using my own environment). Which then leads to
strange errors that cost time to track down...
Thus I'd like to enable dependency tracking by default. Given todays
computing powers there doesn't
Greg Stark st...@mit.edu writes:
Greg Smith's argument was about recovery.conf which is a file that
users are expected to edit. A file which user's are not expected to
edit and is maintained by the software is no more a configuration file
than pg_auth or pg_database which are actually being
Andres Freund and...@2ndquadrant.com writes:
People, including me, every now and then forget to pass --enable-depend
to configure (when not using my own environment). Which then leads to
strange errors that cost time to track down...
Thus I'd like to enable dependency tracking by default.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
whole tree every time, and I trust the results a lot more than I do
--enable-depend.
This is a much more compelling point, imv. We definitely still have
issues around dependencies not being completely tracked, even with
--enable-depend. Makes one wonder
On Thu, Aug 1, 2013 at 1:12 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
we should review the implementation choice of the ALTER
SYSTEM SET facility, and vote for having one-file-per-GUC.
Zombie crazy design idea arise!
I think people are going to laugh at us if an open source database
Greg Stark st...@mit.edu writes:
I think people are going to laugh at us if an open source database
software can't manage a simple flat file database of settings,
especially one that is purely write-only and can be a simple dump of
settings that are set by alter system.
So you say it's easier
On 2013-08-01 15:55:25 +0200, Dimitri Fontaine wrote:
Greg Stark st...@mit.edu writes:
I think people are going to laugh at us if an open source database
software can't manage a simple flat file database of settings,
especially one that is purely write-only and can be a simple dump of
On 2013-08-01 08:34:51 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
People, including me, every now and then forget to pass --enable-depend
to configure (when not using my own environment). Which then leads to
strange errors that cost time to track down...
Thus
We don't need per guc locking. This is the whole objection Tom had about
this patch being more complex than it has to be.
--
greg
On 1 Aug 2013 14:55, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Greg Stark st...@mit.edu writes:
I think people are going to laugh at us if an open source
On 2013-08-01 15:17:04 +0100, Greg Stark wrote:
We don't need per guc locking. This is the whole objection Tom had about
this patch being more complex than it has to be.
IIRC he objected to using locking *at all* because a simple
one-file-per-setting approach should be used.
Greetings,
Andres
All,
I wanted to highlight the below commit as being a significant enough
change that it warrents being seen on -hackers and not just
-committers. If you use SSL with libpq, particularly in a threaded
mode/environment, please take a look/test this change. Prior to the
patch, we would
huxm wrote
where there is a
newline(\n) in the name.
I can't imagine why you would want to use non-printing characters in a name,
especially a database name. Even if the hba.conf file was able to interpret
it (which it probably cannot but I do not know for certain) client
interfaces are
Why isn't it enough to just dump out all variables with a source of alter
system to a text file? You can either have a single global lock around that
operation or write it to a new file and move it into place.
--
greg
On 1 Aug 2013 15:19, Andres Freund and...@2ndquadrant.com wrote:
On
Minor request: could someone enlighten me as to why making the directory
location a compile-time option is undesirable. Packagers then can setup
whatever structure they desire when they compile their distributions. In
which case the discussion becomes what is a reasonable default and that can
be
Hi,
On 2013-08-01 15:40:22 +0100, Greg Stark wrote:
Why isn't it enough to just dump out all variables with a source of alter
system to a text file? You can either have a single global lock around that
operation or write it to a new file and move it into place.
It saves you from several
From: Fujii Masao masao.fu...@gmail.com
However, isn't StandbyRequested true (= standby_mode set to on) to enable
warm standby?
We can set up warm-standby by using pg_standby even if standby_mode = off.
I see. However, I understand that pg_standby is a legacy feature, and the
current way
On Tue, Jul 23, 2013 at 2:16 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Alvaro Herrera wrote:
Peter Eisentraut wrote:
I would suggest that these changes be undone, except that the old
SELECT FOR ... be replaced by a dynamic string that reverse-parses the
LockingClause to provide
Robert Haas escribió:
The fact that there are no tests of this functionality is probably not
a good thing. We should add some.
No disagreement.
At the moment, the following test
case crashes, and it looks like this commit is responsible:
create table test_update2 (id integer);
DECLARE
On Sun, Jul 28, 2013 at 5:39 AM, Martijn van Oosterhout
klep...@svana.org wrote:
On Tue, Jul 23, 2013 at 10:34:21AM -0400, Robert Haas wrote:
I pretty much lost interest in ICU upon reading that they use UTF-16
as their internal format.
A pg_basebackup -Fp running on the same system as the target cluster will
fail in the presence of tablespaces; it would backup each tablespace to its
original path, and those paths are in use locally for the very originals we're
copying. pg_basebackup -Ft does not exhibit that hazard, and I
On Sun, Jul 28, 2013 at 1:26 AM, Amit kapila amit.kap...@huawei.com wrote:
1. Bgworker.c -
FindRegisteredWorkerBySlotNumber()
{
..
/*
* Copy contents of worker list into shared memory. Record the
* shared memory slot assigned to each
On Sun, Jul 28, 2013 at 2:50 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-07-28 02:23:47 +0200, Marko Tiikkaja wrote:
While you could limit the number of connections for non-replication roles,
that's not always possible or desirable. I would like to introduce a way to
reserve
Noah Misch n...@leadboat.com writes:
A pg_basebackup -Fp running on the same system as the target cluster will
fail in the presence of tablespaces; it would backup each tablespace to its
I'd like to see that fixed, +1.
1. Include in the base backup a file listing symbolic links/junction
Hi,
Please find attached to this email the latest and greatest version of
in-line SQL only extensions support, known as Extension Templates and
which could be renamed In-Catalog Extension Templates.
I've included a high-level description of the patch in a style that
targets the detailed commit
On 08/01/2013 12:15 PM, Noah Misch wrote:
A pg_basebackup -Fp running on the same system as the target cluster will
fail in the presence of tablespaces; it would backup each tablespace to its
original path, and those paths are in use locally for the very originals we're
copying. pg_basebackup
On 08/01/2013 07:47 AM, David Johnston wrote:
Minor request: could someone enlighten me as to why making the directory
location a compile-time option is undesirable. Packagers then can setup
whatever structure they desire when they compile their distributions. In
which case the discussion
Josh Berkus j...@agliodbs.com writes:
While I find some value in the one-setting-per-file approach, there's
also some major issues with it. And we already argued this out months
ago, and ended up with the current single-file approach. Let's not
rehash the past infinitely, please?
We rehash
On 07/26/2013 12:19 PM, Stephen Frost wrote:
Agreed. To continue that thought, I find it *very* unlikely that a
given environment would use *both* a tool like puppet to manage the
files in their conf.d *and* have people using ALTER SYSTEM SET. You're
going to do one or the other, almost
Dimitri,
We rehash because the situation did change *a lot*. We just decided that
the ALTER SYSTEM SET setup will live in PGDATA and will not have to be
edited by DBA nor sysadmin nor tools ever. We will have a separate
facility (conf.d) for that. As a result, I don't think there's any
On 2013-08-01 10:13:37 -0700, Josh Berkus wrote:
On 07/26/2013 12:19 PM, Stephen Frost wrote:
Agreed. To continue that thought, I find it *very* unlikely that a
given environment would use *both* a tool like puppet to manage the
files in their conf.d *and* have people using ALTER SYSTEM
On 2013-08-01 10:16:59 -0700, Josh Berkus wrote:
Dimitri,
We rehash because the situation did change *a lot*. We just decided that
the ALTER SYSTEM SET setup will live in PGDATA and will not have to be
edited by DBA nor sysadmin nor tools ever. We will have a separate
facility (conf.d)
Stephen Frost wrote:
All,
I wanted to highlight the below commit as being a significant enough
change that it warrents being seen on -hackers and not just
-committers. If you use SSL with libpq, particularly in a threaded
mode/environment, please take a look/test this change.
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
pgsecure_open_client() returns -1 if it can't lock the mutex. This is a
problem because the callers are not prepared for that return value. I
think it should return PGRES_POLLING_FAILED instead, after setting an
appropriate error message in
Josh Berkus j...@agliodbs.com writes:
Let's please NOT call it conf.d if it's living in PGDATA and is not
meant to be edited by hand. conf.d is for a directory of config files
created by users and external utilities, living in CONFIGDIR.
+1
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr
On 08/01/2013 10:24 AM, Andres Freund wrote:
Let's please NOT call it conf.d if it's living in PGDATA and is not
meant to be edited by hand. conf.d is for a directory of config files
created by users and external utilities, living in CONFIGDIR.
How nice that that's not what's being
Josh Berkus j...@agliodbs.com schrieb:
On 08/01/2013 10:24 AM, Andres Freund wrote:
Let's please NOT call it conf.d if it's living in PGDATA and is not
meant to be edited by hand. conf.d is for a directory of config
files
created by users and external utilities, living in CONFIGDIR.
How
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Andres Freund wrote:
Postgresql.auto.conf.d is what I'd propose, but the decision about
that seems to be one of the smaller problems around this feature...
That naming seems to make it sensible to extend other files (hba,
ident)
On Tue, Jul 30, 2013 at 10:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Fetter da...@fetter.org writes:
On Tue, Jul 30, 2013 at 04:40:38PM -0700, David Gudeman wrote:
When you write an application involving foreign tables, you frequently
end up with queries that are just too inefficient
On Fri, Aug 2, 2013 at 1:22 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jul 28, 2013 at 1:26 AM, Amit kapila amit.kap...@huawei.com
wrote:
2. Shouldn't function
do_start_bgworker()/StartOneBackgroundWorker(void) be moved to bgworker.c
as similar functions
Robert Haas escribió:
The fact that there are no tests of this functionality is probably not
a good thing. We should add some. At the moment, the following test
case crashes, and it looks like this commit is responsible:
create table test_update2 (id integer);
DECLARE test_update_cursor
Andres Freund and...@2ndquadrant.com writes:
They would need a setting that disables ALTER (DATABASE|USER) ... SET
... as well though. At least for some settings.
I don't think enforcing things on that level makes much sense.
If only we could trigger some actions when a command is about to be
On 2013-08-01 14:37:45 -0400, Stephen Frost wrote:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Andres Freund wrote:
Postgresql.auto.conf.d is what I'd propose, but the decision about
that seems to be one of the smaller problems around this feature...
That naming seems to make
* Andres Freund (and...@2ndquadrant.com) wrote:
People know what to expect from .d directories, that's why I suggested
it, don't feel really strongly about it. I dislike naming the
subdirectories pgconf/... et al though, we should reference the original
files name, instead of introducing new
On 2013-08-01 20:33:49 -0400, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
People know what to expect from .d directories, that's why I suggested
it, don't feel really strongly about it. I dislike naming the
subdirectories pgconf/... et al though, we should reference
* Andres Freund (and...@2ndquadrant.com) wrote:
I personally consider readers of this list persons... And even people
not interested in internals will have to look in there if they set
something stupid before. Like setting max_connections higher than the
currently configured kernel's max
On 2013-08-01 20:45:38 -0400, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
I personally consider readers of this list persons... And even people
not interested in internals will have to look in there if they set
something stupid before. Like setting max_connections
* Andres Freund (and...@2ndquadrant.com) wrote:
I agree that we need to do reasonable checks, like running GUC
validators, but we simply can't control the overall system state. And
it's not like this are errors that you couldn't get before. And we
should (that's something to improve on) report
Andres Freund-3 wrote
Even trying to do this completely will guarantee that this patch will
never, ever, suceed. There simply is no way to reliably detect problems
that have complex interactions with the rest of the system.
We can improve the detection rate of problems after some real world
* David Johnston (pol...@yahoo.com) wrote:
How about some form of persistence mechanism so that, before making these
kinds of changes, the admin can save the current configuration. Then, in
a worse case-scenario, they could run something like pg_ctl
--restore-persisted-configuration ... to
On Fri, Aug 2, 2013 at 12:24 AM, MauMau maumau...@gmail.com wrote:
From: Fujii Masao masao.fu...@gmail.com
However, isn't StandbyRequested true (= standby_mode set to on) to enable
warm standby?
We can set up warm-standby by using pg_standby even if standby_mode = off.
I see. However,
Hi,
FWIW, I think you've just put the final nail in the coffin of this
patch by raising the barriers unreasonably high.
* Andres Freund (and...@2ndquadrant.com) wrote:
I agree that we need to do reasonable checks, like running GUC
validators, but we simply can't control the overall system
* Andres Freund (and...@2ndquadrant.com) wrote:
FWIW, I think you've just put the final nail in the coffin of this
patch by raising the barriers unreasonably high.
For my 2c, I don't think it's an unreasonable idea to actually
*consider* what options are available through this mechanism rather
On Thu, Aug 1, 2013 at 8:27 PM, Stephen Frost sfr...@snowman.net wrote:
The point above is that we will always need some amount of external
config file and, as such, we should probably consider which items should
really only be set in the *config* files and which can be set in either
place.
Peter Eisentraut wrote:
On 7/4/13 5:06 PM, Alvaro Herrera wrote:
FWIW if changing the behavior of NOT NULL constraints is desired, I
still have the patch to catalogue them around, if anyone wants to play
around. I haven't gotten around to finishing it up, yet :-(
If your latest patch
On Thu, Aug 1, 2013 at 8:27 PM, Stephen Frost sfr...@snowman.net wrote:
The point above is that we will always need some amount of external
config file and, as such, we should probably consider which items should
really only be set in the *config* files and which can be set in either
On Mon, Jul 8, 2013 at 09:16:32AM +, Heikki Linnakangas wrote:
This has one user-visible change: switching to a new WAL segment with
pg_switch_xlog() now fills the remaining unused portion of the segment with
zeros. This potentially adds some overhead, but it has been a very common
On Friday, August 02, 2013 4:19 AM Michael Paquier wrote:
On Fri, Aug 2, 2013 at 1:22 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jul 28, 2013 at 1:26 AM, Amit kapila amit.kap...@huawei.com wrote:
2. Shouldn't function
do_start_bgworker()/StartOneBackgroundWorker(void) be moved to
Amit Kapila escribió:
On Friday, August 02, 2013 4:19 AM Michael Paquier wrote:
On Fri, Aug 2, 2013 at 1:22 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jul 28, 2013 at 1:26 AM, Amit kapila amit.kap...@huawei.com
wrote:
2. Shouldn't function
On Mon, Jul 8, 2013 at 06:25:44PM -0700, Peter Geoghegan wrote:
When rebasing a patch that I'm working on, I occasionally forget to
update the oid of any pg_proc.h entries I may have created. Of course
this isn't a real problem; when I go to initdb, I immediately
recognize what has happened.
Hi all
Andres and I were going over a patch yesterday and found an unexpected
bug in tqual.c while attempting to trigger a hypothesized bug in that patch.
A SELECT ... FOR SHARE will incorrectly block on another open
transaction that ran SELECT ... FOR SHARE and still holds the locks if
it has
69 matches
Mail list logo
