On Aug 15, 2013 3:44 AM, "Tom Lane" wrote:
>
> Josh Berkus writes:
> >> Before 9.3, it would delete one specific file from a potentially shared
> >> directory. In 9.3 it deletes the entire contents of a potentially
shared
> >> directory. That is a massive expansion in the surface area for
> >>
On Wed, Aug 14, 2013 at 7:00 PM, Merlin Moncure wrote:
> Performance testing this patch is a real bugaboo for me; the VMs I have to
> work with are too unstable to give useful results :-(. Need to scrounge up
> a doner box somewhere...
While doing performance tests in this area, I always had
On Tue, 2013-08-13 at 09:27 +0100, Dean Rasheed wrote:
> So on balance I think you're right, and it would be better to simply say:
>
> ERROR: cannot insert into view "one"
> DETAIL: Views that do not select from a single table or view are not
> automatically updatable.
> HINT: You need an INSTE
On Wed, 2013-08-14 at 16:20 +0300, Heikki Linnakangas wrote:
> On 13.08.2013 14:31, Peter Eisentraut wrote:
> > On Wed, 2013-08-07 at 21:55 -0400, Peter Eisentraut wrote:
> >> WAL timelines are unsigned 32-bit integers everywhere, except the
> >> replication parser (replication/repl_gram.y and
> >>
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> "Etsuro Fujita" writes:
> > ISTM the README contains incorrect information and requires revision
> > to reflect the current code. Please find attached a patch. ISTM the
> > patch needs to be applied to all active branches.
>
> This patch isn't an
Tom Lane wrote:
> I think we should change 9.3 to be restrictive about ownership/permissions
> on the stats_temp_directory (ie, require owner = postgres user,
> permissions = 0700, same as for the $PGDATA directory). I agree that
> back-patching such a change to the older branches is probably not
Josh Berkus writes:
>> Before 9.3, it would delete one specific file from a potentially shared
>> directory. In 9.3 it deletes the entire contents of a potentially shared
>> directory. That is a massive expansion in the surface area for
>> unintentional deletion. If we will disallow using share
On Tue, 2013-08-13 at 14:30 -0700, Josh Berkus wrote:
> Currently PL/python has 1 dimension hardcoded for returning arrays:
>
> create or replace function nparr ()
> returns float[][]
> language plpythonu
> as $f$
> from numpy import array
> x = ((1.0,2.0),(3.0,4.0),(5.0,6.0),)
> return x
> $f$;
Jeff,
> Before 9.3, it would delete one specific file from a potentially shared
> directory. In 9.3 it deletes the entire contents of a potentially shared
> directory. That is a massive expansion in the surface area for
> unintentional deletion. If we will disallow using shared directories
> be
On Mon, Aug 12, 2013 at 11:31:38PM -0400, Bruce Momjian wrote:
> 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.
On Wed, Aug 7, 2013 at 07:04:43PM +0100, Thom Brown wrote:
> On 7 August 2013 18:49, Jon Nelson wrote:
> > On Wed, Aug 7, 2013 at 12:42 PM, Thom Brown wrote:
> >> for i in 1 2 5 10 100; do ./test_fallocate foo $i 1; done
> >> method: classic. 1 open/close iterations, 1 rewrite in 0.6380s
> >> me
On Tue, Aug 13, 2013 at 10:31 PM, Vlad Arkhipov wrote:
> I used to use VACUUM FULL periodically to resolve the issue, but the problem
> arises again in 2-3 months.
> Here is the statistics (from pgstattuple). I run VACUUM FULL on 2013-08-07.
>
> date| relpages | reltuples | table_len | tup
Antonin Houska writes:
> On 07/04/2013 06:11 PM, Antonin Houska wrote:
>> On 07/03/2013 08:32 PM, Tom Lane wrote:
>>> Another possibility would be to keep the optimization, but disable it in
>>> queries that use LATERAL. I don't much care for that though --- seems
>>> too Rube Goldbergish, and in
Rushabh Lathia writes:
> PFA patch and share your input/suggestions.
I think this needs review. Please add it to the next commitfest.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://w
"Etsuro Fujita" writes:
> ISTM the README contains incorrect information and requires revision to
> reflect
> the current code. Please find attached a patch. ISTM the patch needs to be
> applied to all active branches.
This patch isn't an improvement, since grouping_planner doesn't have
anythi
On 8/14/13 12:31 AM, Vlad Arkhipov wrote:
I used to use VACUUM FULL periodically to resolve the issue, but the problem
arises again in 2-3 months.
Here is the statistics (from pgstattuple). I run VACUUM FULL on 2013-08-07.
How much non-temporary DDL do you do? It's possible that you end up wit
On 8/14/13 8:30 AM, Merlin Moncure wrote:
Performance testing this patch is a real bugaboo for me; the VMs I have to work
with are too unstable to give useful results :-(. Need to scrounge up a doner
box somewhere...
I offered a server or two to the community a while ago but I don't think
a
Kevin Grittner wrote:
> Alvaro Herrera wrote:
>
>> Does the combination in $SUBJECT make sense?
>
> I don't think so; I don't know what it would mean.
Oh, I see -- it's part of the SELECT statement, causing a row-level
lock on each row as it is accessed.
>> It is currently allowed,
>
> I will t
Performance testing this patch is a real bugaboo for me; the VMs I have to
work with are too unstable to give useful results :-(. Need to scrounge up
a doner box somewhere...
On Tue, Aug 13, 2013 at 12:26 AM, Amit Kapila wrote:
> Merlin Moncure wrote:
> On Wed, Aug 7, 2013 at 11:52 PM, Amit Kap
On 13.08.2013 14:31, Peter Eisentraut wrote:
On Wed, 2013-08-07 at 21:55 -0400, Peter Eisentraut wrote:
WAL timelines are unsigned 32-bit integers everywhere, except the
replication parser (replication/repl_gram.y and
replication/repl_scanner.l) treats them as signed 32-bit integers. It's
obvio
On Tue, Aug 13, 2013 at 1:31 PM, Peter Eisentraut wrote:
> On Wed, 2013-08-07 at 21:55 -0400, Peter Eisentraut wrote:
>> WAL timelines are unsigned 32-bit integers everywhere, except the
>> replication parser (replication/repl_gram.y and
>> replication/repl_scanner.l) treats them as signed 32-bit
On Wed, Aug 14, 2013 at 10:10 AM, Robert Haas wrote:
> I think Alvaro's suggestion is better. It's shorter, and makes clear
> that at most one will be started.
OK cool. Here are patches for 9.3 and master respecting those comments.
Regards,
--
Michael
20130814_bgworker_refactor_93_v2.patch
De
Hi,
While working on something I come across this issue. Consider following
test:
postgres=# select version();
version
-
PostgreSQ
ISTM the README contains incorrect information and requires revision to reflect
the current code. Please find attached a patch. ISTM the patch needs to be
applied to all active branches.
Thanks,
Best regards,
Etsuro Fujita
optimizer-readme.patch
Description: Binary data
--
Sent via pgsql-ha
24 matches
Mail list logo
