On 10/23/2013 03:05 AM, Noah Misch wrote:
I would vote for choosing the standard we want vsnprintf() to follow (probably
C99) and substituting a conforming implementation wherever "configure" detects
that libc does not conform. We'll be shipping some replacement vsnprintf() in
any case; we may
On Tue, Oct 22, 2013 at 3:04 AM, Piotr Marcinczyk wrote:
> Hi,
>
> I would like to implement item from TODO marked as easy: "Add \i option
> to bring in the specified file as a quoted literal". I understand intent
> of this item, to be able to have parts of query written in separate
> files (now i
On Wed, Oct 23, 2013 at 7:05 AM, KONDO Mitsumasa
wrote:
> (2013/10/22 12:52), Fujii Masao wrote:
>>
>> On Tue, Oct 22, 2013 at 12:47 PM, Amit Kapila
>> wrote:
>>>
>>> On Mon, Oct 21, 2013 at 4:40 PM, KONDO Mitsumasa
>>> wrote:
(2013/10/19 14:58), Amit Kapila wrote:
>
> On Tue,
Hi All,
(2013/10/22 22:26), Stephen Frost wrote:
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
In our case, what I keep experiencing with tuning queries is that we
have like 99% of them running under acceptable threshold and 1% of them
taking more and more time.
This is usually described
initdb.c quoth:
* ... but the fact that a platform has shm_open
* doesn't guarantee that that call will succeed when attempted.
Indeed:
$ initdb
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will
Noah Misch writes:
> On Tue, Oct 22, 2013 at 11:00:42AM -0400, Tom Lane wrote:
>> Yeah. As a separate matter, it might be useful to revise stringinfo.c
>> and the asprintf code so that *if* the returned value is larger than the
>> given buffer size, we use it as a guide to resizing, avoiding the
On Mon, Oct 14, 2013 at 5:38 PM, Josh Kupershmidt wrote:
> Also, Pavel, this patch is still listed as 'Needs Review' in the CF
> app, but I haven't seen a response to the concerns in my last message.
It looks like this patch has been imported into the 2013-11 CF [1] and
marked "Needs Review". I l
(2013/10/22 12:52), Fujii Masao wrote:
On Tue, Oct 22, 2013 at 12:47 PM, Amit Kapila wrote:
On Mon, Oct 21, 2013 at 4:40 PM, KONDO Mitsumasa
wrote:
(2013/10/19 14:58), Amit Kapila wrote:
On Tue, Oct 15, 2013 at 11:41 AM, KONDO Mitsumasa
wrote:
In general, my thinking is that we should prefe
On 2013-10-23 03:18:55 +0200, Andres Freund wrote:
> (000[1-4])
Attached.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
>From bf329af4eb6d839ae2a75c4f8a2d6867877510f4 Mon Sep 17 00:00:00 200
Hi,
Using the same debugging hack^Wpatch (0001) as in the matview patch
(0002) an hour or so ago I noticed that INSERT INTO view WITH CHECK
doesn't lock the underlying relations properly.
I've attached a sort-of-working (0003) hack but I really doubt it's the
correct approach, I don't really know
On Tue, Oct 22, 2013 at 11:00:42AM -0400, Tom Lane wrote:
> Yeah. As a separate matter, it might be useful to revise stringinfo.c
> and the asprintf code so that *if* the returned value is larger than the
> given buffer size, we use it as a guide to resizing, avoiding the possible
> need to loop m
Hi,
In an postgres build that has added instrumentation to detect cases
where indexes are index_open()ed without any locks on the underlying
relation, the matview code started to cry during the regression tests.
The problem seems to be that refresh_matview_datafill() uses
QueryRewrite() without p
Hi,
There has been some interest in keeping track of timestamp of
transaction commits. This patch implements that.
There are some seemingly curious choices here. First, this module can
be disabled, and in fact it's turned off by default. At startup, we
verify whether it's enabled, and create t
I wrote:
> Stephen Frost writes:
>> I agree that exit/Assert-or-elog is the right API here. I wonder if
>> it'd be reasonable or worthwhile to try and actually make that happen-
>> that is to say, we really do only have one implementation for both
>> front-end and back-end here, but on the front-
On 2013-10-22 16:38:05 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-10-22 15:24:40 -0400, Tom Lane wrote:
> >> No, that's hardly a good idea. As Heikki says, that would amount to
> >> converting an entirely foreseeable situation into a PANIC.
>
> > But IIUC this can currently lead
On Tue, Oct 22, 2013 at 2:38 PM, Joshua D. Drake wrote:
>
> On 10/21/2013 08:11 AM, Robert Haas wrote:
>
>> Supposedly, we have a policy that for each patch you submit, you ought
>> to review a patch. That right there ought to provide enough reviewers
>> for all the patches, but clearly it didn't
Andres Freund writes:
> On 2013-10-22 15:24:40 -0400, Tom Lane wrote:
>> No, that's hardly a good idea. As Heikki says, that would amount to
>> converting an entirely foreseeable situation into a PANIC.
> But IIUC this can currently lead to an index giving wrong answers, not
> "just" fail at fur
Alvaro Herrera writes:
> Tom Lane wrote:
>> ... BTW, another reason to choose identical APIs for frontend and backend
>> versions of these functions is that it greatly eases use of them in shared
>> frontend/backend code. As I notice somebody has *already done* in
>> common/relpath.c. I'm not e
On 2013-10-22 15:24:40 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-10-22 21:29:13 +0300, Heikki Linnakangas wrote:
> >> We could put a critical section around the whole recursion that inserts the
> >> downlinks, so that you would get a PANIC and the incomplete split mechanism
> >> w
Tom Lane wrote:
> ... BTW, another reason to choose identical APIs for frontend and backend
> versions of these functions is that it greatly eases use of them in shared
> frontend/backend code. As I notice somebody has *already done* in
> common/relpath.c. I'm not exactly sure how those psprintf
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> ... BTW, another reason to choose identical APIs for frontend and backend
> versions of these functions is that it greatly eases use of them in shared
> frontend/backend code. As I notice somebody has *already done* in
> common/relpath.c. I'm not exactly
... BTW, another reason to choose identical APIs for frontend and backend
versions of these functions is that it greatly eases use of them in shared
frontend/backend code. As I notice somebody has *already done* in
common/relpath.c. I'm not exactly sure how those psprintf calls are
working at al
On 10/21/2013 08:11 AM, Robert Haas wrote:
Supposedly, we have a policy that for each patch you submit, you ought
to review a patch. That right there ought to provide enough reviewers
for all the patches, but clearly it didn't. And I'm pretty sure that
some people (like me) looked at a lot MO
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> In some cases the other solution is "we need to search for a better
> solution". But if you say "the proposed solution is bad" without even
> proposing criteria for a better solution, then you are *de facto* saying
> that the problem isn't importan
On 22.10.2013 22:24, Tom Lane wrote:
I wonder whether Heikki's approach could be used to remove the need for
the incomplete-split-fixup code altogether, thus eliminating a class of
recovery failure possibilities.
Yes. I intend to do that, too.
- Heikki
--
Sent via pgsql-hackers mailing list
On 10/21/2013 11:59 AM, Tom Lane wrote:
> Josh Berkus writes:
>> Either you're proposing a solution, supporting someone else's solution,
>> or you're saying the problem isn't important. There is no fourth
>> alternative.
>
> Nonsense. Pointing out that a proposed solution isn't workable is not
Josh Berkus writes:
> pg_partman has several external (python) scripts which help the
> extension, located in /extras/ in its source. The problem currently is
> that if you install pg_partman via pgxn or package, you don't get those
> scripts, because there's no "install" location for them.
See
Andres Freund writes:
> On 2013-10-22 21:29:13 +0300, Heikki Linnakangas wrote:
>> We could put a critical section around the whole recursion that inserts the
>> downlinks, so that you would get a PANIC and the incomplete split mechanism
>> would fix it at recovery. But that would hardly be an imp
Stephen Frost writes:
> I agree that exit/Assert-or-elog is the right API here. I wonder if
> it'd be reasonable or worthwhile to try and actually make that happen-
> that is to say, we really do only have one implementation for both
> front-end and back-end here, but on the front-end we exit, wh
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Sounds reasonable, and I haven't got a better name, but I'm trying to
> > figure out why psprintf hasn't got the same issues which you mention in
> > your other thread (eg: depending on vsnprintf to return the "would-be"
> > result
On 2013-10-22 21:29:13 +0300, Heikki Linnakangas wrote:
> On 22.10.2013 21:25, Andres Freund wrote:
> >On 2013-10-22 19:55:09 +0300, Heikki Linnakangas wrote:
> >>Splitting a B-tree page is a two-stage process: First, the page is split,
> >>and then a downlink for the new right page is inserted int
On Mon, Oct 21, 2013 at 1:36 PM, Robert Haas wrote:
> On Mon, Oct 21, 2013 at 4:01 PM, Tom Lane wrote:
> > Gavin Flower writes:
> If we're going to extend pg_stat_statements, even more than min and
> max
> I'd like to see the standard deviation in execution time.
> >
> >> How about th
On 22.10.2013 21:25, Andres Freund wrote:
On 2013-10-22 19:55:09 +0300, Heikki Linnakangas wrote:
Splitting a B-tree page is a two-stage process: First, the page is split,
and then a downlink for the new right page is inserted into the parent
(which might recurse to split the parent page, too).
All,
pg_partman has several external (python) scripts which help the
extension, located in /extras/ in its source. The problem currently is
that if you install pg_partman via pgxn or package, you don't get those
scripts, because there's no "install" location for them.
Where should these go? PGS
On 2013-10-22 19:55:09 +0300, Heikki Linnakangas wrote:
> Splitting a B-tree page is a two-stage process: First, the page is split,
> and then a downlink for the new right page is inserted into the parent
> (which might recurse to split the parent page, too). What happens if
> inserting the downlin
Stephen Frost writes:
> Sounds reasonable, and I haven't got a better name, but I'm trying to
> figure out why psprintf hasn't got the same issues which you mention in
> your other thread (eg: depending on vsnprintf to return the "would-be"
> result size).
It does, though not directly in psprintf
On Mon, Oct 21, 2013 at 4:29 PM, Tom Lane wrote:
> Andrew Dunstan writes:
> > This is why I suggested the standard deviation, and why I find it would
> > be more useful than just min and max. A couple of outliers will set the
> > min and max to possibly extreme values but hardly perturb the stan
On 2013-10-22 13:57:53 -0400, Robert Haas wrote:
> On Tue, Oct 22, 2013 at 1:08 PM, Andres Freund wrote:
> >> That strikes me as a flaw in the implementation rather than the idea.
> >> You're presupposing a patch where the necessary information is
> >> available in WAL yet you don't make use of it
On Tue, Oct 22, 2013 at 1:08 PM, Andres Freund wrote:
>> It seems to me that you have to think of the CTID map as tied to a
>> relfilenode; if you try to use one relfilenode's map with a different
>> relfilenode, it's obviously not going to work. So don't do that.
>
> It has to be tied to relfile
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> In short, I want to change pg_asprintf to return the malloc'd buffer
> as its function result. This probably means we should change the
> function name too, since the allusion to asprintf is completely useless
> if we do that. I'm thinking pg_psprint
On Tue, Oct 22, 2013 at 10:30 AM, Heikki Linnakangas
wrote:
> I may be missing something, but there are already plenty of b-tree specific
> flags. See BTP_* in nbtree.h. I'll just add another to that list.
Based on your remarks, I thought that you were intent on directly
using page level bits (pd
On 22.10.2013 20:27, Peter Geoghegan wrote:
On Tue, Oct 22, 2013 at 9:55 AM, Heikki Linnakangas
wrote:
I propose that we use the same approach I used with GiST, and add a flag to
the page header to indicate "the downlink hasn't been inserted yet". When
insertion (or vacuum) bumps into a flagge
On Tue, Oct 22, 2013 at 9:55 AM, Heikki Linnakangas
wrote:
> I propose that we use the same approach I used with GiST, and add a flag to
> the page header to indicate "the downlink hasn't been inserted yet". When
> insertion (or vacuum) bumps into a flagged page, it can finish the
> incomplete act
On 2013-10-22 11:59:35 -0400, Robert Haas wrote:
> >> So I have a new idea for handling this problem, which seems obvious in
> >> retrospect. What if we make the VACUUM FULL or CLUSTER log the old
> >> CTID -> new CTID mappings? This would only need to be done for
> >> catalog tables, and maybe c
Splitting a B-tree page is a two-stage process: First, the page is
split, and then a downlink for the new right page is inserted into the
parent (which might recurse to split the parent page, too). What happens
if inserting the downlink fails for some reason? I tried that out, and
it turns out
On 2013-10-22 19:25:31 +0300, Heikki Linnakangas wrote:
> On 22.10.2013 19:23, Andres Freund wrote:
> >On 2013-10-22 19:19:19 +0300, Heikki Linnakangas wrote:
> >>On 22.10.2013 19:12, Andres Freund wrote:
> >>>On 2013-10-18 20:26:16 +0200, Andres Freund wrote:
> 4) Store both (cmin, cmax) for c
I wrote:
> I have a lot of other gripes about this whole patch, but they can
> wait till tomorrow.
The other big thing I don't like about this patch is that adopting
asprintf() as a model was not any better thought-out than the
portability considerations were. It's a bad choice because:
1. aspri
On Sun, Oct 20, 2013 at 1:37 AM, Noah Misch wrote:
>> > (2013/08/08 20:52), Vik Fearing wrote:
>> >> As part of routine maintenance monitoring, it is interesting for us to
>> >> have statistics on the CLUSTER command (timestamp of last run, and
>> >> number of runs since stat reset) like we have f
On Tue, Oct 22, 2013 at 12:25 PM, Heikki Linnakangas
wrote:
> Or just hand over a copy of the combocid map to the worker, along with the
> snapshot. Seems a lot simpler than this wide cids business..
Yes, that's what Noah and I talked about doing. Or possibly even
making the map into a hash tabl
On 22.10.2013 19:23, Andres Freund wrote:
On 2013-10-22 19:19:19 +0300, Heikki Linnakangas wrote:
On 22.10.2013 19:12, Andres Freund wrote:
On 2013-10-18 20:26:16 +0200, Andres Freund wrote:
4) Store both (cmin, cmax) for catalog tuples.
BTW: That would have the nice side-effect of deliverin
On 2013-10-22 19:19:19 +0300, Heikki Linnakangas wrote:
> On 22.10.2013 19:12, Andres Freund wrote:
> >On 2013-10-18 20:26:16 +0200, Andres Freund wrote:
> >>4) Store both (cmin, cmax) for catalog tuples.
> >
> >BTW: That would have the nice side-effect of delivering the basis of
> >what you need t
On 22.10.2013 19:12, Andres Freund wrote:
On 2013-10-18 20:26:16 +0200, Andres Freund wrote:
4) Store both (cmin, cmax) for catalog tuples.
BTW: That would have the nice side-effect of delivering the basis of
what you need to do parallel sort in a transaction that previously has
performed DDL.
On 2013-10-18 20:26:16 +0200, Andres Freund wrote:
> 4) Store both (cmin, cmax) for catalog tuples.
BTW: That would have the nice side-effect of delivering the basis of
what you need to do parallel sort in a transaction that previously has
performed DDL.
Currently you cannot do anything in parall
On Tue, Oct 22, 2013 at 11:02 AM, Andres Freund wrote:
> On 2013-10-22 10:52:48 -0400, Robert Haas wrote:
>> On Fri, Oct 18, 2013 at 2:26 PM, Andres Freund
>> wrote:
>> > So. As it turns out that solution isn't sufficient in the face of VACUUM
>> > FULL and mixed DML/DDL transaction that have no
On 21 October 2013 20:48, Robert Haas wrote:
>On Fri, Oct 18, 2013 at 7:37 AM, Rajeev rastogi
>wrote:
>> From the following mail, copy behaviour between stdin and normal file
>> having some inconsistency.
>>
>>
>> http://www.postgresql.org/message-id/ce85a517.4878e%tim.k...@gmail.com
>>
>>
>>
Manlio Perillo writes:
> On 22/10/2013 09:58, Tom Lane wrote:
>> 1. src/port/asprintf.c exhibits a truly touching faith that vsnprintf will
>> report exactly the number of bytes that would have been required, even if
>> the buffer is not that large. While this is what is specified in recent
>> ve
On 2013-10-22 10:52:48 -0400, Robert Haas wrote:
> On Fri, Oct 18, 2013 at 2:26 PM, Andres Freund wrote:
> > So. As it turns out that solution isn't sufficient in the face of VACUUM
> > FULL and mixed DML/DDL transaction that have not yet been decoded.
> >
> > To reiterate, as published it works l
On Tue, Oct 22, 2013 at 10:07 AM, Andres Freund wrote:
> On 2013-10-21 20:16:29 +0200, Andres Freund wrote:
>> On 2013-10-18 20:50:58 +0200, Andres Freund wrote:
>> > How about modifying the selection to go from:
>> > * all rows if ALTER TABLE ... REPLICA IDENTITY NOTHING|FULL;
>> > * index chosen
On Fri, Oct 18, 2013 at 2:26 PM, Andres Freund wrote:
> So. As it turns out that solution isn't sufficient in the face of VACUUM
> FULL and mixed DML/DDL transaction that have not yet been decoded.
>
> To reiterate, as published it works like:
> For every modification of catalog tuple (insert, mul
All,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> In our case, what I keep experiencing with tuning queries is that we
> have like 99% of them running under acceptable threshold and 1% of them
> taking more and more time.
This is usually described (at least where I come from) as 'rare eve
Hi Robert, Heikki,
On 2013-09-24 13:25:41 +0200, Andres Freund wrote:
> > I'm afraid this patch was a few bricks shy of a load. The
> > log_newpage_buffer() function asserts that:
> >
> > > /* We should be in a critical section. */
> > > Assert(CritSectionCount > 0);
> >
> > But the call in
On 22/10/13 22:56, Dimitri Fontaine wrote:
Tom Lane writes:
Hm. It's been a long time since college statistics, but doesn't the
entire concept of standard deviation depend on the assumption that the
underlying distribution is more-or-less normal (Gaussian)? Is there a
I just had a quick chat
Hello
here is patch
Regards
Pavel
2013/10/21 Noah Misch
> On Mon, Oct 21, 2013 at 08:10:24PM +0200, Pavel Stehule wrote:
> > > On 10/20/2013 07:52 PM, Noah Misch wrote:
> > >> Anything we do here effectively provides wrappers around the existing
> > >> functions tailored toward the needs of
On Tue, Oct 22, 2013 at 2:56 AM, Dimitri Fontaine
wrote:
> Tom Lane writes:
>> Hm. It's been a long time since college statistics, but doesn't the
>> entire concept of standard deviation depend on the assumption that the
>> underlying distribution is more-or-less normal (Gaussian)? Is there a
>
Tom Lane writes:
> Hm. It's been a long time since college statistics, but doesn't the
> entire concept of standard deviation depend on the assumption that the
> underlying distribution is more-or-less normal (Gaussian)? Is there a
I just had a quick chat with a statistician friends of mine on
Naman wrote:
> I have an 3 indexes on a relation t2(A,B,C) index1 , index2 ,index3
>
> What i need is if i know the indexname (say index1) then is their any
> programmatic way by which i can
> get the list of tuples which comes under the index specified( i.e index1)
Do you need anything that e
On 22/10/2013 09:58, Tom Lane wrote:
So I returned from vacation only to find that the buildfarm has a bad case
of acne. All the Windows members are red or pink, and have been for
awhile. Sigh.
After some research I believe that I understand the reason for the CHECK
failures, at least:
1. src
On 22 October 2013 10:15 Amit Kapila wrote:
>>On Mon, Oct 21, 2013 at 10:54 AM, Haribabu kommi
>>wrote:
>>
>> Yes, it's correct. "nkeep" counter have the dead tuples which are recently
>> dead and are not vacuumed. The removal of tuples vacuumed from dead tuples
>> should be the same as "nkeep"
On Tue, Oct 22, 2013 at 8:58 PM, Tom Lane wrote:
> So I returned from vacation only to find that the buildfarm has a bad case
> of acne. All the Windows members are red or pink, and have been for
> awhile. Sigh.
>
> After some research I believe that I understand the reason for the CHECK
> fail
So I returned from vacation only to find that the buildfarm has a bad case
of acne. All the Windows members are red or pink, and have been for
awhile. Sigh.
After some research I believe that I understand the reason for the CHECK
failures, at least:
1. src/port/asprintf.c exhibits a truly touch
On Tue, Oct 22, 2013 at 2:00 AM, Dimitri Fontaine wrote:
> Tom Lane writes:
> > I believe the reason GIST has compress/decompress functions is not for
> > TOAST (they predate that, if memory serves), but to allow the on-disk
> > representation of an index entry to be different from the data type'
On 2013-10-22 12:52:09 +0900, Fujii Masao wrote:
> So, our consensus is to introduce the hooks for FPW compression so that
> users can freely select their own best compression algorithm?
No, I don't think that's concensus yet. If you want to make it
configurable on that level you need to have:
1)
72 matches
Mail list logo
