btw, there is serious problem with row-level security and constraints. For
example, user with low security level could use unique constraint to know
about existence of a row with higher security. I don't know, what is the
best practice to avoid this.
On Wed, Aug 28, 2013 at 1:37 AM, Greg Smith
Peter Eisentraut pete...@gmx.net writes:
make -C pg_upgrade_support all
Do we have something automated to easily test pg_upgrade?
My memories of how pg_upgrade works with extensions makes me believe
that I don't have anything special to do when those extensions have been
made available through
2013/8/28 Oleg Bartunov obartu...@gmail.com:
btw, there is serious problem with row-level security and constraints. For
example, user with low security level could use unique constraint to know
about existence of a row with higher security. I don't know, what is the
best practice to avoid
On 2013-08-28 13:58:08 +0900, Michael Paquier wrote:
On Tue, Aug 27, 2013 at 11:09 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-08-27 15:34:22 +0900, Michael Paquier wrote:
I have been working a little bit more on this patch for the next
commit fest. Compared to the previous
On 2013-08-27 23:46:23 -0400, Noah Misch wrote:
On Tue, Aug 27, 2013 at 04:14:27PM +0200, Andres Freund wrote:
On 2013-06-09 17:25:59 -0400, Noah Misch wrote:
***
*** 846,851 exec_simple_query(const char *query_string)
--- 847,856
Darren Duncan dar...@darrenduncan.net writes:
That's a really old post/thread, and I'm not arguing for any kind of action
related to RULEs, please disregard the message. -- Darren Duncan
Oh, my fault --- for some reason my mail reader popped it up as an unread
message, and I failed to notice
On Tue, Aug 27, 2013 at 4:51 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Sun, Aug 25, 2013 at 3:21 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Sat, Aug 24, 2013 at 2:46 PM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Sat, Aug 24, 2013 at 3:14 AM, Josh Berkus
Tom Lane wrote:
What exactly is the argument for pushing this into 9.3? Since we
are past rc1, we should treat that branch as released. If you wouldn't
back-patch into all supported branches, you shouldn't be patching 9.3
either.
This is to fix the stats_temp_directory issue that the
I'm currently implementing commit sequence number (CSN) based
snapshots and I hit a design decision that I would like to resolve
before I have too much code to rewrite.
The issue is commit visibility ordering on slaves. As a couple of
threads on hackers have already noted, currently commit order
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
What exactly is the argument for pushing this into 9.3? Since we
are past rc1, we should treat that branch as released. If you wouldn't
back-patch into all supported branches, you shouldn't be patching 9.3
either.
This is to
Dimitri Fontaine wrote:
Peter Eisentraut pete...@gmx.net writes:
make -C pg_upgrade_support all
Do we have something automated to easily test pg_upgrade?
make check in contrib/pg_upgrade should do the trick.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL
Alvaro Herrera alvhe...@2ndquadrant.com writes:
make check in contrib/pg_upgrade should do the trick.
PASSED
Even after I added extension to the serial_schedule. I don't know if I
need to do anything specific on that area, will wait about some feedback
on that before sending a new version of
On 21.05.2013 00:20, Heikki Linnakangas wrote:
On 16.05.2013 01:08, Daniel Farina wrote:
On Mon, May 13, 2013 at 5:50 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
pgbench -S is such a workload. With 9.3beta1, I'm seeing this
profile, when
I run pgbench -S -c64 -j64 -T60 -M prepared on
On Tue, Aug 27, 2013 at 09:04:00AM +0530, Amit Kapila wrote:
For my part, I'd honestly rather have the first things found be what's
picked and later things be ignored. If you want it controlled by ALTER
SYSTEM, then don't set it in postgresql.conf. The problem with that is
there's no
Heikki Linnakangas hlinnakan...@vmware.com writes:
So, my plan is to apply the attached non-locked-tas-spin-x86_64.patch to
master. But I would love to get feedback from people running different
x86_64 hardware.
Surely this patch should update the existing comment at line 209? Or at
least
On Mon, Aug 26, 2013 at 4:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 19, 2013 at 1:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, I notice that the MVCC-catalog-scans patch summarily asserts that
RenumberEnumType no longer poses any
On Sun, Aug 25, 2013 at 10:11:50PM -0400, Tom Lane wrote:
Michael Paquier michael.paqu...@gmail.com writes:
On Thu, Aug 22, 2013 at 11:55 PM, Blake Smith blakesmi...@gmail.com wrote:
The combined entry is used to support contains (@) queries, and the key
only item is used to support key
On 2013-08-28 13:31:22 -0400, Bruce Momjian wrote:
On Sun, Aug 25, 2013 at 10:11:50PM -0400, Tom Lane wrote:
Michael Paquier michael.paqu...@gmail.com writes:
On Thu, Aug 22, 2013 at 11:55 PM, Blake Smith blakesmi...@gmail.com
wrote:
The combined entry is used to support contains (@)
On Tue, Aug 27, 2013 at 9:50 AM, Andres Freund and...@2ndquadrant.com wrote:
BgwHandleStatus GetBackgroundWorkerPid(BackgroundWorkerHandle *handle,
pid_t *pid);
BgwHandleStatus WaitForBackgroundWorkerStartup(BackgroundWorkerHandle
*handle, pid_t *pid);
OK, here's a patch that API. I
On Wed, Aug 28, 2013 at 2:04 PM, Robert Haas robertmh...@gmail.com wrote:
I certainly can't promise that the code is bug-free. But I think it's
probably better to get this into the tree and let people start playing
around with it than to continue to maintain it in my private sandbox.
At this
On Wed, Aug 28, 2013 at 2:04 PM, Robert Haas robertmh...@gmail.com wrote:
Hm. Not this patches fault, but We seem to allow bgw_start_time ==
BgWorkerStart_PostmasterStart here which doesn't make sense...
I can add a check for that. I agree that it's a separate patch.
On third thought, is
* Bruce Momjian (br...@momjian.us) wrote:
On Tue, Aug 27, 2013 at 09:04:00AM +0530, Amit Kapila wrote:
I really hate the idea that someone could configure 'X' in
postgresql.conf and because the auto.conf line is later in the file,
it's able to override the original setting. Does not
Stephen Frost sfr...@snowman.net writes:
While I appreciate that there are bootstrap-type issues with this, I
really don't like this idea of later stuff can just override earlier
stuff.
include files and conf.d-style options are for breaking the config up,
not to allow you to override
On 2013-08-28 14:04:59 -0400, Robert Haas wrote:
+ functionRegisterDynamicBackgroundWorker(typeBackgroundWorker
+ *worker, BackgroundWorkerHandle **handle/type)/function. Unlike
+ functionRegisterBackgroundWorker/, which can only be called from
within
+ the postmaster,
Tom,
Does the backend's memory usage climb, or hold steady? If the former,
I'd bet on client failure to release resources, eg not closing the
portals when done with them. A memory map from MemoryContextStats
would help determine exactly what's leaking.
FS cache usage increases through the
On Wed, Aug 28, 2013 at 02:30:41PM -0400, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
On Tue, Aug 27, 2013 at 09:04:00AM +0530, Amit Kapila wrote:
I really hate the idea that someone could configure 'X' in
postgresql.conf and because the auto.conf line is later in the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
While I appreciate that there are bootstrap-type issues with this, I
really don't like this idea of later stuff can just override earlier
stuff.
include files and conf.d-style options are for breaking the
* Bruce Momjian (br...@momjian.us) wrote:
Agreed, but I think this is a much larger issue than ALTER SYSTEM SET.
Yeah, true.
I think changing behavior to first-seen would only add to confusion.
What we really need is a WARNING when a later postgresql.conf setting
overrides an earlier one,
On Tue, Aug 27, 2013 at 10:07 AM, Andres Freund and...@2ndquadrant.com wrote:
[just sending an email which sat in my outbox for two weeks]
Thanks for taking a look.
Nice to see this coming. I think it will actually be interesting for
quite some things outside parallel query, but we'll see.
On Wed, Aug 28, 2013 at 03:15:14PM -0400, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
Agreed, but I think this is a much larger issue than ALTER SYSTEM SET.
Yeah, true.
I think changing behavior to first-seen would only add to confusion.
What we really need is a
Stephen Frost escribió:
There are counter-examples also; sysctl.d will replace what's already
been set, so perhaps it simply depends on an individual's experience.
For my part, I'd much prefer an error or warning saying you've got
duplicate definitions of X than a last-wins approach, though
On Tue, Aug 27, 2013 at 6:10 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
what is magical?
Stored procedures - we talk about this technology was a originally simple
script moved from client side to server side.
so if I write on client side
BEGIN;
SELECT 1,2;
SELECT 2;
SELECT
On Wed, Aug 28, 2013 at 2:59 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 27, 2013 at 6:10 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
what is magical?
Stored procedures - we talk about this technology was a originally simple
script moved from client side to server side.
On 08/28/2013 09:59 PM, Robert Haas wrote:
On Tue, Aug 27, 2013 at 6:10 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
what is magical?
Stored procedures - we talk about this technology was a originally simple
script moved from client side to server side.
so if I write on client side
On Wed, Aug 28, 2013 at 1:40 AM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
I would be good, if this set gets documented, lest users will be confused.
Can you point me to relevant sections of document? I can add this
documentation.
I think it's your job to look at the documentation
On Wed, Aug 28, 2013 at 03:16:14PM +0200, Andres Freund wrote:
On 2013-08-27 23:46:23 -0400, Noah Misch wrote:
On Tue, Aug 27, 2013 at 04:14:27PM +0200, Andres Freund wrote:
On 2013-06-09 17:25:59 -0400, Noah Misch wrote:
***
*** 846,851 exec_simple_query(const char
Hello,
int, float, double 26829 ms (26675 ms) -- 0.5% slower .. statistic error ..
cleaner code
numeric sum 6490 ms (7224 ms) -- 10% faster
numeric avg 6487 ms (12023 ms) -- 46% faster
I also got very similar results.
On the other hand, initially I was receiving sigsegv's whenever I
wanted
2013/8/29 Hadi Moshayedi h...@moshayedi.net
Hello,
int, float, double 26829 ms (26675 ms) -- 0.5% slower .. statistic error
..
cleaner code
numeric sum 6490 ms (7224 ms) -- 10% faster
numeric avg 6487 ms (12023 ms) -- 46% faster
I also got very similar results.
On the other hand,
38 matches
Mail list logo
