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
expression
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
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:
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
blah, blah
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
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 patch prevents
On 21 January 2014 01:09, KaiGai Kohei kai...@ak.jp.nec.com wrote:
(2014/01/13 22:53), Craig Ringer wrote:
On 01/09/2014 11:19 PM, Tom Lane wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
My first thought was that it should just preprocess any security
barrier quals in
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
On Sun, Dec 15, 2013 at 2:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
On 14 Dec 2013 15:40, Tom Lane t...@sss.pgh.pa.us 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
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
On Jan21, 2014, at 10:53 , David Rowley dgrowle...@gmail.com 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
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
---
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 version
* 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:
Seems to be fixed
On Mon, Jan 20, 2014 at 2:12 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Sat, Jan 18, 2014 at 7:59 PM, Michael Paquier
michael.paqu...@gmail.com 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
On Tue, Jan 21, 2014 at 4:28 PM, Alexander Korotkov aekorot...@gmail.comwrote:
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
From: Amit Kapila amit.kapil...@gmail.com
How about below message:
event source event_source_name 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
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
On Fri, Jan 17, 2014 at 8:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Andres Freund and...@2ndquadrant.com 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
Jov am...@amutu.com 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
On Fri, Jan 17, 2014 at 12:07 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Fri, Jan 17, 2014 at 12:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
PS: off topic, but isn't ParseConfigDirectory leaking the result
of AbsoluteConfigLocation? In both normal and error paths?
Yes, I also think
On Sat, Jan 18, 2014 at 7:14 PM, Marti Raudsepp ma...@juffo.org 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.
Robert Haas escribió:
On Fri, Jan 17, 2014 at 8:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Andres Freund and...@2ndquadrant.com 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
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
On Sun, Jan 19, 2014 at 2:43 PM, Marti Raudsepp ma...@juffo.org wrote:
On Tue, Nov 19, 2013 at 6:38 PM, Andres Freund and...@2ndquadrant.com 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.
On 2014-01-21 10:20:35 -0500, Robert Haas wrote:
On Sun, Jan 19, 2014 at 2:43 PM, Marti Raudsepp ma...@juffo.org wrote:
On Tue, Nov 19, 2013 at 6:38 PM, Andres Freund and...@2ndquadrant.com
wrote:
The attached patches compile and make check successfully on linux x86,
amd64 and msvc x86
On Mon, Jan 20, 2014 at 2:04 PM, Jov am...@amutu.com 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
Stephen Frost sfr...@snowman.net 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
On 6 June 2013 16:00, Heikki Linnakangas hlinnakan...@vmware.com 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:
On Tue, Jan 21, 2014 at 2:41 PM, Alvaro Herrera alvhe...@2ndquadrant.comwrote:
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
* 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 t...@sss.pgh.pa.us wrote:
Amit Kapila amit.kapil...@gmail.com 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,
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
On Tue, Jan 21, 2014 at 5:18 PM, Stephen Frost sfr...@snowman.net 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
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 thing
On Mon, Jan 20, 2014 at 11:23 PM, KaiGai Kohei kai...@ak.jp.nec.com 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
* Magnus Hagander (mag...@hagander.net) wrote:
On Tue, Jan 21, 2014 at 5:18 PM, Stephen Frost sfr...@snowman.net 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
On Mon, Jan 20, 2014 at 4:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
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
Simon Riggs si...@2ndquadrant.com writes:
On 6 June 2013 16:00, Heikki Linnakangas hlinnakan...@vmware.com 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
On Fri, Dec 20, 2013 at 9:21 PM, MauMau maumau...@gmail.com wrote:
From: Fujii Masao masao.fu...@gmail.com
! 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
On Sun, Jan 19, 2014 at 1:41 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2014/1/19 Marko Tiikkaja ma...@joh.to
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
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 some
On Mon, Jan 20, 2014 at 1:39 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
Dne 21.1.2014 18:52 Pavel Stehule pavel.steh...@gmail.com 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
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 intentional
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 alvhe...@2ndquadrant.com napsal(a):
Craig Ringer wrote:
(I
On 1/21/14, 6:42 PM, Robert Haas wrote:
On Sun, Jan 19, 2014 at 1:41 AM, Pavel Stehule pavel.steh...@gmail.com 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
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 robertmh...@gmail.com writes:
On Fri, Jan 17, 2014 at 8:36 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Jan 21, 2014 at 1:05 PM, Fujii Masao masao.fu...@gmail.com 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:
Thom Brown t...@linux.com 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]
On 21 January 2014 18:35, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 6 June 2013 16:00, Heikki Linnakangas hlinnakan...@vmware.com wrote:
The current situation is that if you run out of disk space while writing
WAL, you get a PANIC, and the server shuts
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 t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com 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
Albe Laurenz laurenz.a...@wien.gv.at 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
On Tue, Jan 21, 2014 at 2:00 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, Jan 20, 2014 at 9:49 PM, Robert Haas robertmh...@gmail.com 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
On Mon, Jan 20, 2014 at 9:44 PM, Shigeru Hanada
shigeru.han...@gmail.com wrote:
Thanks for the comments.
2014/1/21 KaiGai Kohei kai...@ak.jp.nec.com:
In addition, an idea which I can't throw away is to assume that all
constraints defined on foreign tables as ASSERTIVE. Foreign tables
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 just
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes:
- CURRENT_TIME and the like are parsed into the nodes directly
represents the node specs in gram.y
blah, blah
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.
On Tue, Jan 21, 2014 at 7:47 AM, Michael Paquier
michael.paqu...@gmail.com 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
On 21 January 2014 12:54, KONDO Mitsumasa kondo.mitsum...@lab.ntt.co.jp 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.
On Tue, Jan 21, 2014 at 12:30 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp 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
On Wed, Dec 18, 2013 at 12:21:08PM -0500, Robert Haas wrote:
On Tue, Dec 10, 2013 at 6:26 PM, Tom Lane t...@sss.pgh.pa.us 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
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 robertmh...@gmail.com 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
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 t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Jan 21, 2014 at 11:48 AM, Simon Riggs si...@2ndquadrant.com 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
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 though that we
On Tue, Jan 21, 2014 at 5:01 PM, Миша Тюрин tmih...@bk.ru 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
On Tue, Jan 21, 2014 at 1:59 PM, Thom Brown t...@linux.com wrote:
On 21 January 2014 18:35, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com 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]:
Robert Haas robertmh...@gmail.com 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
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
On Tue, Jan 21, 2014 at 3:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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-reviewing this tomorrow.
- Heikki
gin-packed-postinglists-20140121.patch.gz
Description
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 with
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp 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
On 01/21/2014 07:31 PM, Fujii Masao wrote:
On Fri, Dec 20, 2013 at 9:21 PM, MauMau maumau...@gmail.com wrote:
From: Fujii Masao masao.fu...@gmail.com
! if (source == XLOG_FROM_ARCHIVE StandbyModeRequested)
Even when standby_mode is not enabled, we can use cascade replication and
it
Greg Stark st...@mit.edu 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
Robert Haas robertmh...@gmail.com 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
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 know if
On Tue, Jan 21, 2014 at 9:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 6 June 2013 16:00, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
The current situation is that if you run out of disk space while writing
WAL, you get a PANIC, and the
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
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
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
On 01/21/2014 12:29 PM, Robert Haas wrote:
On Tue, Jan 21, 2014 at 1:59 PM, Thom Brown t...@linux.com wrote:
On 21 January 2014 18:35, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com writes:
I'm getting a report of a config error when changing a config value
that requires a
On 2014-01-21 16:13:11 -0500, Robert Haas wrote:
On Tue, Jan 21, 2014 at 3:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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 from
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
Jeff Janes jeff.ja...@gmail.com writes:
On Tue, Jan 21, 2014 at 9:35 AM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Jan 21, 2014 at 3:24 PM, Tom Lane t...@sss.pgh.pa.us 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
On 2014-01-21 18:24:39 -0500, Tom Lane wrote:
Jeff Janes jeff.ja...@gmail.com writes:
On Tue, Jan 21, 2014 at 9:35 AM, Tom Lane t...@sss.pgh.pa.us 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
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
On Tue, Jan 21, 2014 at 12:31 AM, Craig Ringer cr...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
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 enough
1 - 100 of 157 matches
Mail list logo
