Rushabh Lathia wrote:
> I found constraints on foreign table is very useful for the application when
> the multiple
> user accessing same remote table using fdw and both user want to enforce
> different
> constraint on particular table or different user want to enforce different
> DEFAULT
> expr
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 I'd submit it for your
consideration regardless.
This patch prevents non-superusers from viewing other user's
pg_stat_activit
Hi Pavel,
Consider following test scenario:
mydb=# \d emp
Table "public.emp"
Column | Type | Modifiers
+-+---
empno | integer | not null
deptno | integer |
ename | text|
Indexes:
"emp_pkey" PRIMARY KEY, btree (empno)
Foreign-key constraints:
"emp
Hello, I found it would be reasonably fixed by small
modifications.
> - 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 ter
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 I'd submit it for your
>> consideration regardless.
>>
>> This patc
On 21 January 2014 01:09, KaiGai Kohei wrote:
> (2014/01/13 22:53), Craig Ringer wrote:
>>
>> On 01/09/2014 11:19 PM, Tom Lane wrote:
>>>
>>> Dean Rasheed writes:
My first thought was that it should just preprocess any security
barrier quals in subquery_planner() in the same way as
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 updated. I would appreciate some heavy-testing of
this patch now. If you could re-run the tests you've been using,
that c
On Sun, Dec 15, 2013 at 2:00 PM, Tom Lane wrote:
> Greg Stark writes:
> > On 14 Dec 2013 15:40, "Tom Lane" wrote:
> >> I think you *can't* cover them for the float types; roundoff error
> >> would mean you don't get the same answers as before.
>
> > I was going to say the same thing. But then I
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 know if this has been done before with Postgres? I would have
assumed yes, but I'm n
On Jan21, 2014, at 10:53 , David Rowley wrote:
> It came to me that it might be possible to implement inverse transitions
> for floating point aggregates by just detecting if precision has been
> lost during forward transitions.
>
> I've written the test to do this as:
>
> IF state.value + value
Rebased patch is attached.
pg_stat_statements in PG9.4dev has already changed table columns in. So I hope
this patch will be committed in PG9.4dev.
Regards,
--
Mitsumasa KONDO
NTT Open Source Software Center
*** a/contrib/pg_stat_statements/pg_stat_statements--1.1--1.2.sql
--- b/contrib/pg_sta
On Mon, Jan 20, 2014 at 06:49:21PM -0300, Alvaro Herrera wrote:
> Marko Kreen escribió:
> > http://www.viva64.com/en/b/0227/ reported that on-stack memset()s
> > might be optimized away by compilers. Fix it.
>
> Just to clarify, this needs to be applied to all branches, right? If
> so, does the
* Craig Ringer (cr...@2ndquadrant.com) 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 problem
On Mon, Jan 20, 2014 at 10:30 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 01/17/2014 08:49 PM, Alexander Korotkov wrote:
>
>> On Fri, Jan 17, 2014 at 10:38 PM, Heikki Linnakangas <
>> hlinnakan...@vmware.com> wrote:
>>
>> On 01/17/2014 01:05 PM, Alexander Korotkov wrote:
>>>
>>>
On Mon, Jan 20, 2014 at 2:12 PM, Amit Kapila wrote:
> On Sat, Jan 18, 2014 at 7:59 PM, Michael Paquier
> wrote:
>> Hi all,
>>
>> 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 aut
On Tue, Jan 21, 2014 at 4:28 PM, Alexander Korotkov wrote:
> I noticed that the gin vacuum redo routine is dead code, except for the
>> data-leaf page handling, because we never remove entries or internal nodes
>> (page deletion is a separate wal record type). And the data-leaf case is
>> function
From: "Amit Kapila"
How about below message:
event source "" is already registered.
Thanks. I'll use this, making the initial letter the capital "E" like other
messages in the same source file. I'm going to submit the final patch and
update the CommitFest entry tomorrow at the earliest.
Stephen Frost wrote:
> * Craig Ringer (cr...@2ndquadrant.com) 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 compr
On Fri, Jan 17, 2014 at 8:36 PM, Tom Lane wrote:
> I wrote:
>> Andres Freund writes:
>>> On 2014-01-17 13:50:08 -0500, Tom Lane wrote:
I think this approach is fundamentally broken, because it can't reasonably
cope with any case more complicated than "%zu" or "%zd".
>
>>> Am I just too
Jov wrote:
> attach patch add the per database set for alter user
Please add to the open CommitFest so that the patch doesn't "fall
through the cracks":
https://commitfest.postgresql.org/action/commitfest_view/open
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Co
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?
>
>Yes, I also think it leaks in both cases and similar l
On Sat, Jan 18, 2014 at 7:14 PM, Marti Raudsepp wrote:
> It looks like the get_object_address_attribute() function has a
> potential relcache leak. When missing_ok=true, the relation is found
> but attribute is not, then the relation isn't closed, nor is it
> returned to the caller.
>
> I couldn't
Robert Haas escribió:
> On Fri, Jan 17, 2014 at 8:36 PM, Tom Lane wrote:
> > I wrote:
> >> Andres Freund writes:
> >>> On 2014-01-17 13:50:08 -0500, Tom Lane wrote:
> >>> Am I just too tired, or am I not getting how INT64_FORMAT currently
> >>> allows the arguments to be used posititional?
> >
>
On 2014-01-21 12:11:23 -0300, Alvaro Herrera wrote:
> How difficult would it be to have expand_fmt_string deal with positional
> modifiers? I don't think we need anything from it other than the %n$
> notation, so perhaps it's not so problematic.
I don't think there's much reason to go there. I di
On Sun, Jan 19, 2014 at 2:43 PM, Marti Raudsepp wrote:
> On Tue, Nov 19, 2013 at 6:38 PM, Andres Freund wrote:
>> The attached patches compile and make check successfully on linux x86,
>> amd64 and msvc x86 and amd64. This time and updated configure is
>> included. The majority of operations stil
On 2014-01-21 10:20:35 -0500, Robert Haas wrote:
> On Sun, Jan 19, 2014 at 2:43 PM, Marti Raudsepp wrote:
> > On Tue, Nov 19, 2013 at 6:38 PM, Andres Freund
> > wrote:
> >> The attached patches compile and make check successfully on linux x86,
> >> amd64 and msvc x86 and amd64. This time and upd
On Mon, Jan 20, 2014 at 2:04 PM, Jov wrote:
> reasonable，I removed the "set",patch attached.
Hi Jov,
A new commitfest was just opened, due on 2014-06. Please add your patch here:
https://commitfest.postgresql.org/action/commitfest_view?id=22
(You'll need a community account if you don't already
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 ability to see it can be given to "public" on default
>> (thus
On 6 June 2013 16:00, Heikki Linnakangas wrote:
> In the "Redesigning checkpoint_segments" thread, many people opined that
> there should be a hard limit on the amount of disk space used for WAL:
> http://www.postgresql.org/message-id/CA+TgmoaOkgZb5YsmQeMg8ZVqWMtR=6s4-ppd+6jiy4oq78i...@mail.gmail.
On Tue, Jan 21, 2014 at 2:41 PM, Alvaro Herrera wrote:
> Stephen Frost wrote:
> > * Craig Ringer (cr...@2ndquadrant.com) 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*
* Magnus Hagander (mag...@hagander.net) wrote:
> Isn't CAP_BACKUP pretty much the REPLICATION privilege?
Not unless we change it to allow read-access to all tables to allow for
pg_dump to work...
Thanks,
Stephen
signature.asc
Description: Digital signature
On Sat, Jan 18, 2014 at 11:54 AM, Tom Lane wrote:
> Amit Kapila writes:
>> Is there any specific reason why adding PGDLLIMPORT for exporting
>> const variables is not good, when we are already doing for other variables
>> like InterruptHoldoffCount, CritSectionCount?
>
>> On searching in code, I
Craig Ringer wrote:
> (I intensely dislike the idea of ignoring accents, but it's something
> some people appear to need/want, and is supported by other vendors).
FWIW at least in spanish, users always want to search for entries
ignoring accents. Nowadays I think most turn to unaccent(), but bef
On Tue, Jan 21, 2014 at 5:18 PM, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
> > Isn't CAP_BACKUP pretty much the REPLICATION privilege?
>
> Not unless we change it to allow read-access to all tables to allow for
> pg_dump to work...
>
That sounds more like CAP_DUMP tha
On Fri, Jan 17, 2014 at 04:31:48PM +, Mel Gorman wrote:
> NUMA Optimisations
> --
>
> The primary one that showed up was zone_reclaim_mode. Enabling that parameter
> is a disaster for many workloads and apparently Postgres is one. It might
> be time to revisit leaving that thin
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 mechanism. Isn't it too complicated
> to
* Magnus Hagander (mag...@hagander.net) wrote:
> On Tue, Jan 21, 2014 at 5:18 PM, Stephen Frost wrote:
> > Not unless we change it to allow read-access to all tables to allow for
> > pg_dump to work...
>
> That sounds more like CAP_DUMP than CAP_BACKUP :)
Well, perhaps CAP_READONLY (or READALL?)
On Mon, Jan 20, 2014 at 4:31 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> With apologies to our beloved commitfest-mace-wielding CFM, commitfest
>> 2013-11 intentionally still contains a few open patches. I think that
>> CF is largely being ignored by most people now that we have CF 2014-01
>
Andres Freund writes:
> On 2014-01-21 12:11:23 -0300, Alvaro Herrera wrote:
>> How difficult would it be to have expand_fmt_string deal with positional
>> modifiers? I don't think we need anything from it other than the %n$
>> notation, so perhaps it's not so problematic.
> I don't think there's
09.01.2014 05:15, Peter Eisentraut kirjoitti:
pg_upgrade creates a script analyze_new_cluster.{sh|bat} that runs
vacuumdb --analyze-only in three stages with different statistics target
settings to get a fresh cluster analyzed faster. I think this behavior
is also useful for clusters or database
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 need to prevent WAL insertions when the disk fills. We
> still have
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 think that
>> AllowCascadeReplicatio
On Sun, Jan 19, 2014 at 1:41 AM, Pavel Stehule wrote:
> 2014/1/19 Marko Tiikkaja
>> On 1/19/14, 12:21 AM, Pavel Stehule wrote:
>>> I checked it and I got a small issue
>>>
>>> bash-4.1$ patch -p1 < cardinality.patch
>>> (Stripping trailing CRs from patch.)
>>>
>>> not sure about source of this pr
Hello
I disagree with it. There was no any request to move "ready for commit"
patches to next commitfest! I expected so only unfinishing patches should
by moved there by their authors. I sent question to Peter E. But without
reply, but Tom did commits from thist list, so I expected so there is som
On Mon, Jan 20, 2014 at 1:39 PM, Alvaro Herrera
wrote:
> * I haven't introduced settings to tweak this per table for
> autovacuum. I don't think those are needed. It's not hard to do,
> however; if people opine against this, I will implement that.
I can't think of any reason to believe that it
Dne 21.1.2014 18:52 "Pavel Stehule" napsal(a):
>
> Hello
>
> I disagree with it. There was no any request to move "ready for commit"
patches to next commitfest! I expected so only unfinishing patches should
by moved there by their authors. I sent question to Peter E. But without
reply, but Tom did
Hi,
When I shut down the standby server and then the master server in that order,
I found that the master server emit the following message.
LOG: XX000: could not remove shared memory segment
"/PostgreSQL.1804289383": Invalid argument
LOCATION: dsm_impl_posix, dsm_impl.c:269
Is this intentiona
This feature is interesting for Czech language too. Lot of applications
allows accent free searching due possible issues in original data or some
client limits - missing Czech keyboard and similar
Dne 21.1.2014 17:17 "Alvaro Herrera" napsal(a):
> Craig Ringer wrote:
>
> > (I intensely dislike the
On 1/21/14, 6:42 PM, Robert Haas wrote:
On Sun, Jan 19, 2014 at 1:41 AM, Pavel Stehule wrote:
It can be problem on my side - some strange combination of mime type. I seen
this issue before. I will recheck it tomorrow from other computer.
Doesn't matter anyway. Patch needing to strip trailing
Hi all,
I'm getting a report of a config error when changing a config value
that requires a restart:
In postgresql.conf
max_connections = 92
(pg_ctl restart)
postgres=# show max_connections ;
max_connections
-
92
(1 row)
(Edit postgresql.conf so that max_connections = 93)
Robert Haas writes:
> On Fri, Jan 17, 2014 at 8:36 PM, Tom Lane wrote:
>> It's still the case that we need a policy against INT64_FORMAT in
>> translatable strings, though, because what's passed to the gettext
>> mechanism has to be a fixed string not something with platform
>> dependencies in it
On Tue, Jan 21, 2014 at 1:05 PM, Fujii Masao wrote:
> When I shut down the standby server and then the master server in that order,
> I found that the master server emit the following message.
>
> LOG: XX000: could not remove shared memory segment
> "/PostgreSQL.1804289383": Invalid argument
> LO
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:
> received SIGHUP, reloading configuration files
> 2014-01-21 18:14:53 GMT [28718]: [5-1] user=,db=,client= LOG:
On 21 January 2014 18:35, 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 need to prevent W
On 01/21/2014 10:26 AM, Thom Brown wrote:
Hi all,
I'm getting a report of a config error when changing a config value
that requires a restart:
In postgresql.conf
max_connections = 92
(pg_ctl restart)
postgres=# show max_connections ;
max_connections
-
92
(1 row)
(Edit
The attached patch is in response to ongoing mailing-list questions
regarding perceived weirdness in to_timestamp and to_date.
The patch modifies doc/src/sgml/func.sgml to add "(see usage notes)" in
the description column for to_date and to_timestamp in the Formatting
Functions table and adds
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:
>> received SIGHUP, reloading configuration files
>> 2014-01-21
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
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
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 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
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 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
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 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 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
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!
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
>
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
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 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
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 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
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:
>>>
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
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
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
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.
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
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
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
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
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
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.
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
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
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
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 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
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]
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
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
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
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
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
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 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 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
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 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
1 - 100 of 157 matches
Mail list logo
