On Wed, Sep 7, 2016 at 7:26 PM, Victor Wagner wrote:
> No, algorithm here is more complicated. It must ensure that there would
> not be second attempt to connect to host, for which unsuccessful
> connection attempt was done. So, there is list rearrangement.
>Algorithm for pick
On Thu, Sep 8, 2016 at 7:21 PM, Tom Lane wrote:
> We could make it work like that without breaking the ABI if we were
> to add a NOERROR bit to the allowed "flags". However, after looking
> around a bit I'm no longer convinced what I said above is a good idea.
> In
Craig Ringer writes:
> On 9 September 2016 at 01:40, Roger Pack wrote:
>> Today's explain tells us what loops and scans were used, and relative
>> costs, etc. It doesn't seem to tell *why* the planner elected to use
>> what it did.
> One thing
Review of 0003-Define-logical-replication-protocol-and-output-plugi.patch:
(This is still based on the Aug 31 patch set, but at quick glance I
didn't see any significant changes in the Sep 8 set.)
Generally, this all seems mostly fine. Everything is encapsulated
well enough that problems are
Andres Freund writes:
> On 2016-09-08 20:15:46 -0400, Peter Eisentraut wrote:
>> We don't support build directories with spaces in them, but we support
>> installation directories with spaces in them. So I guess that means
>> your point is valid.
> Even if not necessary in
On 9 September 2016 at 10:37, Craig Ringer wrote:
> I'm looking at the revised patch now.
Considerably improved.
I fixed a typo from decondig to decoding that's throughout all the
callback names.
This test is wrong:
+while ((change =
Thank you for your attention to details, Mikhail.
pack_float_good() looks good. But I'm not sure inline strict init is allowed
under ansi C. Converting to regular ancient form b.fp = v; won't change compile
result, would it?
Regards, Andrey Borodin.
--
Sent via pgsql-hackers mailing list
On Thu, Sep 8, 2016 at 11:40 PM, Masahiko Sawada
wrote:
>
>
> Making the vacuum possible to choose between two data representations
> sounds good.
> I implemented the patch that changes dead tuple representation to bitmap
> before.
> I will measure the performance of
On Fri, Sep 9, 2016 at 12:39 AM, Jeff Janes wrote:
>
> I plan to do testing using my own testing harness after changing it to
> insert a lot of dummy tuples (ones with negative values in the pseudo-pk
> column, which are never queried by the core part of the harness) and
>
That storage assertion fired during usual update table set x=random() without
conditions. Also Make check fails without it (for brin usage, gist is ok with
it).
Cannot type quotation properly, I'm on a phone for a long time.
Regards, Andrey Borodin.
--
Sent via pgsql-hackers mailing list
On Thu, Sep 8, 2016 at 6:48 PM, Craig Ringer wrote:
> Pity ICU doesn't offer versioned collations within a single install.
> Though I can understand why they don't.
There are two separate issues with collator versioning. ICU can
probably be used in a way that clearly
On Fri, Sep 9, 2016 at 11:37 AM, Craig Ringer wrote:
> When writing TAP tests for Perl you must ensure you use only Perl
> 5.8.8-compatible code and only the core modules plus IPC::Run . You'll
> usually be fine if you just avoid importing things you don't see other
>
On 09/09/16 07:09, Jeff Janes wrote:
On Wed, Sep 7, 2016 at 3:29 AM, Ashutosh Sharma > wrote:
> Thanks to Ashutosh Sharma for doing the testing of the patch and
> helping me in analyzing some of the above issues.
Hi All,
I
On 9 September 2016 at 03:56, Vladimir Gordiychuk wrote:
>>It'd helpful if you summarize the changes made when posting revisions.
>
> Can we use as summary about changes first message?
I meant "what did you change between the last patch I posted and the
one you just posted" ?
On 9 September 2016 at 08:51, Tatsuo Ishii wrote:
>> On 9 September 2016 at 00:19, Peter Eisentraut
>> wrote:
>>> On 9/8/16 11:16 AM, Tom Lane wrote:
This is a problem, if ICU won't guarantee cross-version compatibility,
because it
On Thu, Jun 2, 2016 at 6:51 PM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello.
>
> After a process termination without PQfinish() of a client,
> server emits the following log message not seen on Linux boxes.
>
> > LOG: could not receive data from client: An existing
On 9 September 2016 at 01:40, Roger Pack wrote:
> My apologies if this was already requested before...
>
> I think it would be fantastic if postgres had an "explain the explain" option:
> Today's explain tells us what loops and scans were used, and relative
> costs, etc.
On 2016/09/08 21:38, Rajkumar Raghuwanshi wrote:
> On Wed, Sep 7, 2016 at 3:58 PM, Amit Langote wrote:
>> On 2016/09/07 17:56, Rajkumar Raghuwanshi wrote:
>>>
>>> In this case not sure how to create partition table. Do we have something
>>> like we have UNBOUNDED for range partition or oracle have
On Thu, Sep 8, 2016 at 6:26 PM, Masahiko Sawada wrote:
> "k (n1, n2, n3)" == "first k (n1, n2, n3)" doesn't break backward
> compatibility but most users would think "k(n1, n2, n3)" as quorum
> after introduced quorum.
> I wish we can change the s_s_names syntax of 9.6 to
On 2016-09-07 13:44:28 -0400, Tom Lane wrote:
> +
> +Installing Extensions using Update Scripts
> +
> +
> + An extension that has been around for awhile will probably exist in
Wanted to cry typo for 'awhile' here, but apparently that's actually a
word. The German in me is pleased.
Hi,
On 2016-09-07 09:46:32 -0400, Tom Lane wrote:
> At this point it's awfully tempting to make ALTER EXTENSION UPDATE grow
> a CASCADE option to allow automatic installation of new requirements
> of the new version, but I didn't do that here.
Sounds like a plan. After the refactoring that
> On 9 September 2016 at 00:19, Peter Eisentraut
> wrote:
>> On 9/8/16 11:16 AM, Tom Lane wrote:
>>> This is a problem, if ICU won't guarantee cross-version compatibility,
>>> because it destroys the argument that moving to ICU would offer us
>>> collation
On 2016-08-31 15:15:16 -0700, Peter Geoghegan wrote:
> On Wed, Aug 31, 2016 at 3:08 PM, Andres Freund wrote:
> > On August 31, 2016 3:06:23 PM PDT, Peter Geoghegan wrote:
> >
> >>In other painfully pedantic news, I should point out that
> >>sizeof(size_t)
On 2016-09-08 15:50:42 -0700, Andres Freund wrote:
> > Andres Freund writes:
> > > Am I missing something or is md.c:mdtruncate() leaking open files?
> Will fix.
And done.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 2016-09-08 20:15:46 -0400, Peter Eisentraut wrote:
> On 9/8/16 6:04 PM, Alvaro Herrera wrote:
> > Andres Freund wrote:
> >> On 2016-09-08 18:13:06 -0300, Alvaro Herrera wrote:
> >>> I suppose -I$(srcdir) should be fine. (Why the quotes?)
> >>
> >> Because quoting correctly seems like a good
On 9/8/16 6:04 PM, Alvaro Herrera wrote:
> Andres Freund wrote:
>> On 2016-09-08 18:13:06 -0300, Alvaro Herrera wrote:
>>> I suppose -I$(srcdir) should be fine. (Why the quotes?)
>>
>> Because quoting correctly seems like a good thing to do? Most people
>> won't have whitespace in there, but it
On 9 September 2016 at 00:19, Peter Eisentraut
wrote:
> On 9/8/16 11:16 AM, Tom Lane wrote:
>> This is a problem, if ICU won't guarantee cross-version compatibility,
>> because it destroys the argument that moving to ICU would offer us
>> collation behavior
On Thu, Sep 8, 2016 at 8:16 AM, Tom Lane wrote:
>> I understand that in principle, but I don't see operating system
>> providers shipping a bunch of ICU versions to facilitate that. They
>> will usually ship one.
>
> I agree with that estimate, and I would further venture
On 2016-09-07 23:37:31 +, Robins Tharakan wrote:
> If someone asks for I could provide SQL + EXPLAIN, but it feels irrelevant
> here.
Why is that? information_schema are normal sql queries, and some of them
far from trivial.
Andres
--
Sent via pgsql-hackers mailing list
On Wed, Sep 7, 2016 at 4:37 PM, Robins Tharakan wrote:
>
> Hi,
>
> An SQL (with only information_schema related JOINS) when triggered, runs
with max CPU (and never ends - killed after 2 days).
> - It runs similarly (very slow) on a replicated server that acts as a
read-only
On Thu, Sep 8, 2016 at 6:59 PM, Craig Ringer
wrote:
> On 9 Sep. 2016 03:45, "Corey Huinker" wrote:
> >
> >
>
> > Stylistically, would a separate .pl file for the emitter be preferable
> to something inline like
> >
> >> perl -e 'print
On 9 Sep. 2016 03:45, "Corey Huinker" wrote:
>
>
> Stylistically, would a separate .pl file for the emitter be preferable to
something inline like
>
>> perl -e 'print "a\tb\tcc\t4\n"; print "b\tc\tdd\t5\n"'
I'd be fine with that and a suitable comment. Just be careful
On 2016-09-08 18:39:56 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Am I missing something or is md.c:mdtruncate() leaking open files?
>
> Yeah, I think you're right.
>
> > This only really matters for VACUUM truncate and ON COMMIT TRUNCATE temp
> > table truncation
Andres Freund writes:
> Am I missing something or is md.c:mdtruncate() leaking open files?
Yeah, I think you're right.
> This only really matters for VACUUM truncate and ON COMMIT TRUNCATE temp
> table truncation afaics.
Also, you'd need a table > 1GB to leak anything at
Hi,
Am I missing something or is md.c:mdtruncate() leaking open files?
The relevant piece of code is:
if (priorblocks > nblocks)
{
/*
* This segment is no longer active (and has already
been unlinked
Tom,
Yes, it is what I mean. Is what pg_dump uses to get things synchronized. It
seems to me a clear marker that the same task is using more than one
connection to accomplish the one job.
Em 08/09/2016 6:34 PM, "Tom Lane" escreveu:
> Lucas writes:
> >
Andres Freund wrote:
> On 2016-09-08 18:13:06 -0300, Alvaro Herrera wrote:
> > I suppose -I$(srcdir) should be fine. (Why the quotes?)
>
> Because quoting correctly seems like a good thing to do? Most people
> won't have whitespace in there, but it doesn't seem impossible?
Well, I think they
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> That comment seems utterly wrong to me, because both PageIndexTupleDelete
> >> and PageIndexMultiDelete certainly contain assertions that every item on
> >> the page has storage. Are you expecting that
Alvaro Herrera writes:
> Tom Lane wrote:
>> That comment seems utterly wrong to me, because both PageIndexTupleDelete
>> and PageIndexMultiDelete certainly contain assertions that every item on
>> the page has storage. Are you expecting that any BRIN index items
>>
On Thu, Sep 8, 2016 at 2:19 PM, Peter Geoghegan wrote:
>> Peter, looking at your "displace" patch in this light, I think
>> tuplesort_heap_root_displace() and tuplesort_heap_delete_top() (as I'm
>> calling it now), should share a common subroutine. Displace replaces the top
>>
On 2016-09-08 18:13:06 -0300, Alvaro Herrera wrote:
> I suppose -I$(srcdir) should be fine. (Why the quotes?)
Because quoting correctly seems like a good thing to do? Most people
won't have whitespace in there, but it doesn't seem impossible?
> > check-world appears to mostly run (still doing
On Thu, Sep 8, 2016 at 2:09 PM, Tom Lane wrote:
> Well, my vote is that it ain't broke and we shouldn't fix it.
To take a step back, what prompted this whole discussion is the patch
that I wrote that shifts down, replacing calls to
tuplesort_heap_siftup() and
Lucas writes:
> The queue jumping logic can not use the distributed transaction id?
If we had such a thing as a distributed transaction id, maybe the
answer could be yes. We don't.
I did wonder whether using a shared snapshot might be a workable proxy
for that, but haven't
Tom Lane wrote:
> Hey Alvaro, can you comment on this bit in the proposed patch?
>
> + for (i = FirstOffsetNumber; i <= itemcount; i++)
> + {
> + ItemId ii = PageGetItemId(phdr, i);
> +
> + /* Normally here was following
Stephen Frost writes:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>> Can't you keep those words as Sconst or something (DefElems?) until the
>> execution phase, so that they don't need to be keywords at all?
> Seems like we could do that, though I'm not convinced
Hey Alvaro, can you comment on this bit in the proposed patch?
+ for (i = FirstOffsetNumber; i <= itemcount; i++)
+ {
+ ItemId ii = PageGetItemId(phdr, i);
+
+ /* Normally here was following assertion
+
Andres Freund wrote:
> On 2016-09-08 17:58:03 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> >
> > > ISTM that the easiest fix is to just tack -I '$(srcdir)' into the prove
> > > flags like:
> > > PROVE = @PROVE@
> > > PG_PROVE_FLAGS = -I $(top_srcdir)/src/test/perl/ -I '$(srcdir)'
> >
Peter Geoghegan writes:
> On Thu, Sep 8, 2016 at 1:14 PM, Andres Freund wrote:
>> Is this issue really worth keeping several hackers busy?
> I don't think it's fair to put it to me specifically that I'm doing
> that. That said, I would like to see this
On 2016-09-08 17:58:03 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > ISTM that the easiest fix is to just tack -I '$(srcdir)' into the prove
> > flags like:
> > PROVE = @PROVE@
> > PG_PROVE_FLAGS = -I $(top_srcdir)/src/test/perl/ -I '$(srcdir)'
> > PROVE_FLAGS = --verbose
> >
> > I
Andres Freund wrote:
> ISTM that the easiest fix is to just tack -I '$(srcdir)' into the prove
> flags like:
> PROVE = @PROVE@
> PG_PROVE_FLAGS = -I $(top_srcdir)/src/test/perl/ -I '$(srcdir)'
> PROVE_FLAGS = --verbose
>
> I don't think there's any security concerns for us here.
Maybe not, but
Hi,
On Debian unstable I just got a failure when running the regression
tests:
andres@alap4:~/build/postgres/dev-assert/vpath/src/bin/pg_rewind$ make check
rm -rf '/home/andres/build/postgres/dev-assert/vpath'/tmp_install
/bin/mkdir -p
While perusing the proposed PageIndexTupleOverwrite patch, I noticed
that PageIndexTupleDelete throws an error if size != MAXALIGN(size),
where "size" is the ItemIdGetLength value. This seems wrong now that
I look at it, because PageAddItem does not insist on tuple sizes being
maxaligned. It
I agree. It is an ugly hack.
But to me, the reduced window for failure is important. And that way an
failure will happen right away to be submitted to my operators as soon as
possible.
The queue jumping logic can not use the distributed transaction id?
On my logic, if a connection requests a
On Thu, Sep 8, 2016 at 1:14 PM, Andres Freund wrote:
> Is this issue really worth keeping several hackers busy?
I don't think it's fair to put it to me specifically that I'm doing
that. That said, I would like to see this resolved without further
bikeshedding.
--
Peter
Hi,
Is this issue really worth keeping several hackers busy?
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 8, 2016 at 12:46 PM, Tom Lane wrote:
>
> /*
> * The tuple at state->memtuples[0] has been removed from the heap.
> - * Decrement memtupcount, and sift up to maintain the heap invariant.
> + * Decrement memtupcount, and shift down to maintain the heap invariant.
On 9/3/16 2:41 PM, Vik Fearing wrote:
> On 08/31/2016 06:22 AM, Peter Eisentraut wrote:
>> Here is a patch that adds the notion of a data type to a sequence. So
>> it might be CREATE SEQUENCE foo AS integer. The types are restricted to
>> int{2,4,8} as now.
>
> This patch does not apply cleanly
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Stephen Frost (sfr...@snowman.net) wrote:
> > > Based on Robert's suggestion and using Thom's verbiage, I've tested this
> > > out:
> > >
> > > CREATE POLICY pol ON tab AS [PERMISSIVE|RESTRICTIVE] ...
>
>
>It'd helpful if you summarize the changes made when posting revisions.
Can we use as summary about changes first message? If not, summary can be
something like that:
This parches fix scenarios interrupt logical replication from client side
and allow the client to end a logical decoding session
Peter Geoghegan writes:
> Attached patch does it that way, then. I stuck with the reference to
> "shift down", though, since I think we all agree that that is
> unambiguous.
I dunno. What you've now got is
/*
* The tuple at state->memtuples[0] has been removed from the
On Tue, Sep 6, 2016 at 11:44 PM, Craig Ringer
wrote:
> On 7 September 2016 at 11:37, Corey Huinker
> wrote:
> > On Tue, Sep 6, 2016 at 11:24 PM, Craig Ringer <
> craig.rin...@2ndquadrant.com>
> > wrote:
> >>
> >> On 7 September 2016 at
Sift means shift up. There is no such thing as sift down, though, only
shift down. That is my understanding, based on the Wikipedia article on
heaps.
--
Peter Geoghegan
On Thu, Sep 8, 2016 at 4:20 PM, Peter Geoghegan wrote:
> On Thu, Sep 8, 2016 at 10:40 AM, Tom Lane wrote:
>>> On Thu, Sep 8, 2016 at 12:01 AM, Heikki Linnakangas wrote:
I still think tuplesort_heap_siftup is a confusing name, although
Stephen Frost wrote:
> Greetings!
>
> * Stephen Frost (sfr...@snowman.net) wrote:
> > Based on Robert's suggestion and using Thom's verbiage, I've tested this
> > out:
> >
> > CREATE POLICY pol ON tab AS [PERMISSIVE|RESTRICTIVE] ...
Can't you keep those words as Sconst or something (DefElems?)
Tom Lane wrote:
> Andrew Borodin writes:
> > Thank you for your corrections.
> > Here is the patch with suggestions taken into account, except 6th.
>
> I'll pick this up, unless some other committer is already on it.
>
> I think that we should buy back the addition of
On Thu, Sep 8, 2016 at 10:40 AM, Tom Lane wrote:
>> On Thu, Sep 8, 2016 at 12:01 AM, Heikki Linnakangas wrote:
>>> I still think tuplesort_heap_siftup is a confusing name, although I'm not
>>> sure that Peter's "compact" is much better. I suggest that we
Lucas writes:
> I made a small modification in pg_dump to prevent parallel backup failures
> due to exclusive lock requests made by other tasks.
> The modification I made take shared locks for each parallel backup worker
> at the very beginning of the job. That way, any other
All,
I have discovered a bug with the COPY command, specifically related to RLS.
The issue:
When running COPY as superuser on a table that has RLS enabled, RLS is
bypassed and therefore no issue exists. However, when performing a
COPY as a non-privileged user on the same table causes issues
On Wed, Sep 7, 2016 at 3:29 AM, Ashutosh Sharma
wrote:
> > Thanks to Ashutosh Sharma for doing the testing of the patch and
> > helping me in analyzing some of the above issues.
>
> Hi All,
>
> I would like to summarize the test-cases that i have executed for
> validating
On 09/06/2016 10:26 PM, Peter Geoghegan wrote:
On Tue, Sep 6, 2016 at 12:08 PM, Peter Geoghegan wrote:
Offhand, I would think that taken together this is very important. I'd
certainly want to see cases in the hundreds of megabytes or gigabytes
of work_mem alongside your 4MB
Andrew Borodin writes:
> Thank you for your corrections.
> Here is the patch with suggestions taken into account, except 6th.
I'll pick this up, unless some other committer is already on it.
I think that we should buy back the addition of PageIndexTupleOverwrite
to
Ildar> Could you please try the patch and tell if it works for you?
I've tested patch6 against recent head. The patch applies with no problems.
The previous case (filter on top of i-o-s) is fixed. Great work.
Here are the test cases and results:
People,
I made a small modification in pg_dump to prevent parallel backup failures
due to exclusive lock requests made by other tasks.
The modification I made take shared locks for each parallel backup worker
at the very beginning of the job. That way, any other job that attempts to
acquire
Greetings!
* Stephen Frost (sfr...@snowman.net) wrote:
> Based on Robert's suggestion and using Thom's verbiage, I've tested this
> out:
>
> CREATE POLICY pol ON tab AS [PERMISSIVE|RESTRICTIVE] ...
>
> and it appears to work fine with the grammar, etc.
>
> Unless there's other thoughts on
On Thu, Sep 8, 2016 at 11:54 PM, Pavan Deolasee
wrote:
>
>
> On Wed, Sep 7, 2016 at 10:18 PM, Claudio Freire
> wrote:
>>
>> On Wed, Sep 7, 2016 at 12:12 PM, Greg Stark wrote:
>> > On Wed, Sep 7, 2016 at 1:45 PM, Simon Riggs
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I happened to notice that if you type "make" in
> src/test/modules/test_pg_dump, you will get a "make check" action
> not "make all". I hope this is just somebody being thoughtless
> about Makefile ordering and not an intentional override of the
> default
On 09/05/2016 02:50 PM, Mithun Cy wrote:
On Sep 2, 2016 7:38 PM, "Jesper Pedersen"
wrote:
Could you provide a rebased patch based on Amit's v5 ?
Please find the the patch, based on Amit's V5.
I have fixed following things
1. now in "_hash_first" we check if
Alvaro Herrera writes:
> Tom Lane wrote:
>> Alvaro Herrera writes:
>>> I suppose this is a very easy mistake to make -- but also fortunately an
>>> easy one to correct. Do you want me to fix the affected modules?
>> I was going to do it, but
Tom Lane wrote:
> Alvaro Herrera writes:
> > I suppose this is a very easy mistake to make -- but also fortunately an
> > easy one to correct. Do you want me to fix the affected modules?
>
> I was going to do it, but if you want to, feel free.
Done.
> (BTW, I notice
My apologies if this was already requested before...
I think it would be fantastic if postgres had an "explain the explain" option:
Today's explain tells us what loops and scans were used, and relative
costs, etc. It doesn't seem to tell *why* the planner elected to use
what it did.
For
Peter Geoghegan writes:
> On Thu, Sep 8, 2016 at 12:01 AM, Heikki Linnakangas wrote:
>> I still think tuplesort_heap_siftup is a confusing name, although I'm not
>> sure that Peter's "compact" is much better. I suggest that we rename it to
>>
Hi,
I found these steps to a reliable crash (I know the patch is WIP but I
assume you want to hear about these).
(Running a single instance suffices)
psql (10devel_logical_replication_20160901_1237_6f7c0ea32f80)
Type "help" for help.
(PID 9809) [testdb] # CREATE PUBLICATION pub_all;
Hi,
Attached patch add --disable-page-skipping option to vacuumed command for 9.6.
If by any chance the freeze map causes the serious data corruption bug
then the user will want to run pg_check_visible() and vacuum with
DISABLE_PAGE_SKIPPING option to the multiple tables having problem.
In this
On Thu, Sep 8, 2016 at 10:18 AM, Claudio Freire wrote:
> That particular case I believe is using work_mem=4MB, easy strings, 1.5GB
> table.
Cool. I wonder where this leaves Heikki's draft patch, that completely
removes batch memory, etc.
--
Peter Geoghegan
--
Sent
On Thu, Sep 8, 2016 at 2:13 PM, Peter Geoghegan wrote:
> On Thu, Sep 8, 2016 at 8:53 AM, Claudio Freire wrote:
>> setup:
>>
>> create table lotsofitext(i text, j text, w text, z integer, z2 bigint);
>> insert into lotsofitext select cast(random() *
On Thu, Sep 8, 2016 at 12:01 AM, Heikki Linnakangas wrote:
> I still think tuplesort_heap_siftup is a confusing name, although I'm not
> sure that Peter's "compact" is much better. I suggest that we rename it to
> tuplesort_heap_delete_top(). In comments within the function,
Michael Paquier writes:
> On Tue, Aug 30, 2016 at 5:43 AM, MartÃn Marqués
> wrote:
>> This is v4 of the patch, which is actually a cleaner version from the
>> v2 one Michael sent.
> Let's do as you suggest then, and just focus on the schema
On Thu, Sep 8, 2016 at 8:53 AM, Claudio Freire wrote:
> setup:
>
> create table lotsofitext(i text, j text, w text, z integer, z2 bigint);
> insert into lotsofitext select cast(random() * 10.0 as text)
> || 'blablablawblabla', cast(random() * 10.0 as
> While checking for shippability, we build the target list which is passed
> to
> the foreign server as fdw_scan_tlist. The target list contains
> a. All the GROUP BY expressions
> b. Shippable entries from the target list of upper relation
> c. Var and Aggref nodes from non-shippable entries
Alvaro Herrera writes:
> Tom Lane wrote:
>> I happened to notice that if you type "make" in
>> src/test/modules/test_pg_dump, you will get a "make check" action
>> not "make all".
> Strange. Don't all these makefiles depend on the pgxs stuff emitting
> something sane,
On Thu, Sep 8, 2016 at 8:42 PM, Claudio Freire
wrote:
> On Thu, Sep 8, 2016 at 11:54 AM, Pavan Deolasee
> wrote:
> > For example, for a table with 60 bytes wide tuple (including 24 byte
> > header), each page can approximately have 8192/60 = 136
Peter Eisentraut writes:
> More generally, I'm concerned that appendShellString() looks pretty
> attractive for future use. It's not inconceivable that someone will
> want to use it for say calling pg_dump from pg_dumpall or pg_upgrade at
> some point, and then
Tom Lane wrote:
> I happened to notice that if you type "make" in
> src/test/modules/test_pg_dump, you will get a "make check" action
> not "make all". I hope this is just somebody being thoughtless
> about Makefile ordering and not an intentional override of the
> default make target. If the
I happened to notice that if you type "make" in
src/test/modules/test_pg_dump, you will get a "make check" action
not "make all". I hope this is just somebody being thoughtless
about Makefile ordering and not an intentional override of the
default make target. If the latter, I beg to differ
On 9/4/16 7:36 PM, Stephen Frost wrote:
> Perhaps if the versioned install script was actually a non-versioned
> install script in the source tree, and the Makefile simply installed it
> into the correct place, then we could eliminate that part. (All very
> hand-wavy, I've not looked at what it'd
Rahila Syed wrote:
> However, including the check here will require returning the status
> of command from this hook. i.e if we throw error inside this
> hook we will need to return false indicating the value has not changed.
Looking at the other variables hooks, they already emit errors
On 9/8/16 11:16 AM, Tom Lane wrote:
> This is a problem, if ICU won't guarantee cross-version compatibility,
> because it destroys the argument that moving to ICU would offer us
> collation behavior stability.
It would offer a significant upgrade over the current situation.
First, it offers
On 9/6/16 1:42 PM, Robert Haas wrote:
> If we were talking about pathnames containing spaces, I would agree,
> but I've never heard of a legitimate pathname containing CR or LF. I
> can't see us losing much by refusing to allow such pathnames, except
> for security holes.
The flip side of that
On 9/6/16 1:08 PM, Tom Lane wrote:
>> As just mentioned elsewhere, this accidentally introduces a failure if
>> > the PostgreSQL installation path contains LF/CR, because of the use of
>> > appendShellString().
> I think that's intentional, not accidental. What actual use case is
> there for
I have updated the patch with additional tests and comments per your
review. Final(?) version attached.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From ee34d7d64a4b10c9f7fbe8c905a56cea1584c8c9 Mon Sep 17
1 - 100 of 159 matches
Mail list logo