On 1/11/15 3:57 PM, Robert Haas wrote:
On Sun, Jan 11, 2015 at 5:27 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Jan 8, 2015 at 2:46 PM, Stephen Frost sfr...@snowman.net wrote:
Yeah, if we come up with a plan for X workers and end up not
On Fri, Jan 9, 2015 at 2:00 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Hello, thank you for the comment.
This is the second version of the patch.
- Refactored to make the code simpler and clearer.
- Added comment about logic outline and struct members.
- Removed trailig
Hello, postgresmen! I found incorrect execution of ereport() macro. If we pass into ereport() function 2 or more arguments, the macro errcontext does not correct execute. So, ereport() call stack is: errstarterrcontext_msgset_errcontext_domainerrmsgerrfinishpg_unreachable This bug causes that
On Fri, Jan 2, 2015 at 3:27 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 01/01/2015 03:24 AM, Josh Berkus wrote:
Please remind me because I'm having trouble finding this in the
archives: how does wal_keep_segments interact with the new settings?
It's not very straightforward.
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 10 January 2015 at 21:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
OK, I'll take a look at it. I started reading the existing code that
expands RLS policies and spotted a couple of bugs that should be fixed
first:-
1). In
Dmitry Voronin carriingfat...@yandex.ru writes:
divdivdivdiv data-lang=2divHello,
postgresmen!/divdiv/divdivI found incorrect execution of ereport()
macro. br /If we pass into ereport() function 2 or more arguments, the
macro errcontext does not correct execute. So, ereport() call stack
On 10 January 2015 at 21:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
OK, I'll take a look at it. I started reading the existing code that
expands RLS policies and spotted a couple of bugs that should be fixed
first:-
1). In prepend_row_security_policies(), defaultDeny should be
On 2015-01-12 11:03:42 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
While it might not be required for existing latch uses (I'm *not* sure
that's true)
I think at least syncrep.c might not be correct. In SyncRepWakeQueue()
it sets PGPROC-syncRepState without the
Hi,
latch.h has the following comment:
* Presently, when using a shared latch for interprocess signalling, the
* flag variable(s) set by senders and inspected by the wait loop must
* be protected by spinlocks or LWLocks, else it is possible to miss events
* on machines with weak memory
On Wed, Jan 7, 2015 at 3:54 PM, Jim Nasby jim.na...@bluetreble.com wrote:
Agreed, I was more concerned with calls to nextval(), which don't seem to be
prevented in parallel mode?
It looks prevented:
/*
* Forbid this during parallel operation because, to make it work,
* the
On Thu, Jan 8, 2015 at 6:52 AM, Amit Kapila amit.kapil...@gmail.com wrote:
+ seg = dsm_attach(DatumGetInt32(main_arg));
Here, I think DatumGetUInt32() needs to be used instead of
DatumGetInt32() as the segment handle is uint32.
OK, I'll change that in the next version.
--
Robert Haas
On 12 January 2015 at 14:24, Stephen Frost sfr...@snowman.net wrote:
Looking at the regression tests a bit though, I notice that this removes
the lower-level LockRows.. There had been much discussion about that
last spring which I believe you were a part of..? I specifically recall
Jeff Janes wrote:
I'd like to propose a wiki to-do item for a backslash command in psql which
would show all installable extensions, basically just a wrapper around
'select * from pg_available_extensions'.
I've wanted it a few times recently, mostly in testing.
+1.
Any reason this
A reminder, only about a week to submit your proposal:
http://www.pgcon.org/2015/papers.php
PGCon 2015 will be on 18-19 June 2015 at University of Ottawa.
* 16-17 (Tue-Wed) tutorials
* 18-19 (Thu-Fri) talks - the main part of the conference
* 20 (Sat) The Unconference (very popular)
PLEASE
I'd like to propose a wiki to-do item for a backslash command in psql which
would show all installable extensions, basically just a wrapper around
'select * from pg_available_extensions'.
I've wanted it a few times recently, mostly in testing.
Any reason this wouldn't be desirable? What should
* Jeff Janes (jeff.ja...@gmail.com) wrote:
I'd like to propose a wiki to-do item for a backslash command in psql which
would show all installable extensions, basically just a wrapper around
'select * from pg_available_extensions'.
I guess I don't feel very strongly for or against adding a
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Jeff Janes wrote:
I thought of \dx+, but the + is already used to show the objects
associated with the extensions. (Althought it seems like it would
more in keeping with other usage if \dx+ only listed the objects if it
was given a pattern, and
Dne 12.1.2015 22:26 Tom Lane t...@sss.pgh.pa.us napsal(a):
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Jeff Janes wrote:
I thought of \dx+, but the + is already used to show the objects
associated with the extensions. (Althought it seems like it would
more in keeping with other
On 1/10/15 12:06 AM, Amit Kapila wrote:
On Sat, Jan 10, 2015 at 6:20 AM, Jim Nasby jim.na...@bluetreble.com
mailto:jim.na...@bluetreble.com wrote:
I'm surprised to see that the docs make no mention of how max_connections,
max_worker_processes and autovacuum_max_workers (don't) relate. I
On Mon, Jan 12, 2015 at 01:05:16PM -0800, Jeff Janes wrote:
I'd like to propose a wiki to-do item for a backslash command in psql which
would show all installable extensions, basically just a wrapper around
'select * from pg_available_extensions'.
I've wanted it a few times recently, mostly
On 1/11/15 8:52 AM, Ravi Kiran wrote:
Hi,
I want to know what kind of hash function postgres is using currently, can
someone please explain the algorithm postgres is using for the hash function in
the hash join algorithm.
That's ultimately going to be determined by the operator family of
Dean, Robert,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 29 October 2014 13:04, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Oct 29, 2014 at 8:16 AM, Stephen Frost sfr...@snowman.net wrote:
suggestions. If the user does not have
On 12/3/14 1:08 PM, Tom Lane wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
Do you need to plan for every combination, where some joins are removed
and some are not?
I would vote for just having two plans and one switch node. To exploit
any finer grain, we'd have to have
All,
Apologies, forgot to mention- this is again 9.4.
Thanks,
Stephen
* Stephen Frost (sfr...@snowman.net) wrote:
Dean, Robert,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 29 October 2014 13:04, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas
Michael Paquier michael.paqu...@gmail.com writes:
Attached is a patch adding the following set of functions for frontend
and backends returning NULL instead of reporting ERROR when allocation
fails:
- palloc_safe
- palloc0_safe
- repalloc_safe
Unimpressed with this naming convention.
On 2015/01/10 1:08, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
I ran into a comment type. Please find attached a patch.
Fix pushed.
Thanks!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Hi all,
For the last couple of weeks it has been mentioned a couple of times
that it would be useful to have a set of palloc APIs able to return
NULL on OOM to allow certain code paths to not ERROR and to take
another route when memory is under pressure. This has been for example
mentioned on the
Hi all,
Coverity pointed out that hstore_to_jsonb in hstore_io.c does not use
a couple of return values from pushJsonbValue.
Attached is a patch to fix that.
Regards,
--
Michael
*** a/contrib/hstore/hstore_io.c
--- b/contrib/hstore/hstore_io.c
***
*** 1338,1344
Michael Paquier wrote
Attached is a patch adding the following set of functions for frontend
and backends returning NULL instead of reporting ERROR when allocation
fails:
- palloc_safe
- palloc0_safe
- repalloc_safe
The only thing I can contribute is paint...I'm not fond of the word _safe
Hi!
Last I said something about the new CF app I said I was planning to deploy
it over the holidays, and that clearly did not happen.
But I've been talking to Michael, as the current cf-chief, and doing some
further testing with it, and we think now is a good time to go for it :) As
the plan is
On Tue, Jan 13, 2015 at 4:34 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Attached is a patch to fix that.
Oh, actually that's as well the case of hstore_to_jsonb_loose. Updated
patch is attached.
--
Michael
*** a/contrib/hstore/hstore_io.c
--- b/contrib/hstore/hstore_io.c
Andres Freund and...@2ndquadrant.com writes:
While it might not be required for existing latch uses (I'm *not* sure
that's true), I still think that we should fix those XXX by actually
using barriers now that we have them. I don't think we want every
callsite worry about using barriers.
On Mon, Jan 12, 2015 at 11:27 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-01-12 11:03:42 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
While it might not be required for existing latch uses (I'm *not* sure
that's true)
I think at least syncrep.c might not
Andres Freund and...@2ndquadrant.com writes:
On 2015-01-12 11:03:42 -0500, Tom Lane wrote:
Yeah, now that we have barrier code we think works, we should definitely
put some in there. The only reason it's like that is we didn't have
any real barrier support at the time.
Master only though?
On 2015-01-12 12:44:56 -0500, Robert Haas wrote:
On Mon, Jan 12, 2015 at 11:27 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2015-01-12 11:03:42 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
While it might not be required for existing latch uses (I'm *not* sure
On 2015-01-12 12:49:53 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2015-01-12 11:03:42 -0500, Tom Lane wrote:
Yeah, now that we have barrier code we think works, we should definitely
put some in there. The only reason it's like that is we didn't have
any real
On 2015-01-10 23:03:36 +0100, Andres Freund wrote:
On 2015-01-10 16:09:42 -0500, Tom Lane wrote:
I've not tried to build HEAD on my HPPA dinosaur for awhile, but I did
just now, and I am presented with boatloads of this:
../../../src/include/storage/s_lock.h:759: warning: `S_UNLOCK'
Jeff Janes wrote:
On Fri, Jan 2, 2015 at 9:59 PM, Jeff Janes jeff.ja...@gmail.com wrote:
This commit 3f88672a4e4d8e648d24ccc65 seems to have broken pg_upgrade for
pg_trgm.
It seems I failed to notice the get_object_address in the ALTER
EXTENSION path. Should be fixed now. I looked for
38 matches
Mail list logo
