On 21 January 2014 22:28, Alvaro Herrera wrote:
> I have been mulling over this patch, and I can't seem to come to terms
> with it. I first started making it look nicer here and there, thinking
> it was all mostly okay, but eventually arrived at the idea that it seems
> wrong to do what this does
> I, as a user would be happier if we also have to_regprocedure() and
> to_regoperator(). The following query looks a valid use-case where one
> needs to find if a particular function exists. Using to_regproc('sum') does
> not make sense here because it will return InvalidOid, which will not tell
>
On Wed, Jan 22, 2014 at 1:21 AM, Heikki Linnakangas wrote:
> On 01/21/2014 11:35 AM, Heikki Linnakangas wrote:
>
>> On 01/21/2014 04:02 AM, Tomas Vondra wrote:
>>
>>> On 20.1.2014 19:30, Heikki Linnakangas wrote:
>>>
Attached is a yet another version, with more bugs fixed and more
Hello,
> >> Since this becomes more than a simple bug fix, I think it is too
> >> late for 9.4 now. I'll work on this in the longer term.
>
> OK. I will get around to it someday, but if you do it first, that's fine.
Nevertheless of my words, the drive is getting diminished after
the issue was s
On Tue, Jan 21, 2014 at 9:53 PM, Tom Lane wrote:
> Jon Nelson writes:
>> A rough summary of the patch follows:
>
>> - a GUC variable enables or disables this capability
>> - in nodeAgg.c, eliding duplicate tuples is enabled if the number of
>> distinct columns is equal to the number of sort col
On Tue, Jan 21, 2014 at 8:25 PM, Robert Haas wrote:
> On Fri, Jan 17, 2014 at 12:07 AM, Amit Kapila wrote:
>> On Fri, Jan 17, 2014 at 12:16 AM, Tom Lane wrote:
>>> PS: off topic, but isn't ParseConfigDirectory leaking the result
>>> of AbsoluteConfigLocation? In both normal and error paths?
>>
On Tue, Jan 21, 2014 at 7:29 PM, Kyotaro HORIGUCHI
wrote:
> This apparently seems that the query passing through
> pg_stat_statements twice during single execution. Actually, the
> first one is a by-product of planning (simplify_function) and the
> second is just what expected by users. It surely
On Wed, Jan 22, 2014 at 9:19 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Tue, Jan 21, 2014 at 6:57 PM, MauMau wrote:
>>> To follow this, we have the line as:
>>>
>>> #event_source = 'PostgreSQL 9.4'
>>>
>>> But this requires us to change this line for each major release. That's a
>>> mainte
On Tue, Jan 21, 2014 at 8:01 PM, Peter Geoghegan wrote:
> Not necessarily. Under Linux for example, POSIX_FADV_SEQUENTIAL "sets
> the readahead window to the default size for the backing device"
Excuse me; I meant to put "POSIX_FADV_SEQUENTIAL doubles this size
[default size for the backing devic
On Tue, Jan 21, 2014 at 6:22 PM, Tom Lane wrote:
> BTW, what is the value of using posix_fadvise() in warm_fcache?
>
> ISTM that if you're worried about waiting for I/O while holding the
> LWLock (as I concur you should be), this coding is entirely inadequate
> for preventing that, as the whole po
On Wed, Jan 22, 2014 at 1:15 AM, Robert Haas wrote:
> On Tue, Jan 21, 2014 at 7:47 AM, Michael Paquier
> wrote:
After going through commit 65d6e4c (introducing ALTER SYSTEM SET), I
noticed a couple of typo mistakes as well as (I think) a weird way of
using the temporary auto-config
Jon Nelson writes:
> A rough summary of the patch follows:
> - a GUC variable enables or disables this capability
> - in nodeAgg.c, eliding duplicate tuples is enabled if the number of
> distinct columns is equal to the number of sort columns (and both are
> greater than zero).
> - in createp
Amit Kapila writes:
> On Tue, Jan 21, 2014 at 6:57 PM, MauMau wrote:
>> To follow this, we have the line as:
>>
>> #event_source = 'PostgreSQL 9.4'
>>
>> But this requires us to change this line for each major release. That's a
>> maintenance headache.
> What I had in mind was to change it du
On 31st December 2013, Christian Kruse Wrote:
> Hi there,
>
> I created two patches improving the log messages generated by
> log_lock_waits. The first patch shows the process IDs holding a lock we
> try to acquire (show_pids_in_lock_log.patch), sample output
> (log_lock_waits=on required):
>
Florian Pflug writes:
> On Jan21, 2014, at 18:56 , Tom Lane wrote:
>> Robert Haas writes:
>>> it wouldn't play nice with GCC's desire to check format strings.
>> That last is a deal-breaker. It's not just whether "gcc desires" to check
>> this --- we *need* that checking, because people get it
On Tue, Jan 21, 2014 at 6:57 PM, MauMau wrote:
> From: "Amit Kapila"
>> Today, I reviewed the patch again and found it okay, except a small
>> inconsistency which is about default event source name in
>> postgresql.conf, all other places it's changed except in .conf file.
>> Do you think it makes
Hello,
tgl> > So this is fixed by quite simple way like following getting rid
tgl> > of the referred difficulties of keeping the code sane and total
tgl> > loss of token locations. (white spaces are collapsed for readability)
tgl>
tgl> Committed with minor adjustments (improved comments, and hit
Hi, considering on pg_stat_statements itself,
pg> There was a more obvious case of this that I noticed during the
pg> development of pg_stat_statements query normalization. As you may have
pg> noticed, that was addressed by this commit:
pg>
pg>
http://git.postgresql.org/gitweb/?p=postgresql.git;
Greetings -hackers:
I have worked up a patch to PostgreSQL which elides tuples during an
external sort. The primary use case is when sorted input is being used
to feed a DISTINCT operation. The idea is to throw out tuples that
compare as identical whenever it's convenient, predicated on the
assump
On Jan21, 2014, at 18:56 , Tom Lane wrote:
> Robert Haas writes:
>> Perhaps we should jettison entirely the idea of using the operating
>> system's built-in sprintf and use one of our own that has all of the
>> nice widgets we need, like a format code that's guaranteed to be right
>> for uint64 a
Andres Freund writes:
> On 2014-01-21 20:00:51 -0500, Stephen Frost wrote:
>> Don't know what folks think of removing those in-the-function checks in
>> favor of trusting the grant/revoke system to not allow those functions
>> to be called unless you have EXECUTE privileges on them..
> Well, they
(2014/01/22 1:37), Robert Haas wrote:
On Mon, Jan 20, 2014 at 11:23 PM, KaiGai Kohei wrote:
I briefly checked the patch. Most of lines are mechanical replacement
from LWLockId to LWLock *, and compiler didn't claim anything with
-Wall -Werror option.
My concern is around LWLockTranche mechanis
Andres Freund writes:
> On 2014-01-21 19:45:19 -0500, Tom Lane wrote:
>> I don't think that's a comparable case. Incomplete actions are actions
>> to be taken immediately, and which the replayer then has to complete
>> somehow if it doesn't find the rest of the action in the WAL sequence.
>> The
BTW, what is the value of using posix_fadvise() in warm_fcache?
ISTM that if you're worried about waiting for I/O while holding the
LWLock (as I concur you should be), this coding is entirely inadequate
for preventing that, as the whole point of posix_fadvise is that it
won't wait around for the I
On Wed, Jan 22, 2014 at 6:37 AM, Heikki Linnakangas
wrote:
> On 01/21/2014 07:31 PM, Fujii Masao wrote:
>>
>> On Fri, Dec 20, 2013 at 9:21 PM, MauMau wrote:
>>>
>>> From: "Fujii Masao"
>>>
! if (source == XLOG_FROM_ARCHIVE && StandbyModeRequested)
Even when standby_mode is not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El 21/01/14 20:11, Devrim GÜNDÜZ escribió:
>
> Hi,
>
> On Tue, 2014-01-21 at 20:19 -0200, Martín Marqués wrote:
>> I was updating the packages from one of my servers and I got
>> this message:
>>
>> Package python-psycopg2-doc-2.5.2-1.f19.x86_64.rpm
Hello,
> > > This patch consists of two parts,
> > >
> > > 0001_expose_explain_triggers_v1_20140114.patch
>
> > > 0002_auto_explain_triggers_v1_20140114.patch
>
> > > Documentation will be added later..
>
> > I think documentation is the only thing that stops this patch to be
> > commitable..
On 21.1.2014 22:21, Heikki Linnakangas wrote:
> On 01/21/2014 11:35 AM, Heikki Linnakangas wrote:
>> On 01/21/2014 04:02 AM, Tomas Vondra wrote:
>>> On 20.1.2014 19:30, Heikki Linnakangas wrote:
Attached is a yet another version, with more bugs fixed and more
comments added and updat
On Tue, Jan 21, 2014 at 5:22 PM, Mark Kirkwood
wrote:
> On 22/01/14 13:32, Harold Giménez wrote:
>>
>> On Tue, Jan 21, 2014 at 4:19 PM, Bruce Momjian wrote:
>>>
>>> On Tue, Jan 21, 2014 at 04:06:46PM -0800, Harold Giménez wrote:
I don't know of a client where it can't be overridden. The
On 22/01/14 13:32, Harold Giménez wrote:
On Tue, Jan 21, 2014 at 4:19 PM, Bruce Momjian wrote:
On Tue, Jan 21, 2014 at 04:06:46PM -0800, Harold Giménez wrote:
I don't know of a client where it can't be overridden. The friction
occurs when by default it sets it to something useful to a develope
On 2014-01-21 20:18:54 -0500, Stephen Frost wrote:
> > > Don't know what folks think of removing those in-the-function checks in
> > > favor of trusting the grant/revoke system to not allow those functions
> > > to be called unless you have EXECUTE privileges on them..
> >
> > Well, they *do* ret
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-01-21 20:00:51 -0500, Stephen Frost wrote:
> > * Josh Berkus (j...@agliodbs.com) wrote:
> > > It would be really nice to be able to GRANT/REVOKE on some of these
> > > special system views ...
>
> Just define a security definer wrapper func
On Jan20, 2014, at 15:20 , Florian Pflug wrote:
> * In CREATE AGGREGATE, we should state the precise axioms we assume about
> forward
> and inverse transition functions. The last time I read the text there, it was
> a bit ambiguous about whether inverse transition functions assume
> commutativit
On 2014-01-21 20:00:51 -0500, Stephen Frost wrote:
> * Josh Berkus (j...@agliodbs.com) wrote:
> > It would be really nice to be able to GRANT/REVOKE on some of these
> > special system views ...
Just define a security definer wrapper function + view, that afair works
perfectly fine.
> Well, we ac
* Josh Berkus (j...@agliodbs.com) wrote:
> It would be really nice to be able to GRANT/REVOKE on some of these
> special system views ...
Well, we actually *can* issue grant/revoke against the underlying
function calls, but we are also doing permissions checks *in* those
functions, ignoring our ow
On 2014-01-21 19:45:19 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-01-21 19:23:57 -0500, Tom Lane wrote:
> >> I'm not suggesting that we stop providing that information! I'm just
> >> saying that we perhaps don't need to store it all in one WAL record,
> >> if instead we put the on
On Tue, Jan 21, 2014 at 4:53 PM, Josh Berkus wrote:
> It would be really nice to be able to GRANT/REVOKE on some of these
> special system views ...
I think this would be ideal, too.
-Harold
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
On 01/21/2014 04:12 AM, Stephen Frost wrote:
>> It also means that monitoring tools must run as superuser to see
>> > information they require, which to me is a total showstopper.
> We've already got *far* too much of that going on for my taste. I'd
> love to see a comprehensive solution to this p
On Tue, Jan 21, 2014 at 4:46 PM, Stephen Frost wrote:
> * Harold Giménez (har...@heroku.com) wrote:
>> This is a separate topic, but in such a case I'd want to know that
>> I've reached max_connections, which may not be a problem if I just
>> don't need any more connections, but I still need somet
On 2014-01-21 16:34:45 -0800, Peter Geoghegan wrote:
> On Tue, Jan 21, 2014 at 3:43 PM, Andres Freund wrote:
> > I personally think this isn't worth complicating the code for.
>
> You're probably right. However, I don't see why the bar has to be very
> high when we're considering the trade-off be
Andres Freund writes:
> On 2014-01-21 19:23:57 -0500, Tom Lane wrote:
>> I'm not suggesting that we stop providing that information! I'm just
>> saying that we perhaps don't need to store it all in one WAL record,
>> if instead we put the onus on WAL replay to be able to reconstruct what
>> it ne
* Harold Giménez (har...@heroku.com) wrote:
> This is a separate topic, but in such a case I'd want to know that
> I've reached max_connections, which may not be a problem if I just
> don't need any more connections, but I still need something connecting
> to make sure the service is available at a
On Tue, Jan 21, 2014 at 4:38 PM, Stephen Frost wrote:
> * Harold Giménez (har...@heroku.com) wrote:
>> Definitely agree with you. This is just an example of how running
>> monitoring as superuser is not necessarily the worst thing, and there
>> are other reasons to do it already.
>
> It's a horrib
* Harold Giménez (har...@heroku.com) wrote:
> Definitely agree with you. This is just an example of how running
> monitoring as superuser is not necessarily the worst thing, and there
> are other reasons to do it already.
It's a horrible thing and that isn't a good reason- if my database isn't
acc
On 2014-01-21 19:23:57 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-01-21 18:59:13 -0500, Tom Lane wrote:
> >> Another thing to think about is whether we couldn't put a hard limit on
> >> WAL record size somehow. Multi-megabyte WAL records are an abuse of the
> >> design anyway, whe
On 21 January 2014 21:19, Peter Geoghegan wrote:
> On Tue, Jan 21, 2014 at 11:48 AM, Simon Riggs wrote:
>> I agree with people saying that stddev is better than nothing at all,
>> so I am inclined to commit this, in spite of the above.
>
> I could live with stddev. But we really ought to be inves
On Tue, Jan 21, 2014 at 3:43 PM, Andres Freund wrote:
> I personally think this isn't worth complicating the code for.
You're probably right. However, I don't see why the bar has to be very
high when we're considering the trade-off between taking some
emergency precaution against having a PANIC s
On Tue, Jan 21, 2014 at 4:19 PM, Bruce Momjian wrote:
> On Tue, Jan 21, 2014 at 04:06:46PM -0800, Harold Giménez wrote:
>> I don't know of a client where it can't be overridden. The friction
>> occurs when by default it sets it to something useful to a developer
>> (useful eg: to find what process
Andres Freund writes:
> How are we supposed to wait while e.g. ProcArrayLock? Aborting
> transactions doesn't work either, that writes abort records which can
> get signficantly large.
Yeah, that's an interesting point ;-). We can't *either* commit or abort
without emitting some WAL, possibly qu
Andres Freund writes:
> On 2014-01-21 18:59:13 -0500, Tom Lane wrote:
>> Another thing to think about is whether we couldn't put a hard limit on
>> WAL record size somehow. Multi-megabyte WAL records are an abuse of the
>> design anyway, when you get right down to it. So for example maybe we
>>
On 2014-01-22 01:18:36 +0100, Simon Riggs wrote:
> > My understanding is that if it runs out of buffer space while in an
> > XLogInsert, it will be holding one or more buffer content locks exclusively,
> > and unless it can complete the xlog (or scrounge up the info to return that
> > buffer to its
On Tue, Jan 21, 2014 at 04:06:46PM -0800, Harold Giménez wrote:
> I don't know of a client where it can't be overridden. The friction
> occurs when by default it sets it to something useful to a developer
> (useful eg: to find what process is holding a lock), but is not
> possible to conceal from o
On 21 January 2014 23:01, Jeff Janes wrote:
> On Tue, Jan 21, 2014 at 9:35 AM, Tom Lane wrote:
>>
>> Simon Riggs writes:
>> > On 6 June 2013 16:00, Heikki Linnakangas
>> > wrote:
>> >> The current situation is that if you run out of disk space while
>> >> writing
>> >> WAL, you get a PANIC, and
On 2014-01-21 18:59:13 -0500, Tom Lane wrote:
> Another thing to think about is whether we couldn't put a hard limit on
> WAL record size somehow. Multi-megabyte WAL records are an abuse of the
> design anyway, when you get right down to it. So for example maybe we
> could split up commit records
On Tue, Jan 21, 2014 at 4:01 PM, Bruce Momjian wrote:
> On Tue, Jan 21, 2014 at 03:57:37PM -0800, Harold Giménez wrote:
>> > It also means that monitoring tools must run as superuser to see
>> > information they require, which to me is a total showstopper.
>>
>>
>> Well, the fact is that if you do
On Tue, Jan 21, 2014 at 7:25 AM, Tom Lane wrote:
> Stephen Frost writes:
>> * Craig Ringer (cr...@2ndquadrant.com) wrote:
>>> If you want control over visibility of application_name, it should be
>>> done with a column privilige granted to a system role, or something like
>>> that - so the abilit
On Wed, Jan 22, 2014 at 5:29 AM, Alvaro Herrera
wrote:
> I agree with Michael that having pg_basebackup be aware of the ".temp"
> suffix is ugly; for instance if we were to fix it to ".tmp" in ALTER
> SYSTEM but forgot to change pg_basebackup, the check would be
> immediately broken. But on the o
On Tue, Jan 21, 2014 at 03:57:37PM -0800, Harold Giménez wrote:
> > It also means that monitoring tools must run as superuser to see
> > information they require, which to me is a total showstopper.
>
>
> Well, the fact is that if you don't run monitoring tools as superuser,
> there may not be en
Andres Freund writes:
> On 2014-01-21 18:24:39 -0500, Tom Lane wrote:
>> Maybe we could get some mileage out of the fact that very approximate
>> techniques would be good enough. For instance, I doubt anyone would bleat
>> if the system insisted on having 10MB or even 100MB of future WAL space
>>
On Tue, Jan 21, 2014 at 12:31 AM, Craig Ringer wrote:
>
> On 01/21/2014 04:19 PM, Heikki Linnakangas wrote:
> > On 01/21/2014 07:22 AM, Harold Giménez wrote:
> >> First of all, I apologize for submitting a patch and missing the
> >> commitfest
> >> deadline. Given the size of the patch, I thought
On 01/21/2014 06:21 PM, Marko Tiikkaja wrote:
Hi Andrew,
On 1/18/14, 10:05 PM, I wrote:
But I'll continue with my review now that this has been sorted out.
Sorry about the delay.
I think the API for the new functions looks good. They are all
welcome additions to the JSON family.
The imp
On 2014-01-21 18:24:39 -0500, Tom Lane wrote:
> Jeff Janes writes:
> > On Tue, Jan 21, 2014 at 9:35 AM, Tom Lane wrote:
> >> My preference would be that we simply start failing writes with ERRORs
> >> rather than PANICs. I'm not real sure ATM why this has to be a PANIC
> >> condition. Probably
On Tue, Jan 21, 2014 at 3:24 PM, Tom Lane wrote:
> Maybe we could get some mileage out of the fact that very approximate
> techniques would be good enough. For instance, I doubt anyone would bleat
> if the system insisted on having 10MB or even 100MB of future WAL space
> always available. But I
Jeff Janes writes:
> On Tue, Jan 21, 2014 at 9:35 AM, Tom Lane wrote:
>> My preference would be that we simply start failing writes with ERRORs
>> rather than PANICs. I'm not real sure ATM why this has to be a PANIC
>> condition. Probably the cause is that it's being done inside a critical
>> s
Hi Andrew,
On 1/18/14, 10:05 PM, I wrote:
But I'll continue with my review now that this has been sorted out.
Sorry about the delay.
I think the API for the new functions looks good. They are all welcome
additions to the JSON family.
The implementation side looks reasonable to me. I'm no
Hi,
On Tue, 2014-01-21 at 20:19 -0200, Martín Marqués wrote:
> I was updating the packages from one of my servers and I got this
> message:
>
> Package python-psycopg2-doc-2.5.2-1.f19.x86_64.rpm is not signed
>
> If I remove the package (I thought it might be that package alone) I
> get errors
On 2014-01-21 16:13:11 -0500, Robert Haas wrote:
> On Tue, Jan 21, 2014 at 3:37 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> I kind of agree with Thom. I understand why it's doing what it's
> >> doing, but it still seems sort of lame.
> >
> > Well, the point of the message is to report that
On 01/21/2014 12:29 PM, Robert Haas wrote:
On Tue, Jan 21, 2014 at 1:59 PM, Thom Brown wrote:
On 21 January 2014 18:35, Tom Lane wrote:
Thom Brown writes:
I'm getting a report of a config error when changing a config value
that requires a restart:
...
2014-01-21 18:14:53 GMT [28718]: [4-1]
I have been mulling over this patch, and I can't seem to come to terms
with it. I first started making it look nicer here and there, thinking
it was all mostly okay, but eventually arrived at the idea that it seems
wrong to do what this does: basically, get_object_address() tries to
obtain an obje
I was updating the packages from one of my servers and I got this message:
Package python-psycopg2-doc-2.5.2-1.f19.x86_64.rpm is not signed
If I remove the package (I thought it might be that package alone) I
get errors from other packages:
Package python-psycopg2-2.5.2-1.f19.x86_64.rpm is not s
I realize the following should be applied on the top of v7:
index a0216c1..16dd939 100644
--- a/src/backend/replication/basebackup.c
+++ b/src/backend/replication/basebackup.c
@@ -1263,7 +1263,7 @@ throttle(size_t increment)
throttling_counter %= throttling_sample;
/* Once the (po
On Tue, Jan 21, 2014 at 9:35 AM, Tom Lane wrote:
> Simon Riggs writes:
> > On 6 June 2013 16:00, Heikki Linnakangas
> wrote:
> >> The current situation is that if you run out of disk space while writing
> >> WAL, you get a PANIC, and the server shuts down. That's awful.
>
> > I don't see we nee
On Tue, Jan 21, 2014 at 06:43:54AM -0500, Christian Convey wrote:
> Hi all,
>
> I'm playing around with Postgres, and I thought it might be fun to experiment
> with alternative formats for relation blocks, to see if I can get smaller
> files
> and/or faster server performance.
>
> Does anyone kn
Robert Haas writes:
> The only real argument for the message:
> LOG: configuration file "/home/thom/Development/data/postgresql.conf"
> contains errors; unaffected changes were applied
> ...is that somebody might think that the presence of a single error
> caused all the changes to be ignored.
Greg Stark writes:
> Fwiw I think "all transactions lock up until space appears" is *much*
> better than PANICing. Often disks fill up due to other transient
> storage or people may have options to manually increase the amount of
> space. it's much better if the database just continues to function
On 01/21/2014 07:31 PM, Fujii Masao wrote:
On Fri, Dec 20, 2013 at 9:21 PM, MauMau wrote:
From: "Fujii Masao"
! if (source == XLOG_FROM_ARCHIVE && StandbyModeRequested)
Even when standby_mode is not enabled, we can use cascade replication and
it needs the accumulated WAL files. So I thi
Kyotaro HORIGUCHI writes:
> The fundamental cause of this issue is Const node which conveys
> the location of other than constant tokens. Any other nodes, for
> instance TypeCasts, are safe.
> So this is fixed by quite simple way like following getting rid
> of the referred difficulties of keepin
Robert Haas escribió:
> I don't think there's any real reason to defined
> PG_AUTOCONF_FILENAME_TEMP. pg_stat_statements just writes
> PGSS_DUMP_FILE ".tmp" and that hasn't been a problem that I know of.
> I do wonder why ALTER SYSTEM SET is spelling the suffix "temp" instead
> of "tmp".
I agree
o the page, or
pages if it had to be split.
The same subroutines to disassemble and recompress are also used in vacuum.
Attached is what I've got now. This is again quite heavily-changed from
the previous version - sorry for repeatedly rewriting this. I'll
continue testing and re
On Tue, Jan 21, 2014 at 3:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> I kind of agree with Thom. I understand why it's doing what it's
>> doing, but it still seems sort of lame.
>
> Well, the point of the message is to report that we failed to apply
> all the settings requested by the file.
All,
pg_isready works against older versions of PostgreSQL. Does anyone know
if there's a limit to that? v3 protocol change? Something else?
Backwards compatibility ought to be in its docs, but to fix that I need
to know what version it's compatible *to*.
--
Josh Berkus
PostgreSQL Experts In
Fwiw I think "all transactions lock up until space appears" is *much*
better than PANICing. Often disks fill up due to other transient
storage or people may have options to manually increase the amount of
space. it's much better if the database just continues to function
after that rather than need
Robert Haas writes:
> I kind of agree with Thom. I understand why it's doing what it's
> doing, but it still seems sort of lame.
Well, the point of the message is to report that we failed to apply
all the settings requested by the file. If you prefer some wording
squishier than "error", we coul
On Tue, Jan 21, 2014 at 1:59 PM, Thom Brown wrote:
> On 21 January 2014 18:35, Tom Lane wrote:
>> Thom Brown writes:
>>> I'm getting a report of a config error when changing a config value
>>> that requires a restart:
>>> ...
>>> 2014-01-21 18:14:53 GMT [28718]: [4-1] user=,db=,client= LOG:
>>>
On Tue, Jan 21, 2014 at 5:01 PM, Миша Тюрин wrote:
> And does anyone know how mysql-innodb guys are getting with similar issues?
I'm no innodb dev, but from managing mysql databases, I can say that
mysql simply eats all the RAM the admin is willing to allocate for the
DB, and is content with the
Vik Fearing wrote:
> On 01/20/2014 10:31 PM, Tom Lane wrote:
> > I think the idea was that patch authors should take responsibility for
> > pushing their patches forward to 2014-01 if they still wanted them
> > considered. Quite a few patches already were moved that way, IIRC.
> >
> > Agreed thoug
On Tue, Jan 21, 2014 at 11:48 AM, Simon Riggs wrote:
> I agree with people saying that stddev is better than nothing at all,
> so I am inclined to commit this, in spite of the above.
I could live with stddev. But we really ought to be investing in
making pg_stat_statements work well with third-pa
On Tue, Jan 21, 2014 at 3:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> One thing that's bugging me a bit about this whole line of attack is
>> that, in the first instance, the whole goal here is to support
>> inheritance hierarchies that mix ordinary tables with foreign tables.
>> If you have
On 01/21/2014 02:48 PM, Simon Riggs wrote:
I agree with people saying that stddev is better than nothing at all,
so I am inclined to commit this, in spite of the above. Any objections
to commit?
I have not been following terribly closely, but if it includes stddev
then yes, please do, many
Robert Haas writes:
> One thing that's bugging me a bit about this whole line of attack is
> that, in the first instance, the whole goal here is to support
> inheritance hierarchies that mix ordinary tables with foreign tables.
> If you have a table with children some of which are inherited and
>
Hi
But maybe postgres should provide its own subsystem like linux active/inactive
memory over and/or near shared buffers? There
could be some postgres special heuristics in its own approach.
And does anyone know how mysql-innodb guys are getting with similar issues?
Thank you!
On Wed, Dec 18, 2013 at 12:21:08PM -0500, Robert Haas wrote:
> On Tue, Dec 10, 2013 at 6:26 PM, Tom Lane wrote:
> > The larger point is that such a shutdown process has never in the history
> > of Postgres been successful at removing shared-memory (or semaphore)
> > resources. I do not feel a nee
On Tue, Jan 21, 2014 at 12:30 AM, Kyotaro HORIGUCHI
wrote:
> The fundamental cause of this issue is Const node which conveys
> the location of other than constant tokens. Any other nodes, for
> instance TypeCasts, are safe.
>
> So this is fixed by quite simple way like following getting rid
> of t
On 21 January 2014 12:54, KONDO Mitsumasa wrote:
> Rebased patch is attached.
Does this fix the Windows bug reported by Kumar on 20/11/2013 ?
> pg_stat_statements in PG9.4dev has already changed table columns in. So I
> hope this patch will be committed in PG9.4dev.
I've read through the preced
On Tue, Jan 21, 2014 at 7:47 AM, Michael Paquier
wrote:
>>> After going through commit 65d6e4c (introducing ALTER SYSTEM SET), I
>>> noticed a couple of typo mistakes as well as (I think) a weird way of
>>> using the temporary auto-configuration name postgresql.auto.conf.temp
>>> in two different
Kyotaro HORIGUCHI writes:
>> - CURRENT_TIME and the like are parsed into the nodes directly
>> represents the node specs in gram.y
>>
>> Since this becomes more than a simple bug fix, I think it is too
>> late for 9.4 now. I'll work on this in the longer term.
OK. I will get around to it someda
On 01/20/2014 10:31 PM, Tom Lane wrote:
> I think the idea was that patch authors should take responsibility for
> pushing their patches forward to 2014-01 if they still wanted them
> considered. Quite a few patches already were moved that way, IIRC.
>
> Agreed though that we shouldn't let them ju
On Mon, Jan 20, 2014 at 9:44 PM, Shigeru Hanada
wrote:
> Thanks for the comments.
>
> 2014/1/21 KaiGai Kohei :
>>> In addition, an idea which I can't throw away is to assume that all
>>> constraints defined on foreign tables as ASSERTIVE. Foreign tables
>>> potentially have dangers to have "wrong
On Tue, Jan 21, 2014 at 2:00 AM, Amit Kapila wrote:
> On Mon, Jan 20, 2014 at 9:49 PM, Robert Haas wrote:
>> I ran Heikki's test suit on latest master and latest master plus
>> pgrb_delta_encoding_v4.patch on a PPC64 machine, but the results
>> didn't look too good. The only tests where the WAL
Albe Laurenz writes:
> I believe that a column of a foreign table should be NOT NULL only if
> it is guaranteed that it cannot contain NULL values. Doesn't the planner
> rely on that?
The planner does expect that constraints tell the truth. I don't remember
how significant a false NOT NULL cons
1 - 100 of 157 matches
Mail list logo
