On Fri, Mar 28, 2014 at 12:16 PM, David Johnston wrote:
>
> Slightly tangential but are the locking operations associated with the
> recent bugfix generated in both (all?) modes or only hot_standby? I thought
> it strange that transient locking operations were output with WAL though I
> get it if
Hi,
> > Went looking for this in the docs...
> >
> > http://www.postgresql.org/docs/9.3/interactive/runtime-config-wal.html#GUC-WAL-LEVEL
> >
> > So I guess, no-restore/offline/online would be good names (and maybe
> > wal_restore_mode instead of wal_level) if we started from scratch. Note
> >
Hello,
> > At Wed, 19 Mar 2014 19:34:10 +0900, Fujii Masao wrote
> >> > Agreed. Attached patches do that and I could "recover" the
> >> > database state with following steps,
> >>
> >> Adding new option looks like new feature rather than bug fix.
> >> I'm afraid that the backpatch of such a change
Hello,
> > After all, pmState changes to PM_NO_CHILDREN via PM_WAIT_DEAD_END
> > by SIGCHLDs from non-significant processes, then CancelBackup().
>
> Judging from what was being said on the thread, it seems that running
> CancelBackup() after an immediate shutdown is better than not doing it,
> c
Hi,
> > ForeignPath *pathnode = makeNode(ForeignPath);
> > + Assert(rel->rtekind == RTE_RELATION);
> >
> > pathnode->path.pathtype = T_ForeignScan;
..
> Maybe I'm missing the point, but I don't think it'd be better to put the
> assertion in create_foreignscan_path(). And I think it'd
David Johnston wrote
>
> Noah Misch-2 wrote
>> On Thu, Mar 27, 2014 at 03:06:02PM -0700, David Johnston wrote:
>>> shamccoy wrote
>>> > Hello. I've been doing some benchmarks on performance / size
>>> differences
>>> > between actions when wal_level is set to either archive or
>>> hot_standby.
>
Noah Misch-2 wrote
> On Thu, Mar 27, 2014 at 03:06:02PM -0700, David Johnston wrote:
>> shamccoy wrote
>> > Hello. I've been doing some benchmarks on performance / size
>> differences
>> > between actions when wal_level is set to either archive or hot_standby.
>> > I'm not seeing a ton of differe
Hi,
this is a patch for issue reported in October 2013 in pgsql-bugs:
http://www.postgresql.org/message-id/3839201.nfa2rvc...@techfox.foxi
Frank van Vugt reported that a simple query with array_agg() and large
number of groups (1e7) fails because of OOM even on machine with 32GB of
RAM.
So fo
On Thu, Mar 27, 2014 at 03:06:02PM -0700, David Johnston wrote:
> shamccoy wrote
> > Hello. I've been doing some benchmarks on performance / size differences
> > between actions when wal_level is set to either archive or hot_standby.
> > I'm not seeing a ton of difference. I've read some posts a
On 03/27/2014 05:15 PM, Andres Freund wrote:
On 2014-03-27 12:56:02 -0300, Alvaro Herrera wrote:
Also, there's the vcregress.pl business. The way it essentially
duplicates pg_upgrade/test.sh is rather messy; and now that
test_decoding also needs similar treatment, it's not looking so good.
Sho
On 03/27/2014 03:06 PM, David Johnston wrote:
> As I think both can be used for PITR I don't believe there is much downside,
> technically or with resources, to using hot_standby instead of archive; but
> I do not imagine it having any practical benefit either.
Actually, "hot_standby" does have to
Hi everyone,
On Sun, Sep 22, 2013 at 4:38 PM, Stas Kelvich wrote:
> Here is the patch that introduces kNN search for cubes with euclidean,
> taxicab and chebyshev distances.
What is the status of this patch?
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.c
shamccoy wrote
> Hello. I've been doing some benchmarks on performance / size differences
> between actions when wal_level is set to either archive or hot_standby.
> I'm not seeing a ton of difference. I've read some posts about
> discussions as to whether this parameter should be simplified and
On 2014-03-27 12:56:02 -0300, Alvaro Herrera wrote:
> Also, there's the vcregress.pl business. The way it essentially
> duplicates pg_upgrade/test.sh is rather messy; and now that
> test_decoding also needs similar treatment, it's not looking so good.
> Should we consider redoing that stuff in a w
On 2014-03-27 13:52:19 -0400, Noah Misch wrote:
> On Thu, Mar 27, 2014 at 12:56:02PM -0300, Alvaro Herrera wrote:
> > Also, there's the vcregress.pl business. The way it essentially
> > duplicates pg_upgrade/test.sh is rather messy; and now that
> > test_decoding also needs similar treatment, it's
On 2014-03-27 09:15:52 -0400, Bruce Momjian wrote:
> When we made OIDs optional, we added an oid status display to \d+:
>
> test=> \d+ test
>Table "public.test"
>Column | Type | Modifiers | Storage | Stats target | Description
> +-
First, sorry guys for letting this slide - I was overwhelmed by other works,
and this kind of slipped my mind :-(
On Mar27, 2014, at 09:04 , Dean Rasheed wrote:
> On 26 March 2014 19:43, David Rowley wrote:
>> On Thu, Mar 27, 2014 at 7:33 AM, Tom Lane wrote:
>>>
>>> David Rowley writes:
Peter Eisentraut writes:
> You backpatched this change, but that can't be right, because the
> feature that requires the cdecimal module was added in 9.4
> (7919398bac8bacd75ec5d763ce8b15ffaaa3e071).
Ah. I saw that the failing tests were quite old, but did not realize
that we'd only recently add
On 03/27/2014 04:43 PM, David Johnston wrote:
Bruce Momjian wrote
When we made OIDs optional, we added an oid status display to \d+:
test=> \d+ test
Table "public.test"
Column | Type | Modifiers | Storage | Stats target | Description
Bruce Momjian wrote
> When we made OIDs optional, we added an oid status display to \d+:
>
> test=> \d+ test
>Table "public.test"
>Column | Type | Modifiers | Storage | Stats target | Description
> +-+---+-+
On 03/27/2014 04:31 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 03/27/2014 11:56 AM, Alvaro Herrera wrote:
Also, there's the vcregress.pl business. The way it essentially
duplicates pg_upgrade/test.sh is rather messy; and now that
test_decoding also needs similar treatment, it's not lookin
Andrew Dunstan writes:
> On 03/27/2014 11:56 AM, Alvaro Herrera wrote:
>> Also, there's the vcregress.pl business. The way it essentially
>> duplicates pg_upgrade/test.sh is rather messy; and now that
>> test_decoding also needs similar treatment, it's not looking so good.
>> Should we consider r
With the addition of LATERAL subqueries, Tom fixed up the mechanism
for keeping track of which relations are visible for column references
while the FROM clause is being scanned. That allowed
errorMissingColumn() to give a more useful error to the one produced
by the prior coding of that mechanism,
On 03/27/2014 11:56 AM, Alvaro Herrera wrote:
Also, there's the vcregress.pl business. The way it essentially
duplicates pg_upgrade/test.sh is rather messy; and now that
test_decoding also needs similar treatment, it's not looking so good.
Should we consider redoing that stuff in a way that al
* Euler Taveira (eu...@timbira.com.br) wrote:
> On 27-03-2014 10:15, Bruce Momjian wrote:
> > When we made OIDs optional, we added an oid status display to \d+:
> >
> > test=> \d+ test
> > Table "public.test"
> > Column | Type | Modifiers | Storage | Stats
On 27-03-2014 10:15, Bruce Momjian wrote:
> When we made OIDs optional, we added an oid status display to \d+:
>
> test=> \d+ test
>Table "public.test"
>Column | Type | Modifiers | Storage | Stats target | Description
> +-+
On Thu, Mar 27, 2014 at 12:56:02PM -0300, Alvaro Herrera wrote:
> Also, there's the vcregress.pl business. The way it essentially
> duplicates pg_upgrade/test.sh is rather messy; and now that
> test_decoding also needs similar treatment, it's not looking so good.
> Should we consider redoing that
On Mon, Mar 24, 2014 at 11:52:30AM +0530, Ashutosh Bapat wrote:
> For all the members of struct employee, except arr_col, the size of array
> is set to 14 and next member offset is set of sizeof (struct employee). But
> for arr_col they are set to 3 and sizeof(int) resp. So, for the next row
> onwa
Alvaro Herrera writes:
> Note that "make check" in contrib is substantially slower than "make
> installcheck" --- it creates a temporary installation for each contrib
> module. If we make buildfarm run installcheck for all modules, that
> might be a problem for some animals. Would it be possible
Re: Bruce Momjian 2013-12-04 <20131204151533.gb17...@momjian.us>
> On Mon, May 6, 2013 at 11:51:47PM -0700, Christoph Berg wrote:
> > "make check" supports EXTRA_REGRESS_OPTS to pass extra options to
> > pg_regress, but all the other places where pg_regress is used do not
> > allow this. The attac
Hello
After week, I can to evaluate a community reflection:
2014-03-19 16:34 GMT+01:00 Pavel Stehule :
> Hello
>
> I wrote a few patches, that we use in our production. These patches are
> small, but I hope, so its can be interesting for upstream:
>
> 1. cancel time - we log a execution time ca
Hello
2014-03-20 1:28 GMT+01:00 Josh Berkus :
> Pavel,
>
> > I wrote a few patches, that we use in our production. These patches are
> > small, but I hope, so its can be interesting for upstream:
> >
> > 1. cancel time - we log a execution time cancelled statements
>
> Manually cancelled? state
On 2014-03-27 11:12:41 -0400, Andrew Dunstan wrote:
> >No, unless you're building with some options the buildfarm doesn't
> >exercise. (Well, the buildfarm does installcheck rather than check for
> >contrib, but that should not matter.)
> And I see it does. I missed that, and I don't think anyone
Andrew Dunstan wrote:
> For several reasons. It's not simply a matter of running that
> command. You also have to bundle up the various log files. Also, if
> all we do is "check-world" and it fails that fact gives us
> relatively little information, whereas if it passes "make check" but
> fails "m
On 03/27/2014 11:34 AM, Christoph Berg wrote:
Re: Andrew Dunstan 2014-03-27 <53344465.6010...@dunslane.net>
On 03/27/2014 11:27 AM, Tom Lane wrote:
Andrew Dunstan writes:
I guess we'd better add a make-contrib-check step to the buildfarm. I
was just prepping a release, so I'll delay that whi
On 26 March 2014 19:43, David Rowley wrote:
> On Thu, Mar 27, 2014 at 7:33 AM, Tom Lane wrote:
>>
>> David Rowley writes:
>> > I've attached an updated invtrans_strictstrict_base patch which has the
>> > feature removed.
>>
>> What is the state of play on this patch? Is the latest version what'
Re: Andrew Dunstan 2014-03-27 <53344465.6010...@dunslane.net>
>
> On 03/27/2014 11:27 AM, Tom Lane wrote:
> >Andrew Dunstan writes:
> >>I guess we'd better add a make-contrib-check step to the buildfarm. I
> >>was just prepping a release, so I'll delay that while I add this.
> >BTW, won't that ob
Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
> >> I meant to say what's actually in git HEAD at the moment is broken.
>
> > Uh, I thought that might be what you were saying, but I am not seeing
> > any failures here.
>
> The buildfar
On 03/27/2014 11:27 AM, Tom Lane wrote:
Andrew Dunstan writes:
I guess we'd better add a make-contrib-check step to the buildfarm. I
was just prepping a release, so I'll delay that while I add this.
BTW, won't that obsolete the need for the separate check-pg_upgrade
step?
Andrew Dunstan writes:
> I guess we'd better add a make-contrib-check step to the buildfarm. I
> was just prepping a release, so I'll delay that while I add this.
BTW, won't that obsolete the need for the separate check-pg_upgrade
step?
regards, tom lane
--
Sent via p
On 03/27/2014 10:31 AM, Andrew Dunstan wrote:
On 03/27/2014 10:13 AM, Tom Lane wrote:
Bruce Momjian writes:
On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
I meant to say what's actually in git HEAD at the moment is broken.
Uh, I thought that might be what you were saying,
On Thu, Mar 27, 2014 at 10:30:59AM -0400, Bruce Momjian wrote:
> On Thu, Mar 27, 2014 at 10:13:36AM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
> > >> I meant to say what's actually in git HEAD at the moment is broken.
> >
On Thu, Mar 27, 2014 at 10:13:36AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
> >> I meant to say what's actually in git HEAD at the moment is broken.
>
> > Uh, I thought that might be what you were saying, but I am not seein
On 03/27/2014 10:13 AM, Tom Lane wrote:
Bruce Momjian writes:
On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
I meant to say what's actually in git HEAD at the moment is broken.
Uh, I thought that might be what you were saying, but I am not seeing
any failures here.
The buil
Bruce Momjian writes:
> On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
>> I meant to say what's actually in git HEAD at the moment is broken.
> Uh, I thought that might be what you were saying, but I am not seeing
> any failures here.
The buildfarm isn't complaining, either. Is
On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
> Re: Bruce Momjian 2014-03-27 <20140327131048.ga11...@momjian.us>
> > On Thu, Mar 27, 2014 at 10:02:20AM +0100, Christoph Berg wrote:
> > > Re: Bruce Momjian 2014-03-26 <20140326161056.ga...@momjian.us>
> > > > The attached patch matc
Re: Bruce Momjian 2014-03-27 <20140327131048.ga11...@momjian.us>
> On Thu, Mar 27, 2014 at 10:02:20AM +0100, Christoph Berg wrote:
> > Re: Bruce Momjian 2014-03-26 <20140326161056.ga...@momjian.us>
> > > The attached patch matches your suggestion. It is basically back to
> > > what the code origin
When we made OIDs optional, we added an oid status display to \d+:
test=> \d+ test
Table "public.test"
Column | Type | Modifiers | Storage | Stats target | Description
+-+---+-+--+-
On Thu, Mar 27, 2014 at 10:02:20AM +0100, Christoph Berg wrote:
> Re: Bruce Momjian 2014-03-26 <20140326161056.ga...@momjian.us>
> > The attached patch matches your suggestion. It is basically back to
> > what the code originally had, except it skips system tables, and shows
> > "???" for invalid
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-03-26 13:41:27 -0400, Stephen Frost wrote:
> > > Good catch. There's actually no need for explicitly using the context,
> > > we're in the appropriate one. The only other MemoryContextAlloc() caller
> > > in there should be converted to a pa
On Mar 27, 2014 12:45 PM, "Tom Lane" wrote:
>
> Magnus Hagander writes:
> > On Thu, Mar 27, 2014 at 9:12 AM, Rajeev rastogi
> > wrote:
> >> But current code does not behave in this manner. Even if dbistemplate
of
> >> database is false, still it allows to be used as template database.
>
> > AFAI
Buildfarm member prairiedog thinks there's something unreliable about
commit f01d1ae3a104019d6d68aeff85c4816a275130b3:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2014-03-27%2008%3A12%3A11
== pgsql.13462/src/test/regress/regression.diffs
==
Magnus Hagander writes:
> On Thu, Mar 27, 2014 at 9:12 AM, Rajeev rastogi
> wrote:
>> But current code does not behave in this manner. Even if dbistemplate of
>> database is false, still it allows to be used as template database.
> AFAICT, the *only* thing datistemplate is used is to set paramet
* Magnus Hagander (mag...@hagander.net) wrote:
> However, that also raises a third option. We could just drop the idea if
> datistemplate completely, and remove the column. Since clearly it's not
> actually doing anything, and people seem to have been happy with that for a
> while, why do we need i
Re: Bruce Momjian 2014-03-26 <20140326161056.ga...@momjian.us>
> The attached patch matches your suggestion. It is basically back to
> what the code originally had, except it skips system tables, and shows
> "???" for invalid values.
Fwiw, "make check-world" is currently broken:
build/c
On 03/27/2014 06:35 AM, Amit Kapila wrote:
Few new warnings have been introduced in windows build.
1>e:\workspace\postgresql\master\postgresql\src\backend\utils\adt\jsonb_util.c(802):
warning C4715: 'JsonbIteratorNext' : not all control paths return a
value
1>e:\workspace\postgresql\master\post
Hi Horiguchi-san,
(2014/03/27 17:09), Kyotaro HORIGUCHI wrote:
analyze.c: In function ‘acquire_inherited_sample_rows’:
analyze.c:1461: warning: unused variable ‘saved_rel’
>>
>> I've fixed this in the latest version (v8) of the patch.
>
> Mmm. sorry. I missed v8 patch. Then I had a look
On Thu, Mar 27, 2014 at 9:12 AM, Rajeev rastogi
wrote:
> As per the documentation, datistemplate of pg_database is used in
> following way:
>
>
>
> datistemplate
>
> Bool
>
> If true then this database can be used in the TEMPLATE clause of CREATE
> DATABASE to create a new database as a clone of
As per the documentation, datistemplate of pg_database is used in following way:
datistemplate
Bool
If true then this database can be used in the TEMPLATE clause of CREATE
DATABASE to create a new database as a clone of this one
But current code does not behave in this manner. Even if dbiste
Hello,
> >> analyze.c: In function ‘acquire_inherited_sample_rows’:
> >> analyze.c:1461: warning: unused variable ‘saved_rel’
>
> I've fixed this in the latest version (v8) of the patch.
Mmm. sorry. I missed v8 patch. Then I had a look on that and have
a question.
You've added a check for relki
60 matches
Mail list logo
