Oops! I found a bug in this patch. The previous v8 patch missed
the case that build_index_pathkeys() could build a partial
pathkeys from the index tlist.
This causes the situation follows,
===
=# \d cu11
Table "public.cu11"
Column | Type | Modifiers
+-+---
a
On Mon, Mar 10, 2014 at 4:24 PM, Amit Kapila wrote:
>
> On Mon, Mar 10, 2014 at 5:58 AM, Wang, Jing wrote:
> > Enclosed is the patch to implement the requirement that issue log message to
> > suggest VACUUM FULL if a table is nearly empty.
> >
> > The requirement comes from the Postgresql TODO li
Hello. As a minimal implementation, I made an attempt that emit
NOTICE message when alter table affects foreign tables. It looks
like following,
| =# alter table passwd add column added int, add column added2 int;
| NOTICE: This command affects foreign relation "cf1"
| NOTICE: This command affec
Peter Eisentraut writes:
> Aside from those details, it seems clear that any reasonably complete
> move-extensions-elsewhere feature will need some kind of build system
> support. I have various ideas on that and would gladly contribute some
> of them, but it's not going to happen within two week
From: "Amit Kapila"
If I understand correctly that objection was on changing Default Event
Source name, and the patch now doesn't contain that change, it's
just a bug fix for letting pg_ctl know the non-default event source
set by user.
Please clarify if I misunderstood something, else this sho
On 03/08/2014 01:56 AM, Tom Lane wrote:
> Craig Ringer writes:
>> What I'm concerned about is the locking. It looks to me like we're
>> causing the user to lock rows that they may not intend to lock, by
>> applying a LockRows step *before* the user supplied qual. (I'm going to
>> test that tomorro
On Mon, Mar 10, 2014 at 1:18 PM, Peter Geoghegan wrote:
> * The jsonb_hash_ops non-default GIN opclass is broken. It has its own
> idiosyncratic notion of what constitutes containment, that sees it
> only return, say, jsonb arrays that have a matching string as their
> "leftmost" element (if we a
Hi,
Arrangements have been made to hold a meeting between database and kernel
developers at Collaboration Summit 2014 http://sched.co/1hEBRuq on March
27th 2014. This was organised after discussions on pain points encountered
by the PostgreSQL community. Originally the plan had been to just have a
On Mon, Mar 10, 2014 at 3:00 AM, Alexander Korotkov
wrote:
> I din't get comment about "leftmost" element. There is absolutely no
> distinguish between array elements. All elements are extracted into same
> keys independent of their indexes. It seems to have no change since I wrote
> hstore_hash_o
On Mon, Mar 10, 2014 at 3:19 AM, Peter Geoghegan wrote:
> I don't have time to post that at the moment, but offhand I *think*
> your confusion may be due to the fact that the json_hash_ops opclass
> (as I call it) was previously consistent with the behavior of the
> other GIN opclass (the default)
On Mon, Mar 10, 2014 at 3:21 AM, Peter Geoghegan wrote:
> Sorry, I realize now that that must be incorrect. Still, please take a
> look at the commit linked to.
To be clear, I mean that my explanation of why this was missed before
was incorrect, not my contention that it's a problem right now (fo
On Mon, Mar 10, 2014 at 2:19 PM, Peter Geoghegan wrote:
> On Mon, Mar 10, 2014 at 3:00 AM, Alexander Korotkov
> wrote:
> > I din't get comment about "leftmost" element. There is absolutely no
> > distinguish between array elements. All elements are extracted into same
> > keys independent of the
On Mon, Mar 10, 2014 at 3:47 AM, Alexander Korotkov
wrote:
> Fix is attached.
Could you post a patch with regression tests, please?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
On Mon, Mar 10, 2014 at 3:04 PM, Peter Geoghegan wrote:
> On Mon, Mar 10, 2014 at 3:47 AM, Alexander Korotkov
> wrote:
> > Fix is attached.
>
> Could you post a patch with regression tests, please?
>
Here it is.
--
With best regards,
Alexander Korotkov.
jsonb-hash-ops-fix-2.patch
Descrip
Hi,
thanks for the continued review.
On 09/03/14 12:15, Amit Kapila wrote:
> 1.
> "> ISTM that you should be printing just the value and the unique index
> > there, and not any information about the tuple proper.
>
> Good point, I will have a look at this."
>
> This point is still not handled i
Hi all,
I have been playing a bit with the replication slots, and I noticed a
weird behavior in such a scenario:
1) Create a master/slave cluster, and have slave use a replication slot
2) Stop the master
3) Create a certain amount of WAL, during my tests I played with 4~5GB of WAL
4) Restart the s
On 10 March 2014 03:36, Craig Ringer wrote:
> I've found an issue with updatable security barrier views. Locking is
> being pushed down into the subquery. Locking is thus applied before
> user-supplied quals are, so we potentially lock too many rows.
>
> I'm looking into the code now, but in the m
Hi,
On 2014-03-10 21:06:53 +0900, Michael Paquier wrote:
> I have been playing a bit with the replication slots, and I noticed a
> weird behavior in such a scenario:
> 1) Create a master/slave cluster, and have slave use a replication slot
> 2) Stop the master
> 3) Create a certain amount of WAL,
On Mon, Mar 10, 2014 at 9:24 PM, Andres Freund wrote:
> Hi,
>
> On 2014-03-10 21:06:53 +0900, Michael Paquier wrote:
>> I have been playing a bit with the replication slots, and I noticed a
>> weird behavior in such a scenario:
>> 1) Create a master/slave cluster, and have slave use a replication
Hello
I had to migrate our databases from 9.1 to 9.2. We have high number of
databases per cluster (more than 1000) and high number of tables (indexes)
per database (sometimes more than 10K, exceptionally more than 100K).
I seen two problems:
a) too long files pg_upgrade_dump_db.sql, pg_upgrade_
On Fri, Mar 7, 2014 at 2:40 PM, Robert Haas wrote:
>> The big picture here is that in the scenario being debated in the other
>> thread, exit() in a child process forked from a backend will execute that
>> backend's on_detach actions *even if the code had done on_exit_reset after
>> the fork*.
>
>
On Tue, Mar 4, 2014 at 4:13 PM, Heikki Linnakangas
wrote:
> Agreed. Amit, do you have the test setup at hand, can you check the
> performance of this one more time?
Are you expecting more performance numbers than I have posted?
Is there anything more left for patch which you are expecting?
With
Robert Berry writes:
> I'm looking at doing a calculation to determine the number of free buffers
> available. A n example ratio that is based on some data structures in
> freelist.c as follows:
> (StrategyControl->lastFreeBuffer - StrategyControl->firstFreeBuffer) /
> (double) NBuffers
> Is th
Tomonari Katsumata writes:
> Adding FATAL and PANIC to client_min_messages is done at below-commit.
> 8ac386226d76b29a9f54c26b157e04e9b8368606
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=8ac386226d76b29a9f54c26b157e04e9b8368606
> According to the commit log, it seems that the
On Sat, Feb 8, 2014 at 2:31 AM, Amit Kapila wrote:
>> On Thu, Feb 6, 2014 at 3:42 PM, Kyotaro HORIGUCHI
>> wrote:
>>> Hello, I've understood how this works and seems working as
>>> expected.
>>>
>>>
>>> The orphan section handles on postmaster have become a matter of
>>> documentation.
>
> I had
On 03/10/2014 05:18 AM, Peter Geoghegan wrote:
On Fri, Mar 7, 2014 at 9:00 AM, Bruce Momjian wrote:
OK, it sounds like the adjustments are minimal, like not using the
high-order bit.
Attached patch is a refinement of the work of Oleg, Teodor and Andrew.
Revisions are mostly my own, although A
Robert Haas writes:
> On Fri, Mar 7, 2014 at 2:40 PM, Robert Haas wrote:
>> Hmm. So the problematic sequence of events is where a postmaster
>> child forks, and then exits without exec-ing, perhaps because e.g.
>> exec fails?
> I've attempted a fix for this case. The attached patch makes
> tes
Hi
2014-03-10 23:45 GMT+09:00 Tom Lane :
> Tomonari Katsumata writes:
> > Adding FATAL and PANIC to client_min_messages is done at below-commit.
> > 8ac386226d76b29a9f54c26b157e04e9b8368606
> >
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=8ac386226d76b29a9f54c26b157e04e9b83686
On Mon, Mar 10, 2014 at 8:18 PM, Robert Haas wrote:
> I took a look at this patch. It seems to me that it doesn't do a very
> good job maintaining the abstraction boundary between what the dsm.c
> layer knows about and what the dsm_impl.c layer knows about. However,
> AFAICS, these problems are
On Mon, Mar 10, 2014 at 9:48 PM, Amit Kapila wrote:
> On Mon, Mar 10, 2014 at 8:18 PM, Robert Haas wrote:
>> I took a look at this patch. It seems to me that it doesn't do a very
>> good job maintaining the abstraction boundary between what the dsm.c
>> layer knows about and what the dsm_impl.c
On Mon, Mar 10, 2014 at 6:58 AM, Pavel Stehule wrote:
> Hello
>
> I had to migrate our databases from 9.1 to 9.2. We have high number of
> databases per cluster (more than 1000) and high number of tables (indexes)
> per database (sometimes more than 10K, exceptionally more than 100K).
>
> I seen t
On Mon, Mar 10, 2014 at 12:44 PM, Amit Kapila wrote:
> On Mon, Mar 10, 2014 at 9:48 PM, Amit Kapila wrote:
>> On Mon, Mar 10, 2014 at 8:18 PM, Robert Haas wrote:
>>> I took a look at this patch. It seems to me that it doesn't do a very
>>> good job maintaining the abstraction boundary between w
Rajeev rastogi writes:
> On 12th December 2013, Rajeev Rastogi Wrote:
>> On 9th December, Amit Khandelkar wrote:
>>> But copystream can be different than pset.cur_cmd_source , right ?
>> As per the earlier code, condition result was always true. So pset.lineno
>> was always incremented.
>> In th
On Mon, Mar 10, 2014 at 09:54:36AM -0700, Jeff Janes wrote:
> On Mon, Mar 10, 2014 at 6:58 AM, Pavel Stehule
> wrote:
>
> Hello
>
> I had to migrate our databases from 9.1 to 9.2. We have high number of
> databases per cluster (more than 1000) and high number of tables (indexes)
>
> >
> > There were several bottlenecks in this area removed in 9.2 and 9.3.
> > Unfortunately the worst of those bottlenecks were in the server, so they
> depend
> > on what database you are upgrading from, and so won't help you much
> upgrading
> > from 9.1.
>
> Yes, I assume 9.3 will be much bett
On Fri, Mar 7, 2014 at 7:44 AM, Andres Freund wrote:
> I've attached a new version of the walsender patch. It's been rebased
> ontop of Heikki's latest commit to walsender.c. I've changed a fair bit
> of stuff:
> * The sleeptime is now computed to sleep until we either need to send a
> keepalive
On Mon, Mar 10, 2014 at 7:44 AM, Christian Kruse
wrote:
> [ response to review ]
This response seems to have made no mention of point #7 from Amit's
review, which seems to me to be a rather important one.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Fri, Mar 7, 2014 at 10:19 PM, Peter Eisentraut wrote:
>> What the $directory proposal achieves is allowing a fully relocatable
>> extension layout, where you just have to drop a directory anywhere in
>> the file system and it just works (*).
>
> If that's what you want (and it sounds attractive
On Mon, Mar 10, 2014 at 07:40:42PM +0100, Pavel Stehule wrote:
>
> >
> > There were several bottlenecks in this area removed in 9.2 and 9.3.
> > Unfortunately the worst of those bottlenecks were in the server, so they
> depend
> > on what database you are upgrading from, and so
2014-03-10 20:11 GMT+01:00 Bruce Momjian :
> On Mon, Mar 10, 2014 at 07:40:42PM +0100, Pavel Stehule wrote:
> >
> > >
> > > There were several bottlenecks in this area removed in 9.2 and 9.3.
> > > Unfortunately the worst of those bottlenecks were in the server,
> so they
> > depen
On Mon, Mar 10, 2014 at 11:48 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 7, 2014 at 2:40 PM, Robert Haas wrote:
>>> Hmm. So the problematic sequence of events is where a postmaster
>>> child forks, and then exits without exec-ing, perhaps because e.g.
>>> exec fails?
>
>> I've att
Robert Haas escribió:
> I've committed this patch now with a few further tweaks, leaving this
> issue unaddressed. It may well be something that needs improvement,
> but I don't think it's a big enough issue to justify holding back a
> commit.
Hmm, is the buildfarm exercising any of this?
--
Á
On Mon, Mar 10, 2014 at 3:33 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> I've committed this patch now with a few further tweaks, leaving this
>> issue unaddressed. It may well be something that needs improvement,
>> but I don't think it's a big enough issue to justify holding back a
>>
Hi,
On 2014-03-10 16:33:33 -0300, Alvaro Herrera wrote:
> Robert Haas escribió:
> > I've committed this patch now with a few further tweaks, leaving this
> > issue unaddressed. It may well be something that needs improvement,
> > but I don't think it's a big enough issue to justify holding back a
On 03/10/2014 11:54 AM, Robert Haas wrote:
> I've committed this patch now with a few further tweaks, leaving this
> issue unaddressed. It may well be something that needs improvement,
> but I don't think it's a big enough issue to justify holding back a
> commit.
Wait, does this mean Changesets
On 2014-03-10 12:38:42 -0700, Josh Berkus wrote:
> On 03/10/2014 11:54 AM, Robert Haas wrote:
> > I've committed this patch now with a few further tweaks, leaving this
> > issue unaddressed. It may well be something that needs improvement,
> > but I don't think it's a big enough issue to justify h
On Mon, Apr 30, 2012 at 1:34 PM, Noah Misch wrote:
> When GIN changes a metapage, we WAL-log its ex-header content and never use a
> backup block. This reduces WAL volume since the vast majority of the metapage
> is unused. However, ginRedoUpdateMetapage() only restores the WAL-logged
> content
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Mar 7, 2014 at 10:19 PM, Peter Eisentraut wrote:
> >> What the $directory proposal achieves is allowing a fully relocatable
> >> extension layout, where you just have to drop a directory anywhere in
> >> the file system and it just works (*).
On Mon, Mar 10, 2014 at 3:38 PM, Josh Berkus wrote:
> On 03/10/2014 11:54 AM, Robert Haas wrote:
>> I've committed this patch now with a few further tweaks, leaving this
>> issue unaddressed. It may well be something that needs improvement,
>> but I don't think it's a big enough issue to justify
I wrote:
> Also, I'm thinking we should back-patch the aspects of the patch
> needed to fix the wrong-line-number issue. That appears to have been
> introduced in 9.2; older versions of PG get the above example right.
I've done that. For reference' sake, here's an updated patch against
HEAD with
All students and mentors (and backup mentors) should now register to
this year's GSoC. Students only have until Friday next week (up until
21st March 19:00 UTC) to apply.
Thanks
Thom
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
Robert Haas escribió:
> A related point that's been bugging me for a while, and has just
> struck me again, is that background workers for which
> BGWORKER_SHMEM_ACCESS is not passed probably ought to be detaching
> shared memory (and DSMs). Currently, and since Alvaro originally
> added the faci
Thank you both for the thoughtful and helpful responses.
The utility of the length of the free list is somewhat dubious. I imagine
it could be useful to answer the question of "is there a chance that
increasing shared buffers would be useless?" in an optimization context.
Agreed it's not useful
On 03/10/2014 12:46 PM, Robert Haas wrote:
> On Mon, Mar 10, 2014 at 3:38 PM, Josh Berkus wrote:
>> On 03/10/2014 11:54 AM, Robert Haas wrote:
>>> I've committed this patch now with a few further tweaks, leaving this
>>> issue unaddressed. It may well be something that needs improvement,
>>> but
On Mon, Mar 10, 2014 at 4:55 PM, Josh Berkus wrote:
> On 03/10/2014 12:46 PM, Robert Haas wrote:
>> On Mon, Mar 10, 2014 at 3:38 PM, Josh Berkus wrote:
>>> On 03/10/2014 11:54 AM, Robert Haas wrote:
I've committed this patch now with a few further tweaks, leaving this
issue unaddressed.
Robert Haas escribió:
> On Mon, Mar 10, 2014 at 3:33 PM, Alvaro Herrera
> wrote:
> > Robert Haas escribió:
> >> I've committed this patch now with a few further tweaks, leaving this
> >> issue unaddressed. It may well be something that needs improvement,
> >> but I don't think it's a big enough i
On 03/10/2014 02:08 PM, Robert Haas wrote:
> On Mon, Mar 10, 2014 at 4:55 PM, Josh Berkus wrote:
>> Yeah, that's my thoughts. Although I might wait for recvlogical. Will
>> put documentation wordsmithing on my todo list once Andres commits.
>
> Is this your way of announcing that Andres is gett
Andres Freund wrote:
> On 2014-02-16 21:26:47 -0500, Robert Haas wrote:
>> I don't really know about cpu_tuple_cost. Kevin's often
>> advocated raising it, but I haven't heard anyone else advocate
>> for that. I think we need data points from more people to know
>> whether or not that's a good i
Hi,
On 10/03/14 14:59, Robert Haas wrote:
> On Mon, Mar 10, 2014 at 7:44 AM, Christian Kruse
> wrote:
> > [ response to review ]
>
> This response seems to have made no mention of point #7 from Amit's
> review, which seems to me to be a rather important one.
Just didn't notice it because the pr
On 03/10/2014 03:16 PM, Kevin Grittner wrote:
> I only have anecdotal evidence, though. I have seen it help dozens
> of times, and have yet to see it hurt. That said, most people on
> this list are probably capable of engineering a benchmark which
> will show whichever result they would prefer.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am probably missing something obvious, but why does the
AccessShareLock remain held on a table after a SELECT statement is
complete when in a transaction block? E.g.:
8<-
create table t1 ();
begin;
select * from t1;
select re
On 03/10/2014 10:50 AM, Andrew Dunstan wrote:
Thanks for your work on this.
It's just occurred to me that we'll need to add hstore_to_jsonb
functions and a cast to match the hstore_to_json functions and cast.
That should be fairly simple - I'll work on that. It need not hold up
progress wi
Gurjeet Singh wrote:
> On Tue, Nov 26, 2013 at 12:37 PM, Tom Lane wrote:
>
> > Gurjeet Singh writes:
> > > I was looking for ways to reduce the noise in Postgres make output,
> > > specifically, I wanted to eliminate the "Nothing to be done for `all' "
> > > messages, since they don't add much v
On Mon, Mar 10, 2014 at 08:12:20PM +0100, Pavel Stehule wrote:
> Remember pg_upgrade is using pg_dump, which then connecting to a
> backend, so passing that super-lock mode there is not ideal. The fixes
> in 9.3 improve locking in all user cases, not just upgrades.
>
>
>
> nice
FYI
On Mon, Mar 10, 2014 at 4:19 AM, Alexander Korotkov
wrote:
> Here it is.
So it looks like what you have here is analogous to the other problems
that I fixed with both GiST and GIN. That isn't surprising, and this
does fix my test-case. I'm not terribly happy about the lack of
explanation for the
Fabrízio de Royes Mello escribió:
> On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera
> wrote:
>
> > I am reworking this patch, both to accomodate earlier review comments
> > and to fix the multiple verify step of namespaces, as noted by Tom in
> > 4530.1390023...@sss.pgh.pa.us
> >
> Alvaro,
>
> Do
On Mon, Mar 10, 2014 at 11:37 PM, Robert Haas wrote:
> Looks good, committed. However, I changed it so that
> dsm_keep_segment() does not also perform the equivalent of
> dsm_keep_mapping(); those are two separate operations.
So are you expecting that if some one needs to retain dynamic segment'
On Mon, Mar 10, 2014 at 2:39 PM, MauMau wrote:
> From: "Amit Kapila"
>
>>> If I understand correctly that objection was on changing Default Event
>>> Source name, and the patch now doesn't contain that change, it's
>>> just a bug fix for letting pg_ctl know the non-default event source
>>> set by
Joe Conway writes:
> I am probably missing something obvious, but why does the
> AccessShareLock remain held on a table after a SELECT statement is
> complete when in a transaction block?
*Any* lock acquired by user command is held till end of transaction;
AccessShareLock isn't special.
In gener
On Mon, Mar 10, 2014 at 1:13 PM, Haribabu Kommi
wrote:
> On Mon, Mar 10, 2014 at 4:24 PM, Amit Kapila wrote:
>> On Mon, Mar 10, 2014 at 5:58 AM, Wang, Jing
>> wrote:
>> > Enclosed is the patch to implement the requirement that issue log message
>> > to
>> > suggest VACUUM FULL if a table is ne
Hi,
Can someone confirm is this really an issue? or any reasons for missing
rows?
On Tue, Feb 25, 2014 at 3:51 PM, Prakash Itnal wrote:
> Hi,
>
> Recently we observed below errors while taking dump after upgrading from
> 9.0.13 to 9.1.9.
>
> pg_dump: schema with OID 0 does not exist
>
> I refe
(2014/03/09 1:49), Fabien COELHO wrote:
Hello Mitsumasa-san,
New "\setrandom" interface is here.
\setrandom var min max [gaussian threshold | exponential threshold]
Attached patch realizes this interface, but it has little bit ugly codeing in
executeStatement() and process_commands()..
I
Hello,
> This seems far better than silently performing the command,
> except for the duplicated message:( New bitmap might required to
> avoid the duplication..
I rewrote it in more tidy way. ATController collects all affected
tables on ATRewriteCatalogs as first stage, then emit NOTICE
message
(2014/03/11 14:07), Kyotaro HORIGUCHI wrote:
This seems far better than silently performing the command,
except for the duplicated message:( New bitmap might required to
avoid the duplication..
I rewrote it in more tidy way. ATController collects all affected
tables on ATRewriteCatalogs as firs
74 matches
Mail list logo
