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
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 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
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
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 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
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)
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
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
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
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
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
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
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 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
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
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
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
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
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
>
* 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 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
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 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
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 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
* 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 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*
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.
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 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
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 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 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
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 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
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
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 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
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
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.
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
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 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:
>>>
>>>
* 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 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
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 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
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 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
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 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: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
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
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
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
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
101 - 157 of 157 matches
Mail list logo
