On Friday, August 02, 2013 4:34 AM Dimitri Fontaine wrote:
> Andres Freund 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 co
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 to
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 happene
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 wrote:
> >> On Sun, Jul 28, 2013 at 1:26 AM, Amit kapila
> >> wrote:
> >>> 2. Shouldn't function
> >>> do_start_bgworker()/StartOneBackgroundWorker(void) be moved t
On Friday, August 02, 2013 4:19 AM Michael Paquier wrote:
On Fri, Aug 2, 2013 at 1:22 AM, Robert Haas wrote:
On Sun, Jul 28, 2013 at 1:26 AM, Amit kapila wrote:
>>> 2. Shouldn't function
>>> do_start_bgworker()/StartOneBackgroundWorker(void) be moved to
bgworker.c
>>> as similar functions Aut
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
> pra
> On Thu, Aug 1, 2013 at 8:27 PM, Stephen Frost 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.
I thin
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
On Thu, Aug 1, 2013 at 8:27 PM, Stephen Frost 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.
What settings di
* 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
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 syst
On Fri, Aug 2, 2013 at 12:24 AM, MauMau wrote:
> From: "Fujii Masao"
>
> 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_
* 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 ...
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 wo
* 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) rep
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_connect
* 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 nu
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 ref
* 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 ne
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
Andres Freund 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
executed, in a way
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_cu
On Fri, Aug 2, 2013 at 1:22 AM, Robert Haas wrote:
> On Sun, Jul 28, 2013 at 1:26 AM, Amit kapila
> wrote:
> > 2. Shouldn't function
> > do_start_bgworker()/StartOneBackgroundWorker(void) be moved to bgworker.c
> >as similar functions AutoVacWorkerMain()/PgArchiverMain() are in
> their respe
On Tue, Jul 30, 2013 at 10:22 PM, Tom Lane wrote:
> David Fetter 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 because they bring
>>> too mu
* 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
Josh Berkus 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 nice
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 d
Josh Berkus 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 PostgreSQL
* 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
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.
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
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 SYS
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
> i
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 c
Josh Berkus 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 because the si
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
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_basebacku
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 commi
Noah Misch 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 points,
> then hav
On Sun, Jul 28, 2013 at 2:50 PM, Andres Freund 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 connection slots for
On Sun, Jul 28, 2013 at 1:26 AM, Amit kapila wrote:
> 1. Bgworker.c -
> FindRegisteredWorkerBySlotNumber()
> {
> ..
> /*
> * Copy contents of worker list into shared memory. Record the
> * shared memory slot assigned to each worker. This ensu
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 ty
On Sun, Jul 28, 2013 at 5:39 AM, Martijn van Oosterhout
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.
>>
>> http://userguide.icu-project.org/strings#TOC-Strings-in-ICU
>
> T
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);
> DE
On Tue, Jul 23, 2013 at 2:16 PM, Alvaro Herrera
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 the actual
From: "Fujii Masao"
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 to setup a warm stand
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 com
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
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" wrote:
> On 2013-08-01 15:17:04 +0100, G
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 like
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 c
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,
Andre
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" wrote:
> Greg Stark writes:
> > I think people are going to laugh at us if an open source database
> > software can't manage
On 2013-08-01 08:34:51 -0400, Tom Lane wrote:
> Andres Freund 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 ena
On 2013-08-01 15:55:25 +0200, Dimitri Fontaine wrote:
> Greg Stark 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
Greg Stark 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 to implem
On Thu, Aug 1, 2013 at 1:12 PM, Dimitri Fontaine 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
software can't manage
* 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
Andres Freund 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. Given todays
> computi
Greg Stark 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 stored in th
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 seem
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 i
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 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 wrote:
>
>> Jeevan Chalke writes:
>> > Oops forgot patch.
>> > Attached now.
>>
>> Hmm ... I think the logic change is good, but two demerits for not fixing
>
On Thu, Aug 1, 2013 at 3:52 PM, Amit Langote 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 rebuilt after "
65 matches
Mail list logo
