On 09/04/2013 11:22 PM, Tom Lane wrote:
> AFAICT, to deal with update/delete the RLS patch needs to constrain order
> of qual application without the crutch of having a separate level of
> subquery; and it's that behavior that I have zero confidence in, either
> as to whether it works as submitted
On 01.11.2013 18:22, Noah Misch wrote:
On Fri, Nov 01, 2013 at 12:27:31AM -0400, Robert Haas wrote:
On Thu, Oct 31, 2013 at 7:48 PM, Heikki Linnakangas
wrote:
On 31.10.2013 16:43, Robert Haas wrote:
There should be no cases where the main shared memory
segment gets cleaned up and the dynamic
The current code just reads:
/*
* For now, we also don't support security-barrier views, because of the
* difficulty of keeping upper-level qual expressions away from
* lower-level data. This might get relaxed in future.
*/
if (RelationIsSecurityView(view))
return gettext_noop("Securi
On 01.11.2013 11:42, Mika Eloranta wrote:
pg_receivexlog calculated the xlog segment number incorrectly
when started after the previous instance was interrupted.
Resuming streaming only worked when the physical wal segment
counter was zero, i.e. for the first 256 segments or so.
Oops. Fixed, t
On 2013-11-04 09:38:27 +0200, Heikki Linnakangas wrote:
> On 29.10.2013 03:16, Andres Freund wrote:
> >Hi,
> >
> >I've started a valgrind run earlier when trying to run the regression
> >tests with valgrind --error-exitcode=122 (to cause the regression tests
> >to fail visibly) but it crashed frequ
On 2013-11-02 17:05:24 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
>
> > the matview patch (0002)
>
> This is definitely needed as a bug fix. Will adjust comments and
> commit, back-patched to 9.3.
Thanks.
> > Also attached is 0004 which just adds a heap_lock() around a
> > newly crea
On 2013-11-01 15:28:54 -0400, Tom Lane wrote:
> Andres Freund writes:
> > While not particularly nice, given the API, it seems best for buffile.c
> > to remember the resource owner used for the original segment and
> > temporarily set that during the extension.
>
> Hm, yeah, that seems right. It
On 2013-11-04 10:27:47 +0200, Heikki Linnakangas wrote:
> On 01.11.2013 18:22, Noah Misch wrote:
> >On Fri, Nov 01, 2013 at 12:27:31AM -0400, Robert Haas wrote:
> >>On Thu, Oct 31, 2013 at 7:48 PM, Heikki Linnakangas
> >> wrote:
> >>>On 31.10.2013 16:43, Robert Haas wrote:
> There should be no
On 2013-11-02 15:29:36 -0400, Tom Lane wrote:
> Attached is a proposed patch for this. It fixes most of the functions
> in printtup.c to use a per-row memory context. (I did not bother to
> fix debugtup(), which is used only in standalone mode. If you're doing
> queries large enough for mem leak
> Please find attached a patch doing what is written in the $subject.
With the documentation updated, this is even better...
Regards,
--
Michael
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index ccb76d8..0f20253 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sg
On 04.11.2013 11:55, Andres Freund wrote:
On 2013-11-04 10:27:47 +0200, Heikki Linnakangas wrote:
Hmm, here's another idea:
Postmaster creates the POSIX shared memory object at startup, by calling
shm_open(), and immediately calls shm_unlink on it. That way, once all the
processes have exited,
On 2013-11-04 13:13:27 +0200, Heikki Linnakangas wrote:
> On 04.11.2013 11:55, Andres Freund wrote:
> >On 2013-11-04 10:27:47 +0200, Heikki Linnakangas wrote:
> >>Postmaster creates the POSIX shared memory object at startup, by calling
> >>shm_open(), and immediately calls shm_unlink on it. That wa
On Nov 4, 2013, at 11:06, Heikki Linnakangas wrote:
> On 01.11.2013 11:42, Mika Eloranta wrote:
>> pg_receivexlog calculated the xlog segment number incorrectly
>> when started after the previous instance was interrupted.
>>
>> Resuming streaming only worked when the physical wal segment
>> counte
On 04.11.2013 11:35, Andres Freund wrote:
On 2013-11-04 09:38:27 +0200, Heikki Linnakangas wrote:
Secondly, it will fail if you create
two fake relcache entries for the same relfilenode. Freeing the first will
close the smgr entry, and freeing the second will try to close the same smgr
entry aga
On 2013-11-04 14:37:53 +0200, Heikki Linnakangas wrote:
> On 04.11.2013 11:35, Andres Freund wrote:
> >On 2013-11-04 09:38:27 +0200, Heikki Linnakangas wrote:
> >>diff --git a/src/backend/access/transam/xlogutils.c
> >>b/src/backend/access/transam/xlogutils.c
> >>index 5429d5e..f732e71 100644
> >>
On 2013-11-04 13:48:32 +0100, Andres Freund wrote:
> > Hmm, the startup process doesn't participate in sinval messaging at all,
> > does it?
>
> Well, not sinval but inval, in hot standby via commit messages.
Err, that's bullshit, sorry for that. We send the messages via sinval,
but never (probab
Dimitri,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> So please find v15 of the patch attached to this email, that passes all
> previously done checks and this one too now.
Looks like there's been a bit of unfortunate bitrot due to Tom's change
to disable fancy output:
patching file src/
On Fri, Nov 1, 2013 at 3:52 AM, Craig Ringer wrote:
> I've been looking some more into write-side checks in row-security and
> have a suggestion.
>
> Even though write-side checks are actually fairly separate to read
> checks, and can be done as another step, I'd like to think about them
> before
On Mon, Nov 4, 2013 at 5:57 AM, Michael Paquier
wrote:
>> Please find attached a patch doing what is written in the $subject.
> With the documentation updated, this is even better...
I'm unconvinced that there's any value in this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Ent
Craig Ringer writes:
> On 09/04/2013 11:22 PM, Tom Lane wrote:
>> AFAICT, to deal with update/delete the RLS patch needs to constrain order
>> of qual application without the crutch of having a separate level of
>> subquery; and it's that behavior that I have zero confidence in, either
>> as to wh
Andres Freund writes:
> On 2013-11-02 15:29:36 -0400, Tom Lane wrote:
>> Attached is a proposed patch for this. It fixes most of the functions
>> in printtup.c to use a per-row memory context. (I did not bother to
>> fix debugtup(), which is used only in standalone mode. If you're doing
>> quer
On 2013-11-04 09:45:22 -0500, Tom Lane wrote:
> Really I'd like to see standalone mode, in its current form, go away
> completely. I had a prototype patch for allowing psql and other clients
> to interface to a standalone backend. I think getting that finished would
> be a way more productive use
Andres Freund writes:
> On 2013-11-04 13:13:27 +0200, Heikki Linnakangas wrote:
>> On 04.11.2013 11:55, Andres Freund wrote:
>>> Also, I don't think it's portable across platforms to access segments
>>> that already have been unlinked.
>> See
>> http://pubs.opengroup.org/onlinepubs/009695299/func
On Mon, Nov 4, 2013 at 9:37 AM, Tom Lane wrote:
> Craig Ringer writes:
>> On 09/04/2013 11:22 PM, Tom Lane wrote:
>>> AFAICT, to deal with update/delete the RLS patch needs to constrain order
>>> of qual application without the crutch of having a separate level of
>>> subquery; and it's that beha
On Mon, Nov 4, 2013 at 8:15 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2013-11-02 15:29:36 -0400, Tom Lane wrote:
>>> Attached is a proposed patch for this. It fixes most of the functions
>>> in printtup.c to use a per-row memory context. (I did not bother to
>>> fix debugtup(), which is
On Fri, Nov 1, 2013 at 11:45 PM, Peter Eisentraut wrote:
> On Mon, 2013-10-28 at 12:17 -0400, Robert Haas wrote:
>> On Sun, Oct 27, 2013 at 11:34 PM, Noah Misch wrote:
>> > On Fri, Oct 25, 2013 at 10:11:41PM -0400, Robert Haas wrote:
>> >> When I wrote the dynamic shared memory patch, I used uint
On 11/4/13, 8:58 AM, Robert Haas wrote:
> On Mon, Nov 4, 2013 at 5:57 AM, Michael Paquier
> wrote:
>>> Please find attached a patch doing what is written in the $subject.
>> With the documentation updated, this is even better...
>
> I'm unconvinced that there's any value in this.
Yeah, the only
On 2013-11-04 10:46:06 -0500, Robert Haas wrote:
> On Fri, Nov 1, 2013 at 11:45 PM, Peter Eisentraut wrote:
> > On Mon, 2013-10-28 at 12:17 -0400, Robert Haas wrote:
> >> On Sun, Oct 27, 2013 at 11:34 PM, Noah Misch wrote:
> >> > On Fri, Oct 25, 2013 at 10:11:41PM -0400, Robert Haas wrote:
> >> >
On Sat, Nov 2, 2013 at 6:07 AM, Simon Riggs wrote:
> On 29 October 2013 16:10, Peter Geoghegan wrote:
>> On Tue, Oct 29, 2013 at 7:53 AM, Leonardo Francalanci
>> wrote:
>>> I don't see much interest in insert-efficient indexes.
>>
>> Presumably someone will get around to implementing a btree in
On Mon, Nov 4, 2013 at 10:55 AM, Andres Freund wrote:
>> Ah. This is because I didn't change the format code used to print the
>> arguments; it's still using UINT64_FORMAT, but the argument is now a
>> Size. What's the right way to print out a Size, anyway?
>
> There isn't a nice one currently.
On Mon, Nov 4, 2013 at 1:09 PM, Robert Haas wrote:
> On Sat, Nov 2, 2013 at 6:07 AM, Simon Riggs wrote:
>> On 29 October 2013 16:10, Peter Geoghegan wrote:
>>> On Tue, Oct 29, 2013 at 7:53 AM, Leonardo Francalanci
>>> wrote:
I don't see much interest in insert-efficient indexes.
>>>
>>> P
On Mon, Nov 4, 2013 at 11:24 AM, Claudio Freire wrote:
> Such a thing would help COPY, so maybe it's worth a look
I have little doubt that a deferred insertion buffer of some kind
could help performance on some workloads, though I suspect the buffer
would have to be pretty big to make it worthwhi
On Mon, Nov 4, 2013 at 1:27 PM, Robert Haas wrote:
> On Mon, Nov 4, 2013 at 11:24 AM, Claudio Freire
> wrote:
>> Such a thing would help COPY, so maybe it's worth a look
>
> I have little doubt that a deferred insertion buffer of some kind
> could help performance on some workloads, though I sus
On Sat, Nov 2, 2013 at 3:32 PM, Peter Eisentraut wrote:
> This doesn't seem right:
>
> $ pg_ctl -D /nowhere status
> pg_ctl: no server running
>
> It does exit with status 3, so it's not all that broken, but I think the
> error message could be more accurate.
I doubt anyone will object if you fee
On Mon, Nov 4, 2013 at 11:31 AM, Claudio Freire wrote:
> On Mon, Nov 4, 2013 at 1:27 PM, Robert Haas wrote:
>> On Mon, Nov 4, 2013 at 11:24 AM, Claudio Freire
>> wrote:
>>> Such a thing would help COPY, so maybe it's worth a look
>>
>> I have little doubt that a deferred insertion buffer of som
On 2013-11-04 11:27:33 -0500, Robert Haas wrote:
> On Mon, Nov 4, 2013 at 11:24 AM, Claudio Freire
> wrote:
> > Such a thing would help COPY, so maybe it's worth a look
>
> I have little doubt that a deferred insertion buffer of some kind
> could help performance on some workloads, though I susp
On Mon, Nov 4, 2013 at 11:32 AM, Andres Freund wrote:
> I think doing this outside of s_b will make stuff rather hard for
> physical replication and crash recovery since we either will need to
> flush the whole buffer at checkpoints - which is hard since the
> checkpointer doesn't work inside indi
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 11/4/13, 8:58 AM, Robert Haas wrote:
> > On Mon, Nov 4, 2013 at 5:57 AM, Michael Paquier
> > wrote:
> >>> Please find attached a patch doing what is written in the $subject.
> >> With the documentation updated, this is even better...
> >
> > I'm un
On Mon, Nov 4, 2013 at 11:45 AM, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> On 11/4/13, 8:58 AM, Robert Haas wrote:
>> > On Mon, Nov 4, 2013 at 5:57 AM, Michael Paquier
>> > wrote:
>> >>> Please find attached a patch doing what is written in the $subject.
>> >> With the
On Thu, Oct 31, 2013 at 3:42 PM, Robert Haas wrote:
> On Thu, Oct 31, 2013 at 2:44 PM, Garick Hamlin
wrote:
>> I think using /dev/urandom directly would be surprising. At least it
would
>> have probably have taken me a while to figure out what was depleting the
>> entropy pool here.
>
> Perhaps s
On Fri, Nov 01, 2013 at 04:51:34PM +, Tom Lane wrote:
> Remove internal uses of CTimeZone/HasCTZSet.
>
> The only remaining places where we actually look at CTimeZone/HasCTZSet
> are abstime2tm() and timestamp2tm(). Now that session_timezone is always
> valid, we can remove these special case
Amit Kapila writes:
> On Mon, Nov 4, 2013 at 8:15 PM, Tom Lane wrote:
>> Really I'd like to see standalone mode, in its current form, go away
>> completely. I had a prototype patch for allowing psql and other clients
>> to interface to a standalone backend. I think getting that finished would
>
Noah Misch writes:
> On Fri, Nov 01, 2013 at 04:51:34PM +, Tom Lane wrote:
>> Remove internal uses of CTimeZone/HasCTZSet.
> This changed EncodeDateTime() output for USE_SQL_DATES and USE_GERMAN_DATES
> styles, because it inserts a space before "tzn" but does not insert a space
> before Encod
On 05/11/13 05:35, Robert Haas wrote:
On Mon, Nov 4, 2013 at 11:32 AM, Andres Freund wrote:
I think doing this outside of s_b will make stuff rather hard for
physical replication and crash recovery since we either will need to
flush the whole buffer at checkpoints - which is hard since the
chec
On 4 November 2013 16:09, Robert Haas wrote:
> On Sat, Nov 2, 2013 at 6:07 AM, Simon Riggs wrote:
>> On 29 October 2013 16:10, Peter Geoghegan wrote:
>>> On Tue, Oct 29, 2013 at 7:53 AM, Leonardo Francalanci
>>> wrote:
I don't see much interest in insert-efficient indexes.
>>>
>>> Presuma
On Mon, Nov 4, 2013 at 8:09 AM, Robert Haas wrote:
> On Sat, Nov 2, 2013 at 6:07 AM, Simon Riggs wrote:
> > On 29 October 2013 16:10, Peter Geoghegan wrote:
> >> On Tue, Oct 29, 2013 at 7:53 AM, Leonardo Francalanci
> wrote:
> >>> I don't see much interest in insert-efficient indexes.
> >>
> >
Kevin Grittner wrote:
> Michael Paquier wrote:
>
>> I am not sure that adding a boolean flag introducing a concept
>> related to matview inside checkRuleResultList is the best
>> approach to solve that. checkRuleResultList is something related
>> only to rules, and has nothing related to matviews
On Mon, Oct 21, 2013 at 11:12 PM, Alexander Korotkov
wrote:
> Attached version of patch is debugged. I would like to note that number of
> bugs was low and it wasn't very hard to debug. I've rerun tests on it. You
> can see that numbers are improved as the result of your refactoring.
>
>
Folks,
>From our docs:
"Adding a column with a non-null default or changing the type of an
existing column will require the entire table and indexes to be
rewritten. As an exception, if the USING clause does not change the
column contents and the old type is either binary coercible to the new
typ
On Mon, Nov 4, 2013 at 5:01 PM, Simon Riggs wrote:
>> Of course, it's possible that even we do get a shared memory
>> allocator, a hypothetical person working on this project might prefer
>> to make the data block-structured anyway and steal storage from
>> shared_buffers. So my aspirations in th
On 4 November 2013 21:58, Josh Berkus wrote:
> Folks,
>
> From our docs:
>
> "Adding a column with a non-null default or changing the type of an
> existing column will require the entire table and indexes to be
> rewritten. As an exception, if the USING clause does not change the
> column contents
On 11/04/2013 09:55 PM, Robert Haas wrote:
> I continue to think that this syntax is misguided. For SELECT and
> DELETE there is only read-side security, and for INSERT there is only
> write-side security, so that's OK as far as it goes, but for UPDATE
> both read-side security and write-side secu
On Mon, Nov 04, 2013 at 02:34:02PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Fri, Nov 01, 2013 at 04:51:34PM +, Tom Lane wrote:
> >> Remove internal uses of CTimeZone/HasCTZSet.
>
> > This changed EncodeDateTime() output for USE_SQL_DATES and USE_GERMAN_DATES
> > styles, because it i
Thom,
> SELECT
> castsource::regtype::text,
> array_agg(casttarget::regtype order by casttarget::regtype::text)
> casttargets
> FROM pg_cast
> WHERE castmethod = 'b'
> GROUP BY 1
> ORDER BY 1;
Are we actually covering 100% of these for ALTER COLUMN now?
--
Josh Berkus
PostgreSQL Experts
On 11/04/2013 05:21 PM, Josh Berkus wrote:
> Thom,
>
>
>> SELECT
>> castsource::regtype::text,
>> array_agg(casttarget::regtype order by casttarget::regtype::text)
>> casttargets
>> FROM pg_cast
>> WHERE castmethod = 'b'
>> GROUP BY 1
>> ORDER BY 1;
>
> Are we actually covering 100% of thes
On 11/04/2013 11:17 PM, Robert Haas wrote:
> I'd still like to here what's wrong with what I said here:
>
> http://www.postgresql.org/message-id/ca+tgmoyr1phw3x9vnvuwdcfxkzk2p_jhtwc0fv2q58negcx...@mail.gmail.com
For me, just my understanding. I'm still too new to the planner and
rewriter to grasp
On Mon, Nov 04, 2013 at 05:23:36PM -0800, Josh Berkus wrote:
> On 11/04/2013 05:21 PM, Josh Berkus wrote:
> > Thom,
> >
> >
> >> SELECT
> >> castsource::regtype::text,
> >> array_agg(casttarget::regtype order by casttarget::regtype::text)
> >> casttargets
> >> FROM pg_cast
> >> WHERE castmet
On Tue, Nov 5, 2013 at 12:52 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Mon, Nov 4, 2013 at 8:15 PM, Tom Lane wrote:
>>> Really I'd like to see standalone mode, in its current form, go away
>>> completely. I had a prototype patch for allowing psql and other clients
>>> to interface to a st
On 11/04/2013 08:43 AM, Atri Sharma wrote:
> Please find attached our latest version of the patch. This version
> fixes the issues pointed out by the reviewers.
No, it doesn't. The documentation still contains formatting and
grammatical errors, and the code comments still do not match the their
s
On Mon, Nov 4, 2013 at 3:14 AM, Alvaro Herrera wrote:
> David Rowley escribió:
> > I've just been looking at how alignment of columns in tuples can make the
> > tuple larger than needed.
>
> This has been discussed at length previously, and there was a design
> proposed to solve this problem. See
On 4 November 2013 19:55, Gavin Flower wrote:
> How about having a 'TRANSIENT INDEX' that only exists in memory, so there is
> no requirement to write it to disk or to replicate directly? This type of
> index would be very fast and easier to implement. Recovery would involve
> rebuilding the ind
On Mon, Nov 4, 2013 at 12:20 AM, Tom Lane wrote:
> But we're not buying much. A few instructions during postmaster shutdown
> is entirely negligible.
>
The patch is for ClosePostmasterPorts(), which is called from every child
process startup sequence (as $subject also implies), not in postmaste
On 30 October 2013 14:34, Yann Fontana wrote:
>
>
>> On 30 October 2013 11:23, Leonardo Francalanci wrote:
>>
>> >> In terms of generality, do you think its worth a man year of developer
>> >> effort to replicate what you have already achieved? Who would pay?
>
>
> I work on an application that d
63 matches
Mail list logo
