On Mon, Aug 12, 2013 at 08:16:59PM -0700, Jeff Janes wrote:
> On Mon, Aug 12, 2013 at 1:31 PM, tubadzin wrote:
> > Hi users.
> > I want to sure, that is no this implementation in Postgresql:
> > For Sorte Merge Join Alghoritm:
> > If the large input arrives sorted,
> > g-join joins its pages with
Hello
2013/8/12 Pavel Stehule :
> 2013/8/10 Tom Lane :
>> Pavel Stehule writes:
>>> I found so there are no simple API for working with LO from PL without
>>> access to file system.
>>
>> What? See lo_open(), loread(), lowrite(), etc.
>>
so simplified functionality should have a little bit diff
Merlin Moncure wrote:
On Wed, Aug 7, 2013 at 11:52 PM, Amit Kapila
wrote:
>>> -Original Message-
>>> From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
>>> owner(at)postgresql(dot)org] On Behalf Of Merlin Moncure
>>> Sent: Thursday, August 08, 2013 12:09 AM
>>> To: Andr
Reviving a very old thread, because I've run into the issue again.
On Tue, May 29, 2012 at 11:58 AM, Robert Haas wrote:
> On Fri, May 25, 2012 at 4:06 PM, Jeff Janes wrote:
>> If I invoke vacuum manually and do so with VacuumCostDelay == 0, I
>> have basically declared my intentions to get this
On Mon, Aug 12, 2013 at 05:19:30PM -0400, Bruce Momjian wrote:
> Attached are docs that add the new syntax, and mention it is
> non-standard; you can see the output here:
>
> http://momjian.us/tmp/pgsql/functions-string.html#FUNCTIONS-STRING-SQL
>
> We do document three syntaxes for substr
On Mon, Aug 12, 2013 at 1:31 PM, tubadzin wrote:
> Hi users.
> I want to sure, that is no this implementation in Postgresql:
> For Sorte Merge Join Alghoritm:
> If the large input arrives sorted,
> g-join joins its pages with the buffer pool contents by strictly
> increasing join key values and t
> > However it occurs to me that the plan isn't ideal:
> >
> > postgres=# explain select * from generate_series(1,10) with ordinality
> > as a(a,o) natural full outer join generate_series(1,5) with ordinality
> > as b(b,o) ;
> > QUERY PLAN
> > -
On Mon, Aug 12, 2013 at 11:41 PM, Tom Lane wrote:
> That sounds like a mess --- race conditions all over the place, even aside
> from efficiency worries.
This I don't understand. All I'm envisioning is setting a flag in the
signal handler. If that flag is set then the next CHECK_FOR_INTERRUPTS
On Wed, 2013-08-07 at 21:19 -0400, Peter Eisentraut wrote:
> To make the view updatable, provide an unconditional ON DELETE DO
> INSTEAD rule or an INSTEAD OF DELETE trigger.
>
> I think it's a bit strange to claim that adding a DELETE rule/trigger
> makes a view *updatable*. I suspect someone th
Greg Stark writes:
> So I poked around a bit. It looks like Linux does send a SIGIO when a
> tcp connection is closed (with POLL_HUP if it's closed and POLL_IN if
> it's half-closed). So it should be possible to arrange to get a signal
> which CHECK_FOR_INTERRUPTS could handle the normal way.
> H
On Mon, Aug 12, 2013 at 6:56 PM, Tom Lane wrote:
> Jeff Janes writes:
>> On Sat, Aug 10, 2013 at 4:26 AM, Greg Stark wrote:
>>> The problem is that I don't know of any way to detect eof on a socket
>>> other than trying to read from it (or calling poll or select).
>
>> Do we know how inefficient
On 08/12/2013 01:31 PM, tubadzin wrote:
> Hi users.
> I want to sure, that is no this implementation in Postgresql:
> For Sorte Merge Join Alghoritm:
> If the large input arrives sorted,
> g-join joins its pages with the buffer pool contents by strictly
> increasing join key values and the join ou
On Mon, Aug 12, 2013 at 04:58:23PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > We did have someone confused by what we have now, as well as me, so I
> > think there is a reason to clean this up. It would be a
> > backward-compatible change, though.
>
> backward-INcompatible, I assume you
Bruce Momjian writes:
> We did have someone confused by what we have now, as well as me, so I
> think there is a reason to clean this up. It would be a
> backward-compatible change, though.
backward-INcompatible, I assume you meant.
> To document this, I think we would need to add only one line
On Mon, Aug 12, 2013 at 10:08:07PM +0200, Pavel Raiskup wrote:
> > The patch moves the atexit setting up, as you suggested, but only does
> > that when pg_ctl succeeds (we know we started the server),
>
> Yes, of course!
>
> > PG 9.1+ will allow pg_ctl -w start to succeed even if there are
> > pe
Hi users.
I want to sure, that is no this implementation in Postgresql:
For Sorte Merge Join Alghoritm:
If the large input arrives sorted,
g-join joins its pages with the buffer pool contents by strictly
increasing join key values and the join output is also strictly
sorted.
Is it difficult to i
On Mon, Aug 12, 2013 at 02:18:01PM -0400, Tom Lane wrote:
> No, wait, I take that back. I was thinking that the function call would
> dump out as trim(x, y) but actually none of the underlying functions
> are named just "trim"; they're btrim, ltrim, or rtrim. So actually the
> dump/reload scenari
> The patch moves the atexit setting up, as you suggested, but only does
> that when pg_ctl succeeds (we know we started the server),
Yes, of course!
> PG 9.1+ will allow pg_ctl -w start to succeed even if there are
> permissions problems; earlier versions will not and will keep the
> server run
[ fixed hackers CC address ]
On Mon, Aug 12, 2013 at 12:31:10PM +0200, Pavel Raiskup wrote:
> The latest update on original bug report at Red Hat bugzilla shows that the
> reproducer is just disable the peer access for 'postgres' user in
> pg_hba.conf. So — the old server was most probably still
On Mon, Aug 5, 2013 at 2:02 PM, Pavel Stehule wrote:
> Hello
>
> 2013/8/5 David Gudeman :
>> For those who don't want to go to the link to see what I'm talking
>> about with query rewrites, I thought I'd give a brief description.
>> Foreign data wrappers currently do all of their work in the plann
On 08/12/2013 02:22 PM, Magnus Hagander wrote:
On Mon, Aug 12, 2013 at 8:14 PM, Andrew Dunstan wrote:
On 08/12/2013 01:40 PM, Magnus Hagander wrote:
I also like the concept of #2, but I think we need to think about it a
bit more. One of the things I like about barman backups is that on
recove
On Mon, Aug 12, 2013 at 8:14 PM, Andrew Dunstan wrote:
>
> On 08/12/2013 01:40 PM, Magnus Hagander wrote:
I also like the concept of #2, but I think we need to think about it a
bit more. One of the things I like about barman backups is that on
recovery you can map where tablesp
I wrote:
> This will break even more stuff than the last patch, ie, every single
> stored rule or view that contains a TRIM function. You can *not*
> eliminate, or mess with, the expr_list production, because that's what
> dumping of these function calls relies on.
No, wait, I take that back. I
On 08/12/2013 01:40 PM, Magnus Hagander wrote:
I also like the concept of #2, but I think we need to think about it a
bit more. One of the things I like about barman backups is that on
recovery you can map where tablespaces go, on a per tablespace basis
(it's not very well documented, or wasn't
2013/8/10 Tom Lane :
> Pavel Stehule writes:
>> I found so there are no simple API for working with LO from PL without
>> access to file system.
>
> What? See lo_open(), loread(), lowrite(), etc.
>
yes, so there are three problems with these functions:
a) probably (I didn't find) undocumented
On Mon, Aug 12, 2013 at 12:28:26PM -0400, Peter Eisentraut wrote:
> On 8/9/13 12:04 AM, Bruce Momjian wrote:
> > generates this output:
> >
> > SET search_path = xx, pg_catalog;
> > CREATE TABLE test (
> > x integer
> > );
> >
> > If you dump a schema and want to reload it int
Jeff Janes writes:
> On Sat, Aug 10, 2013 at 4:26 AM, Greg Stark wrote:
>> The problem is that I don't know of any way to detect eof on a socket
>> other than trying to read from it (or calling poll or select).
> Do we know how inefficient it is, compared to the baseline work done
> by CHECK_FOR
Bruce Momjian writes:
> Based on my research, I am now proposing a new, attached patch which
> eliminates comma in all places in TRIM,
This will break even more stuff than the last patch, ie, every single
stored rule or view that contains a TRIM function. You can *not*
eliminate, or mess with, t
On Mon, Aug 5, 2013 at 10:03 PM, Noah Misch wrote:
> On Thu, Aug 01, 2013 at 01:04:42PM -0400, Andrew Dunstan wrote:
>> On 08/01/2013 12:15 PM, Noah Misch wrote:
>>> 1. Include in the base backup a file listing symbolic links/junction points,
>>> then have archive recovery recreate them. This fil
On 12 August 2013 18:37, Peter Eisentraut wrote:
> On 8/8/13 3:44 PM, Josh Berkus wrote:
> > Other than that, no. I was thinking of creating a general tool as a
> > custom background worker, which would take stored procedure calls and
> > pass them through to PostgreSQL, returning results as JSO
On 8/8/13 3:44 PM, Josh Berkus wrote:
> Other than that, no. I was thinking of creating a general tool as a
> custom background worker, which would take stored procedure calls and
> pass them through to PostgreSQL, returning results as JSON. Mainly
> because I need it for a project. However, thi
On 8/9/13 12:04 AM, Bruce Momjian wrote:
> generates this output:
>
> SET search_path = xx, pg_catalog;
> CREATE TABLE test (
> x integer
> );
>
> If you dump a schema and want to reload it into another schema, you
> should only need to update that one search_path line
On Sat, Aug 10, 2013 at 4:26 AM, Greg Stark wrote:
>
> The problem is that I don't know of any way to detect eof on a socket
> other than trying to read from it (or calling poll or select). So the
> server would have to periodically poll the client even when it's not
> expecting any data. The inef
On Sat, 10 Aug 2013 09:33:05 -0700, Noah Misch , wrote:
>Note that PostgreSQL 8.3 had xmlvalidate() for a time; commit
we found that, xmlvalidate() was for checking well formedness of an xml doc,
not for validating against xml schema, we inferred this from Release note of
8.2
for reference, be
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 8/1/13 1:42 PM, Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >> pgsecure_open_client() returns -1 if it can't lock the mutex. This is a
> >> problem because the callers are not prepared for that return value. I
> >>
On Fri, Aug 9, 2013 at 12:23:59PM -0400, Bruce Momjian wrote:
> Yes, I have thought about this some more and another problem is that
> rtrim/btrim/ltrim() use the source string first, so having trim() have
> the source string second when using a comma is very confusing, e.g.:
>
> -- with pa
On 8/1/13 1:42 PM, Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>> pgsecure_open_client() returns -1 if it can't lock the mutex. This is a
>> problem because the callers are not prepared for that return value. I
>> think it should return PGRES_POLLING_FAILED instead,
The latest update on original bug report at Red Hat bugzilla shows that the
reproducer is just disable the peer access for 'postgres' user in
pg_hba.conf. So — the old server was most probably still running for OP
(not shut down properly as was originally said).
But basically, this fix is relevan
38 matches
Mail list logo
