On Sat, Dec 5, 2015 at 4:38 PM, Christian Ullrich wrote:
> I have zero experience with libxml2, so no idea if the previous context
> level can be turned on again. IMHO, the libxml2 change is a bug in itself;
> PostgreSQL's error messages are more readable with the XML text in them.
See here for e
Hello,
I just noticed that last night all built branches failed on my buildfarm
animal, jaguarundi. They all failed on the "xml" test, and the output is
essentially the same everywhere:
***
*** 9,16
LINE 1: INSERT INTO xmltest VALUES (3, ' SELECT xmlconcat('', NULL, 'stand
On Sat, Dec 5, 2015 at 2:30 AM, Robert Haas wrote:
>
> On Fri, Dec 4, 2015 at 12:50 PM, Tom Lane wrote:
> > So over in my private branch where I've been fooling around with upper
> > planner pathification, I've been sweating bullets to avoid enlarging the
> > size of struct Path, because I was aw
On Thu, Dec 03, 2015 at 07:03:21PM +0100, Andres Freund wrote:
> On 2015-12-03 04:38:45 -0500, Noah Misch wrote:
> > On Wed, Dec 02, 2015 at 04:46:26PM +0100, Andres Freund wrote:
> > > Especially if reverting and redoing includes conflicts that mainly
> > > increases the chance of accidental bugs.
On Fri, Dec 4, 2015 at 6:14 PM, Peter Geoghegan wrote:
> As frustrated as I've sometimes been with those discussions, I do
> recognize that there has to be a middle ground, and that the emphasis
> on distributed costs has as much to do with fairness for every
> contributor as anything else. I woul
On 12/4/15 5:14 PM, Peter Geoghegan wrote:
On Fri, Dec 4, 2015 at 2:44 PM, Jim Nasby wrote:
>I suspect Cachegrind[1] would answer a lot of these questions (though I've
>never actually used it). I can't get postgres to run under valgrind on my
>laptop, but maybe someone that's been successful at
On 12/04/15 12:56, Bruce Momjian wrote:
>
> OK, good logical reason to install dynloader.h on Windows.
Ah! Thanks. I was starting to wonder whether I had said something wrong
and been sent to the bit bucket within my first two -hackers posts. :)
> What do we need to do to close this item? Wha
On Fri, Dec 4, 2015 at 2:44 PM, Jim Nasby wrote:
> I suspect Cachegrind[1] would answer a lot of these questions (though I've
> never actually used it). I can't get postgres to run under valgrind on my
> laptop, but maybe someone that's been successful at valgrind can try
> cachegrind (It's just a
On 12/4/15 11:50 AM, Tom Lane wrote:
which means Robert has already blown the planner's space consumption out
by close to a factor of 2, and I should stop worrying. Or else he should
start worrying. Do we really need this field? Did anyone pay any
attention to what happened to planner space co
On Fri, 4 Dec 2015 21:55:23 +
Dann Corbit wrote:
> Using a Windows computer, editing the file:
> C:\WINDOWS\system32\drivers\etc\hosts
> the localhost entry was remapped to the machine name by adding the following
> line:
> 127.0.0.1
>
> After this change, Postgres would not allow ac
Using a Windows computer, editing the file:
C:\WINDOWS\system32\drivers\etc\hosts
the localhost entry was remapped to the machine name by adding the following
line:
127.0.0.1
After this change, Postgres would not allow access using the address localhost.
Only using the machine name to acce
On Sat, Dec 5, 2015 at 12:10 AM, Simon Riggs wrote:
> On 4 December 2015 at 13:47, Ildus Kurbangaliev
> wrote:
>
>>
>> Attached patch adds support of partial decompression for datums.
>> It will be useful in many cases when extracting part of data is
>> enough for big varlena structures.
>>
>> It
On Fri, Dec 4, 2015 at 12:50 PM, Tom Lane wrote:
> So over in my private branch where I've been fooling around with upper
> planner pathification, I've been sweating bullets to avoid enlarging the
> size of struct Path, because I was aware that common path types like
> IndexPath and AppendPath wer
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > Still, I'll get a patch worked up for it and then we can discuss the
> > merits of that patch going in to 9.5 now versus just into HEAD.
>
> Cool.
While working on the DROP OWNED BY patch, and part of what took me a bit
On Tue, Dec 1, 2015 at 10:20 PM, Etsuro Fujita
wrote:
> One thing I can think of is that we can keep both the structure of a
> ForeignPath node and the API of create_foreignscan_path as-is. The latter
> is a good thing for FDW authors. And IIUC the patch you posted today, I
> think we could make
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> If you're speaking of section 20.4, that text is all my fault ... but
>> I'm not clear on what you think needs to be added? The first DROP OWNED
>> BY will take care of any privileges on shared objects, so I didn't really
>> think
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I noticed in passing that the role removal documentation should really
> > also discuss shared objects (as the DROP OWNED BY reference page does).
>
> If you're speaking of section 20.4, that text is all my fault ... but
> I'm not
Stephen Frost writes:
> I noticed in passing that the role removal documentation should really
> also discuss shared objects (as the DROP OWNED BY reference page does).
If you're speaking of section 20.4, that text is all my fault ... but
I'm not clear on what you think needs to be added? The fi
Andres Freund writes:
> On 2015-12-04 12:50:09 -0500, Tom Lane wrote:
>> which means Robert has already blown the planner's space consumption out
>> by close to a factor of 2, and I should stop worrying.
> FWIW, for me it's still <= 64 bytes:
No, it's not bare Path I'm worried about, it's IndexP
On 2015-12-04 12:50:09 -0500, Tom Lane wrote:
> So over in my private branch where I've been fooling around with upper
> planner pathification, I've been sweating bullets to avoid enlarging the
> size of struct Path, because I was aware that common path types like
> IndexPath and AppendPath were al
So over in my private branch where I've been fooling around with upper
planner pathification, I've been sweating bullets to avoid enlarging the
size of struct Path, because I was aware that common path types like
IndexPath and AppendPath were already a power-of-2 size (at least on
64-bit machines),
On Sat, Nov 14, 2015 at 07:11:32PM -0500, Chapman Flack wrote:
> I use the PG dynloader because, hey, you guys have already done the work
> of abstracting up from 12 different platforms' variations on dlopen, and
> it seems smarter to stand on your shoulders and not reinvent that. The
> one minor q
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > Stephen Frost wrote:
> > >
> > > > The non-documentation question is around DROP OWNED. We need to either
> > > > have policies dropped by DROP OWNED (well, roles
Robert Haas writes:
> Still, maybe we should try to sneak at least this much into
> 9.5 RSN, because I have to think this is going to help people with
> mostly-NULL (or mostly-really-wide) columns.
Please no. We are trying to get to release, not destabilize things.
I think this is fine work for
On Tue, Dec 1, 2015 at 10:21 AM, Shulgin, Oleksandr
wrote:
> Hi Hackers!
>
> This post summarizes a few weeks of research of ANALYZE statistics
> distribution on one of our bigger production databases with some real-world
> data and proposes a patch to rectify some of the oddities observed.
>
>
>
On Fri, Dec 4, 2015 at 9:51 PM, Jeff Janes wrote:
> On Tue, Dec 1, 2015 at 10:40 AM, Masahiko Sawada
> wrote:
>> On Tue, Dec 1, 2015 at 3:04 AM, Jeff Janes wrote:
>>> On Mon, Nov 30, 2015 at 9:18 AM, Masahiko Sawada
>>> wrote:
On Sun, Nov 29, 2015 at 2:21 AM, Jeff Janes wrote:
> On
03.12.2015 04:03, Robert Haas пишет:
On Tue, Dec 1, 2015 at 7:53 AM, Anastasia Lubennikova
wrote:
If we don't need c4 as an index scankey, we don't need any btree opclass on
it.
But we still want to have it in covering index for queries like
SELECT c4 FROM tbl WHERE c1=1000; // uses the Inde
On 4 December 2015 at 15:50, Simon Riggs wrote:
> Do we think they ever launched a Saturn V that didn't have some marginal
> flashing lights somewhere?
>
Almost certainly. They had triple-redundant systems that were certified
for correctness. You don't knowingly send rockets into space with dub
Alvaro Herrera writes:
>> Hmm ... I would have supposed that this directory should have been
>> removed by File::Temp's END block. Are END blocks abandoned completely
>> when a signal is received? That seems pretty surprising.
> Yes, they are. Quoth man perlmod:
>An "END" code block i
Hi hackers,
We are developing and maintaining a Pacemaker resource agent for PostgreSQL
here. This agent is "stateful", ie. it knows where is the master and where are
the slaves. See [1]. Now that this resource agent version is close to what we
wanted to achieve, we will make some official announc
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Yesterday I was fooling around with the TAP tests, and at least once
> > I changed my mind and control-C'd out of a run. Today I find:
> >
> > [postgres@sss1 pgsql]$ git status
> > On branch master
> > Your branch is up-to-date with 'origin/master'.
> >
2015-12-04 17:34 GMT+01:00 Alvaro Herrera :
> Pavel Stehule wrote:
>
> > It should be disabled by default
> >
> > only when you have some problems, then you can enable it
>
> That still seems mostly unworkable to me. Are we going to tell DBAs to
> set PGOPTIONS when they have some pg_hba problem?
Tom Lane wrote:
> Yesterday I was fooling around with the TAP tests, and at least once
> I changed my mind and control-C'd out of a run. Today I find:
>
> [postgres@sss1 pgsql]$ git status
> On branch master
> Your branch is up-to-date with 'origin/master'.
>
> Untracked files:
> (use "git add
Hi,
On 2015-12-03 16:10:51 -0600, Kevin Grittner wrote:
> Is the c.h change above on anything resembling the right track for
> a patch for this? If not, what would such a patch look like?
I think a better path would be to add fallback support for 64bit atomics
- like we already have for 32bit. T
Pavel Stehule wrote:
> It should be disabled by default
>
> only when you have some problems, then you can enable it
That still seems mostly unworkable to me. Are we going to tell DBAs to
set PGOPTIONS when they have some pg_hba problem?
What's the issue with calling the function when you want
Haribabu Kommi wrote:
> How about as follows?
>
> postgres=# select * from pg_hba_lookup('all','all','::1');
> line_number | type | database | user | address | hostname | method |
> options | mode
> -+---+--+-+---+--++-+
2015-12-04 17:16 GMT+01:00 Alvaro Herrera :
> Haribabu Kommi wrote:
>
> > The trace messages that are going to print doesn't come to client until
> the
> > connection gets successful. The traces may not useful for the clients
> > to find out
> > why the connection is failing. But it may be useful
On Fri, Dec 4, 2015 at 3:47 PM, Robert Haas wrote:
> For the most part, the cleanups in this version are just cosmetic: I
> fixed some whitespace damage, and reverted some needless changes to
> the psql references page that were whitespace-only adjustments. In a
> few places, I tweaked documentat
On Tue, Dec 1, 2015 at 10:40 AM, Masahiko Sawada wrote:
> On Tue, Dec 1, 2015 at 3:04 AM, Jeff Janes wrote:
>> On Mon, Nov 30, 2015 at 9:18 AM, Masahiko Sawada
>> wrote:
>>> On Sun, Nov 29, 2015 at 2:21 AM, Jeff Janes wrote:
On Tue, Nov 24, 2015 at 3:13 PM, Masahiko Sawada
wrote:
>
Haribabu Kommi wrote:
> The trace messages that are going to print doesn't come to client until the
> connection gets successful. The traces may not useful for the clients
> to find out
> why the connection is failing. But it may be useful for administrators.
> How about the attached patch?
>
> [
Noah Misch wrote:
> git checkout 807b9e0
> (find src -name \*.pl -o -name \*.pm ) | sort -u | xargs perltidy
> --profile=src/tools/pgindent/perltidyrc
>
> perltidy v20090616 leaves the working directory clean, but perltidy v20150815
> introduces diffs:
>
> src/backend/catalog/genbki.pl
Yesterday I was fooling around with the TAP tests, and at least once
I changed my mind and control-C'd out of a run. Today I find:
[postgres@sss1 pgsql]$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add ..." to include in what will be c
Michael Paquier wrote:
> By the way, if there are no objections, I am going to mark this patch
> as committed in the CF app. Putting in the infrastructure is already a
> good step forward, and I will add an entry in next CF to track the
> patch to add tests for recovery itself. Alvaro, what do you
On 30 November 2015 at 17:52, Robert Haas wrote:
> My idea is that you'd end up with a plan like this:
>
> Gather
> -> Hash Join
> -> Parallel Seq Scan
> -> Parallel Hash
> -> Parallel Seq Scan
>
> Not only does this build only one copy of the hash table instead of N
> copies, but we can
Fujii Masao wrote:
> Sorry for not reviewing the patch before you push it...
>
> In HEAD, I ran very simple test case:
>
> 1. enable track_commit_timestamp
> 2. start the server
> 3. run some transactions
> 4. execute pg_last_committed_xact() -- returns non-null values
> 5. shutdown the server w
On 4 December 2015 at 16:29, Tom Lane wrote:
> Simon Riggs writes:
> > On 1 December 2015 at 17:05, Robert Haas wrote:
> >> do we want to
> >> back-patch those changes to 9.5 at this late date?
>
> > Surely the whole point of a release process is to fix issues in the
> > release. If we don't ev
Simon Riggs writes:
> On 1 December 2015 at 17:05, Robert Haas wrote:
>> do we want to
>> back-patch those changes to 9.5 at this late date?
> Surely the whole point of a release process is to fix issues in the
> release. If we don't ever dare put something in the release, we may as well
> have
Ashutosh Bapat writes:
> There's another seemingly wrong result, not with lateral, but with FOR
> UPDATE.
[ shrug... ] You're getting the post-update images of the two join
rows that would have been reported without FOR UPDATE. This one is
definitely not a bug.
regards,
Ashutosh Bapat writes:
> I am seeing different results with two queries which AFAIU have same
> semantics and hence are expected to give same results.
> postgres=# select * from t1, (select distinct val, val2 from t2) t2ss where
> t1.val = t2ss.val for update of t1;
> postgres=# select * from t
On 1 December 2015 at 17:05, Robert Haas wrote:
> do we want to
> back-patch those changes to 9.5 at this late date?
>
Surely the whole point of a release process is to fix issues in the
release. If we don't ever dare put something in the release, we may as well
have released it earlier.
I'm t
On 4 December 2015 at 13:47, Ildus Kurbangaliev <
i.kurbangal...@postgrespro.ru> wrote:
> Attached patch adds support of partial decompression for datums.
> It will be useful in many cases when extracting part of data is
> enough for big varlena structures.
>
> It is especially useful for expande
On Wed, Dec 2, 2015 at 4:06 AM, Andres Freund wrote:
> On 2015-12-02 08:52:20 +, Kouhei Kaigai wrote:
>> diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
>> index 26264cb..c4bb76e 100644
>> --- a/src/backend/nodes/copyfuncs.c
>> +++ b/src/backend/nodes/copyfuncs.c
>>
On Wed, Dec 2, 2015 at 12:33 AM, Pavel Stehule wrote:
>> Yeah, I don't think that's a big issue either to be honest. The code
>> is kept consistent a maximum with what is there previously.
>>
>> Patch is switched to ready for committer.
>
> perfect
>
> Thank you very much to all
I did some edits
On Tue, Nov 17, 2015 at 6:43 AM, Alvaro Herrera
wrote:
> I paraphrase Fujii Masao, who wrote:
>
>> 1. Start the master and standby servers with track_commit_timestamp enabled.
>> 2. Disable track_commit_timestamp in the master and restart the master
>> server.
>> 3. Run checkpoint in the master.
On Fri, Dec 4, 2015 at 6:35 AM, Greg Stark wrote:
> On Thu, Dec 3, 2015 at 10:10 PM, Kevin Grittner wrote:
>> Is the c.h change above on anything resembling the right track for
>> a patch for this? If not, what would such a patch look like?
>
> It would be nicer if we could come up with an inter
On Fri, 4 Dec 2015 22:13:58 +0900
Michael Paquier wrote:
> On Fri, Dec 4, 2015 at 9:47 PM, Ildus Kurbangaliev
> wrote:
> > Attached patch adds support of partial decompression for datums.
> > It will be useful in many cases when extracting part of data is
> > enough for big varlena structures.
>
Some inconsistency (if we believe that omitted lower bound is equal to 1):
regression=# insert into arrtest_s values
('[-1:9]={3,1,4,1,5,9,5,6,7,8,9}'::int[], null);
INSERT 0 1
regression=# UPDATE arrtest_s SET a[:2] = '{23, 24, 25}';
ERROR: source array too small
regression=# UPDATE arrtest_s
On 3 December 2015 at 20:39, Simon Riggs wrote:
> On 30 November 2015 at 17:20, Konstantin Knizhnik <
> k.knizh...@postgrespro.ru> wrote:
>
>
>> But looks like there is not so much sense in having multiple network
>> connection between one pair of nodes.
>> It seems to be better to have one conne
On Fri, Nov 6, 2015 at 11:27 AM, Kyotaro HORIGUCHI
wrote:
> Hello, thank you for the comments.
>
> The revised version of this patch is attached.
Thanks for updating the patch!
I tested whether the following patterns work as expected or not.
CREATE UNIQUE INDEX CONCURRENTLY name ON
CREATE UNIQU
On Fri, Dec 4, 2015 at 9:47 PM, Ildus Kurbangaliev
wrote:
> Attached patch adds support of partial decompression for datums.
> It will be useful in many cases when extracting part of data is
> enough for big varlena structures.
>
> It is especially useful for expanded datums, because it provides
>
On Fri, Dec 4, 2015 at 5:10 PM, Andres Freund wrote:
> On 2015-12-04 17:00:13 +0900, Michael Paquier wrote:
>> Andres Freud wrote:
>> >> extern void InitXLogInsert(void);
>> >> diff --git a/src/include/catalog/pg_control.h
>> >> b/src/include/catalog/pg_control.h
>> >> index ad1eb4b..91445f1 100
Attached patch adds support of partial decompression for datums.
It will be useful in many cases when extracting part of data is
enough for big varlena structures.
It is especially useful for expanded datums, because it provides
storage for partial results.
I have another patch, which removes the
On Thu, Dec 3, 2015 at 10:10 PM, Kevin Grittner wrote:
> Is the c.h change above on anything resembling the right track for
> a patch for this? If not, what would such a patch look like?
It would be nicer if we could come up with an interface that didn't
require #ifdefs everywhere it's used.
So
Hello all,
Current implementation of ResourceOwner uses arrays to store resources
like TupleDescs, Snapshots, etc. When we want to release one of these
resources ResourceOwner finds it with linear scan. Granted, resource
array are usually small so its not a problem most of the time. But it
appears
On December 4, 2015 9:48:55 AM GMT+01:00, Craig Ringer
wrote:
>On 3 December 2015 at 22:58, Amit Kapila
>wrote:
>
>> On Thu, Dec 3, 2015 at 9:02 AM, Craig Ringer
>> wrote:
>http://www.postgresql.org/message-id/CAA4eK1+=5Ex8-5NRr3u94=_t2p65v0kcjZ5rXddVmkx=lwa...@mail.gmail.com
>>
>Good point. I
2015-12-04 9:37 GMT+01:00 Kyotaro HORIGUCHI :
> Hello, I think this is the my last proposal of an idea on
> psql-side generic solution. Sorry for bothering.
>
> > My environment is CentOS7. But completely forgot Windows
> > environment (or other platforms). I agree with you. It will
> > indeed too
On 3 December 2015 at 22:58, Amit Kapila wrote:
> On Thu, Dec 3, 2015 at 9:02 AM, Craig Ringer
> wrote:
> >
> > On 3 December 2015 at 09:32, Peter Eisentraut wrote:
> >>
> >> On 12/2/15 7:00 PM, Craig Ringer wrote:
> >> > I notice that you don't set the 'waiting' flag. 'waiting' is
> presently
Hello, I think this is the my last proposal of an idea on
psql-side generic solution. Sorry for bothering.
> My environment is CentOS7. But completely forgot Windows
> environment (or other platforms). I agree with you. It will
> indeed too much considering all possible platforms.
Ok, DLL is not
On 2015-12-04 17:00:13 +0900, Michael Paquier wrote:
> Andres Freud wrote:
> >> @@ -450,14 +450,21 @@ ginbuildempty(PG_FUNCTION_ARGS)
> >> START_CRIT_SECTION();
> >> GinInitMetabuffer(MetaBuffer);
> >> MarkBufferDirty(MetaBuffer);
> >> - log_newpage_buffer(MetaBuffer, false);
On Thu, Dec 3, 2015 at 3:25 AM, Robert Haas wrote:
>
> On Tue, Dec 1, 2015 at 7:21 AM, Amit Kapila
wrote:
>
> > - There seems to be some inconsistency in Explain's output when
> > multiple workers are used.
>
>
> So the net result of this is that the times and row counts are
> *averages* across a
Andres Freud wrote:
> On 2015-11-20 16:11:15 +0900, Michael Paquier wrote:
>> diff --git a/src/backend/access/transam/xlog.c
>> b/src/backend/access/transam/xlog.c
>> index cc845d2..4883697 100644
>> --- a/src/backend/access/transam/xlog.c
>> +++ b/src/backend/access/transam/xlog.c
>> @@ -9503,6 +
71 matches
Mail list logo
