While trying out CURRENT OF with foreign table, ending up with error.
postgres=# select version();
version
-
PostgreSQL 9.3devel on
On Wed, Apr 17, 2013 at 12:49:10PM +0200, Florian Pflug wrote:
> Fixing this on the receive side alone seems quite messy and fragile.
> So instead, I think we should let the master send a shutdown message
> after it has sent everything it wants to send, and wait for the client
> to acknowledge it b
On Thu, Apr 18, 2013 at 2:11 PM, Heikki Linnakangas
wrote:
> I just found out that if you use continuous archiving and online backups,
> it's surprisingly difficult to restore a backup, without replaying any more
> WAL than necessary.
>
> If you don't set a recovery target, PostgreSQL will recover
On Wed, Apr 17, 2013 at 3:58 PM, Fabrízio de Royes Mello
wrote:
> The attached patch fix a little typo on contrib/hstore/crc32.c comment.
Thanks. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsq
On Wed, Apr 17, 2013 at 6:17 PM, Tom Lane wrote:
> No, it's a critical tool in complexity management. When you're dealing
> with systems as complicated as a database, every little non-orthogonal
> detail adds up. DISCARD ALL has a clear definition in terms of simpler
> commands, and it's going t
On Fri, Apr 19, 2013 at 10:50 AM, Robert Haas wrote:
>
> [...]
>
> So it seems to me that we pretty much already made a decision that the
> controlling definition of DISCARD ALL is that, as the fine manual says
> "DISCARD ALL resets a session to its original state". Whatever
> decision we make n
Rushabh Lathia writes:
> While trying out CURRENT OF with foreign table, ending up with error.
Yeah, that's an unimplemented feature.
In principle I think it could be made to work with postgres_fdw (since
that uses CTID row identification), but I doubt that it'd be possible
to promise that it wo
On 4/18/13 11:31 AM, Dimitri Fontaine wrote:
> The only questions in this thread are:
>
> - only docs or docs + contrib example?
At this point, all that is appropriate is some documentation of the C
API. If the contrib example you have in mind is short enough, it might
as well become part of t
On Fri, Apr 19, 2013 at 10:05 AM, Fabrízio de Royes Mello
wrote:
> The attached wip patch do that and introduce a subcommand 'SEQUENCES', but
> if we decide to don't add a new subcommand to DISCARD, then its easier to
> modify the patch.
This patch is quite wrong. It frees seqtab without clearin
On Fri, Apr 19, 2013 at 10:11 AM, Tom Lane wrote:
> Rushabh Lathia writes:
>> While trying out CURRENT OF with foreign table, ending up with error.
>
> Yeah, that's an unimplemented feature.
>
> In principle I think it could be made to work with postgres_fdw (since
> that uses CTID row identifica
On 04/19/2013 06:50 AM, Robert Haas wrote:
On Wed, Apr 17, 2013 at 6:17 PM, Tom Lane wrote:
No, it's a critical tool in complexity management. When you're dealing
with systems as complicated as a database, every little non-orthogonal
detail adds up. DISCARD ALL has a clear definition in terms
Robert Haas writes:
> On Fri, Apr 19, 2013 at 10:11 AM, Tom Lane wrote:
>> Yeah, that's an unimplemented feature.
> So, should we just make that an
> ereport(errcode(ERRCODE_FEATURE_NOT_SUPPORTED), ...) instead of
> elog()?
I'm not that excited about the errcode; if we're going to do anything,
On Fri, Apr 19, 2013 at 10:24 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 19, 2013 at 10:11 AM, Tom Lane wrote:
>>> Yeah, that's an unimplemented feature.
>
>> So, should we just make that an
>> ereport(errcode(ERRCODE_FEATURE_NOT_SUPPORTED), ...) instead of
>> elog()?
>
> I'm not t
Robert Haas writes:
> My main concern was actually whether we ought to be detecting this
> earlier in the process, before it gets as far as the executor.
Yeah, that might be an appropriate response too. The executor is
coded so cavalierly because it expects the planner to have replaced
the CURRE
On Fri, Apr 19, 2013 at 11:12 AM, Robert Haas wrote:
> On Fri, Apr 19, 2013 at 10:05 AM, Fabrízio de Royes Mello
> wrote:
> > The attached wip patch do that and introduce a subcommand 'SEQUENCES',
> but
> > if we decide to don't add a new subcommand to DISCARD, then its easier to
> > modify the
Fabrízio de Royes Mello escribió:
> Ohh sorry... you're all right... I completely forgot to finish the
> ReleaseSequenceCaches to transverse 'seqtab' linked list and free each
> node.
>
> The attached patch have this correct code.
It seems a bad idea to backpatch this; whoever wants this functio
Alvaro Herrera writes:
> It seems a bad idea to backpatch this; whoever wants this functionality
> in back branches should probably run a patched server.
Surely this is 9.4 material at this point in any case.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pg
Hello All,
I'm writing today to inquire about finding the exact point in the source
where postgres writes to disk. I'm trying to implement some compression in
postgres. The idea is to compress the data right when its written to disk,
to reduce the amount of data written to disk, reducing the amount
Will,
* Will Childs-Klein (willc...@gmail.com) wrote:
> I'm writing today to inquire about finding the exact point in the source
> where postgres writes to disk. I'm trying to implement some compression in
> postgres.
PostgreSQL already does compression in most cases where you'd want it
done..
On Fri, Apr 19, 2013 at 10:17 AM, Will Childs-Klein wrote:
> Hello All,
> I'm writing today to inquire about finding the exact point in the source
> where postgres writes to disk. I'm trying to implement some compression in
> postgres. The idea is to compress the data right when its written to dis
On Fri, Apr 19, 2013 at 11:09 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> It seems a bad idea to backpatch this; whoever wants this functionality
>> in back branches should probably run a patched server.
>
> Surely this is 9.4 material at this point in any case.
I don't know why this couldn'
I would expect the strategy you have in mind to be more useful to apply at
the filesystem level, so that it's not in Postgres altogether. (Ala
"Stacker", remember DR-DOS?)
But, to speak arguable heresy, the demerits of this sort of thing are
described nicely in Another Database's Documentation: <
On Fri, Apr 19, 2013 at 11:17 AM, Christopher Browne wrote:
>
> I would expect the strategy you have in mind to be more useful to apply at
> the filesystem level, so that it's not in Postgres altogether. (Ala
> "Stacker", remember DR-DOS?)
>
> But, to speak arguable heresy, the demerits of this s
On Apr19, 2013, at 14:46 , Martijn van Oosterhout wrote:
> On Wed, Apr 17, 2013 at 12:49:10PM +0200, Florian Pflug wrote:
>> Fixing this on the receive side alone seems quite messy and fragile.
>> So instead, I think we should let the master send a shutdown message
>> after it has sent everything
I wrote:
> Robert Haas writes:
>> My main concern was actually whether we ought to be detecting this
>> earlier in the process, before it gets as far as the executor.
> Yeah, that might be an appropriate response too. The executor is
> coded so cavalierly because it expects the planner to have r
On Wed, Apr 17, 2013 at 7:33 PM, Jeff Janes wrote:
> On Wednesday, April 17, 2013, Peter Eisentraut wrote:
>>
>> When archive_command fails three times, it prints this message into the
>> logs:
>>
>> "transaction log file \"%s\" could not be archived: too many failures"
>>
>> This leaves it open w
On Wed, Apr 3, 2013 at 6:40 PM, Greg Stark wrote:
>
> On Fri, Aug 21, 2009 at 6:54 PM, decibel wrote:
>
>> Would it? Risk seems like it would just be something along the lines of
>> the high-end of our estimate. I don't think confidence should be that hard
>> either. IE: hard-coded guesses have
On Fri, Apr 19, 2013 at 6:19 PM, Jeff Janes wrote:
> On Wed, Apr 3, 2013 at 6:40 PM, Greg Stark wrote:
>>
>>
>> On Fri, Aug 21, 2009 at 6:54 PM, decibel wrote:
>>>
>>> Would it? Risk seems like it would just be something along the lines of
>>> the high-end of our estimate. I don't think confiden
On Thu, Apr 4, 2013 at 11:53 AM, Dimitri Fontaine wrote:
> Robert Haas writes:
> > for estimate_worstcase_fraction. So, when computing the cost of a
> > path, we'd compute our current expected-case estimate, and also a
> > worst-case estimate, and then compute the final cost as:
>
> There also w
On Fri, Apr 19, 2013 at 2:24 PM, Claudio Freire wrote:
>
> Especially if there's some locality of occurrence, since analyze
> samples pages, not rows.
>
But it doesn't take all rows in each sampled page. It generally takes
about one row per page, specifically to avoid the problem you indicate.
M
On Fri, Apr 19, 2013 at 7:43 PM, Jeff Janes wrote:
> On Fri, Apr 19, 2013 at 2:24 PM, Claudio Freire
> wrote:
>>
>>
>> Especially if there's some locality of occurrence, since analyze
>> samples pages, not rows.
>
>
> But it doesn't take all rows in each sampled page. It generally takes about
>
31 matches
Mail list logo
