Hi all,
Coverity has pointed out that vacuumlo.c is leaking memory when
grabbing the list of candidate table names and schemas. Attached is a
patch to fix the leak.
Regards,
--
Michael
*** a/contrib/vacuumlo/vacuumlo.c
--- b/contrib/vacuumlo/vacuumlo.c
***
*** 240,245 vacuumlo(co
On Tue, Jan 13, 2015 at 4:34 PM, Michael Paquier
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
***
*** 1338,1344 hsto
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 hstore_to_jsonb(PG
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 "_
Michael Paquier 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. "_unsafe" would be nearer
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
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!
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 t
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 wrote:
> > > * Robert Haas (robertmh...@gmail.com) wrote:
On 12/3/14 1:08 PM, Tom Lane wrote:
Heikki Linnakangas 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 infrastructure that would let us
Dean, Robert,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 29 October 2014 13:04, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Wed, Oct 29, 2014 at 8:16 AM, Stephen Frost wrote:
> >> > suggestions. If the user does not have table-level SELECT rights,
>
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 the
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, mos
Dne 12.1.2015 22:26 "Tom Lane" napsal(a):
>
> Alvaro Herrera 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 ob
On 1/10/15 12:06 AM, Amit Kapila wrote:
On Sat, Jan 10, 2015 at 6:20 AM, Jim Nasby 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 couldn't
remember and ha
Alvaro Herrera 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 did what I prop
* 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 ba
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 wo
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 i
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 NOTE
On Thu, Jan 8, 2015 at 6:52 AM, Amit Kapila 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
EnterpriseDB: http://www.e
On Wed, Jan 7, 2015 at 3:54 PM, Jim Nasby 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 cooperating backends would ne
On 12 January 2015 at 14:24, Stephen Frost 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
> discussing it with Craig
Jeff Janes wrote:
> On Fri, Jan 2, 2015 at 9:59 PM, Jeff Janes 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 similar missed
call
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_UNLO
On 2015-01-12 12:49:53 -0500, Tom Lane wrote:
> Andres Freund 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 supp
On 2015-01-12 12:44:56 -0500, Robert Haas wrote:
> On Mon, Jan 12, 2015 at 11:27 AM, Andres Freund
> wrote:
> > On 2015-01-12 11:03:42 -0500, Tom Lane wrote:
> >> Andres Freund writes:
> >> > While it might not be required for existing latch uses (I'm *not* sure
> >> > that's true)
> >
> > I thi
Andres Freund 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? If we decide we
On Mon, Jan 12, 2015 at 11:27 AM, Andres Freund wrote:
> On 2015-01-12 11:03:42 -0500, Tom Lane wrote:
>> Andres Freund 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()
On 2015-01-12 11:03:42 -0500, Tom Lane wrote:
> Andres Freund 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 necessary barriers (via
Andres Freund 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.
> Agreed?
Yeah, now tha
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 orderin
Dmitry Voronin writes:
> 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_msg />set_errcontext_domainerrmsgerrfinish
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 10 January 2015 at 21:38, Dean Rasheed 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_secu
On Fri, Jan 2, 2015 at 3:27 PM, Heikki Linnakangas
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. First of all, m
On 10 January 2015 at 21:38, Dean Rasheed 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
> initialised to false at the
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 error
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
On 1/11/15 3:57 PM, Robert Haas wrote:
On Sun, Jan 11, 2015 at 5:27 AM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, Jan 8, 2015 at 2:46 PM, Stephen Frost wrote:
Yeah, if we come up with a plan for X workers and end up not being able
to spawn that many then I cou
39 matches
Mail list logo
