On Fri, Dec 11, 2015 at 4:27 AM, Andres Freund wrote:
> Hi,
>
> On 2015-12-10 18:36:32 +0100, Andres Freund wrote:
>> On 2015-12-10 12:19:12 -0500, Robert Haas wrote:
>> > > The real problem there imo isn't that the copy_relation_data() doesn't
>> > > deal with 0 block tables, but that ATExecSetTa
On 10 December 2015 at 20:02, Tom Lane wrote:
>> It seems to be a loss of 4 digits in every case I've seen.
>
> I wouldn't have a problem with, say, throwing in an extra DEC_DIGITS worth
> of rscale in each of these functions so that the discrepancies tend to
> favor more significant digits out, r
On Fri, Dec 11, 2015 at 1:32 AM, Andres Freund wrote:
> I've, pushed the fix for the promotion related issue.
Thanks! It is great to see this issue addressed.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
On Fri, Dec 11, 2015 at 5:35 AM, Alvaro Herrera
wrote:
> Noah Misch wrote:
>> On Mon, Dec 07, 2015 at 02:34:39PM +0900, Michael Paquier wrote:
>> > > Postmaster log file names became less informative. Before the commit:
>> > > Should nodes get a name, so we instead see master_57834.log?
>> >
>> >
Hello,
At Thu, 10 Dec 2015 20:27:01 +0100, Andres Freund wrote in
<20151210192701.gc11...@alap3.anarazel.de>
> > > > A second problem is that the smgrimmedsync() in copy_relation_data()
> > > > isn't called for the init fork of unlogged relations, even if it needs
> > > > to.
>
> Here's a patch
On Thu, Dec 3, 2015 at 6:06 PM, David Rowley
wrote:
> On 3 December 2015 at 19:24, Haribabu Kommi
> wrote:
>>
>> On Thu, Dec 3, 2015 at 4:18 PM, David Rowley
>> wrote:
>> >
>> > Hi,
>> >
>> > I just wanted to cross post here to mark that I've posted an updated
>> > patch
>> > for combining aggre
On Fri, Dec 11, 2015 at 3:41 AM, Robert Haas wrote:
> On Wed, Dec 2, 2015 at 6:45 AM, Ashutosh Bapat
> wrote:
> > It's been a long time since last patch on this thread was posted. I have
> > started
> > to work on supporting join pushdown for postgres_fdw. Attached please
> find
> > three
> > pa
On Fri, Dec 11, 2015 at 12:59 AM, Robert Haas wrote:
> On Thu, Dec 10, 2015 at 9:49 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Oh, please, no. Gosh, this is supposed to be a lightweight facility!
>>> Just have a chunk of shared memory and write the data in there. If
>>> you try to feed thi
On 2015/12/11 14:41, Kyotaro HORIGUCHI wrote:
> Sorry, I misunderstood the meaning of PgStat_*.
I should've just said "messages to the stats collector" instead of
"PgStat_Msg's".
>
> At Fri, 11 Dec 2015 09:41:04 +0900, Amit Langote
> wrote
>>> As far as I understand it, the basic reason why th
Sorry, I misunderstood the meaning of PgStat_*.
At Fri, 11 Dec 2015 09:41:04 +0900, Amit Langote
wrote in <566a1ba0.70...@lab.ntt.co.jp>
> > As far as I understand it, the basic reason why this patch exists is
> > to allow a DBA to have a hint of the progress of a VACUUM that may be
> > taking m
On Thu, Dec 10, 2015 at 11:20 PM, Robert Haas wrote:
> On Tue, Dec 8, 2015 at 6:40 AM, Etsuro Fujita
> wrote:
> > IMO I want to see the EvalPlanQual fix in the first version for 9.6.
>
> +1.
>
> I think there is still a lot functionality that is offered without
EvalPlanQual fix. As long as we do
I wrote:
> As threatened, here's a patch on top of that that gets rid of
> LateralJoinInfo. I'm pretty happy with this, although I have an
> itchy feeling that we could dispense with the lateral_vars lists too.
I experimented with that and figured out what was bothering me: there is
no need for a
Alvaro Herrera writes:
> Peter Eisentraut wrote:
>> On 11/11/15 12:34 PM, Tom Lane wrote:
>>> I was thinking more of removing the "missing" script and associated logic
>>> entirely, rather than making PGXS a special case.
>> Well, about a year ago people were arguing for the opposite change in
>>
Jim Nasby writes:
> AFAICT the problem is that missing wasn't included in install or
> uninstall in config/Makefile. Attached patch fixes that, and results in
> missing being properly installed in lib/pgxs/config.
I thought we'd more or less rejected that approach in the previous thread.
Jim Nasby writes:
> Is there any reason we couldn't/shouldn't support IS DISTINCT in
> subquery_Op? (Or really, just add support to ANY()/ALL()/(SELECT ...)?)
It's not an operator (in the sense of something with a pg_operator OID),
which means this would be quite a bit less than trivial as far a
I wrote:
> Ah-hah --- the new check I added in join_is_legal understood about
> chains of LATERAL references, but it forgot that we could also have chains
> of outer-join ordering constraints. When we're looking to see if joining
> on the basis of a LATERAL reference would break some later outer j
Is there any reason we couldn't/shouldn't support IS DISTINCT in
subquery_Op? (Or really, just add support to ANY()/ALL()/(SELECT ...)?)
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http:/
On 2015/12/10 20:46, Michael Paquier wrote:
> On Thu, Dec 10, 2015 at 7:23 PM, Amit Langote
> wrote:
>> AIUI, the counts published via stats collector are updated asynchronously
>> w.r.t. operations they count and mostly as aggregate figures. For example,
>> PgStat_StatTabEntry.blocks_fetched. IOW
On Fri, Dec 11, 2015 at 1:57 AM, Robert Haas wrote:
> On Mon, Nov 30, 2015 at 9:53 PM, Michael Paquier
> wrote:
>>> I feel quite uncomfortable that it solves the problem from a kind
>>> of nature of unlogged object by arbitrary flagging which is not
>>> fully corresponds to the nature. If we can
Recently I had need of removing occurrences of a number of values from
an array. Obviously I could have nested array_remove() call or wrapped
the whole thing in a SELECT unnest(), but that seems rather silly and
inefficient.
Any one have objections to changing array_replace_internal() to make
Full story below, but in short:
I see that there is a config/missing script in source, and that
Makefile.global.in references it:
> src/Makefile.global.in:missing= $(SHELL)
$(top_srcdir)/config/missing
AFAICT the problem is that missing wasn't included in install or
uninstall
On Thu, Dec 10, 2015 at 7:09 PM, Robert Haas wrote:
>> I really don't like Robert's proposal of a metapage though. We've got too
>> darn many forks per relation already.
>
> Oh, I wasn't thinking of adding a fork, just repurposing block 0 of
> the main fork, as we do for some index types.
Not to
On 2015-12-10 17:13:12 -0500, Robert Haas wrote:
> Is the postmaster in a "stopped" state (T)?
No, running normally. New connections are possible without problems.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
On Thu, Dec 10, 2015 at 4:55 PM, Andres Freund wrote:
> Hi,
>
> I recently started a pgbench benchmark (to evaluate a piece of hardware,
> not postgres) with master. Unfortunately, by accident, I started
> postgres in a shell, not screen like pgbench.
>
> Just logged back in and saw:
> client 71 a
On Wed, Dec 2, 2015 at 6:45 AM, Ashutosh Bapat
wrote:
> It's been a long time since last patch on this thread was posted. I have
> started
> to work on supporting join pushdown for postgres_fdw. Attached please find
> three
> patches
> 1. pg_fdw_core.patch: changes in core related to user mapping
Hi,
I recently started a pgbench benchmark (to evaluate a piece of hardware,
not postgres) with master. Unfortunately, by accident, I started
postgres in a shell, not screen like pgbench.
Just logged back in and saw:
client 71 aborted in state 8: ERROR: database is not accepting commands to
avo
Noah Misch wrote:
> On Mon, Dec 07, 2015 at 02:34:39PM +0900, Michael Paquier wrote:
> > I don't directly see any limitation with the use of kill on Windows..
> > http://perldoc.perl.org/functions/kill.html
> > But indeed using directly pg_ctl kill seems like a better fit for the
> > PG infrastruc
Robert Haas writes:
> On Thu, Dec 10, 2015 at 2:47 PM, Tom Lane wrote:
>> That's on me as author of the commit message, I guess. The rscale
>> in most of these functions is exactly the number of fraction digits
>> that will be emitted, and we changed the rules for computing it.
>> Not by much, i
On Thu, Dec 10, 2015 at 2:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> This patch, or something nearby, seems to have changed the number of
>> significant figures produced by log() and maybe some of the other
>> functions this patch touched.
>
> Yeah, not surprising.
>
>> It's certainly not ob
Hello Hackers,
Reviving an old thread on simplifying the bootstrap process.
I'm a developer from the GPDB / HAWQ side of the world where we did some
work a while back to enable catalog definition via SQL files and we have
found it valuable from a dev perspective. The mechanism currently in t
Robert Haas writes:
> This patch, or something nearby, seems to have changed the number of
> significant figures produced by log() and maybe some of the other
> functions this patch touched.
Yeah, not surprising.
> It's certainly not obvious from the commit message that this change
> was expecte
On 9 December 2015 at 18:44, Stas Kelvich wrote:
> In this patch I’ve changed this procedures to following:
> * on prepare backend writes data only to xlog and store pointer to the
> start of the xlog record
> * if commit occurs before checkpoint then backend reads data from xlog by
> this point
On Thu, Dec 10, 2015 at 2:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, sorta. To be honest, I think this patch is really ugly. If we
>> were going to do this then, yes, I would want to split the patch into
>> two parts along those lines. But actually I don't really want to do
>> it th
On Thu, Dec 10, 2015 at 2:25 PM, Simon Riggs wrote:
> On 10 December 2015 at 18:59, Robert Haas wrote:
>Why did we make the change? I'm not sure it's bad, but
>>
>> it seems funny to whack a user-visible behavior around like this
>> without a clearly-explained reason.
>
> Surely the title of
Hi,
On 2015-12-10 18:36:32 +0100, Andres Freund wrote:
> On 2015-12-10 12:19:12 -0500, Robert Haas wrote:
> > > The real problem there imo isn't that the copy_relation_data() doesn't
> > > deal with 0 block tables, but that ATExecSetTableSpace() doesn't have a
> > > unlogged table specific codepat
On 10 December 2015 at 18:59, Robert Haas wrote:
Why did we make the change? I'm not sure it's bad, but
> it seems funny to whack a user-visible behavior around like this
> without a clearly-explained reason.
>
Surely the title of the post explains?
--
Simon Riggshttp://www
Robert Haas writes:
> Well, sorta. To be honest, I think this patch is really ugly. If we
> were going to do this then, yes, I would want to split the patch into
> two parts along those lines. But actually I don't really want to do
> it this way at all. It's not that I don't want the performan
On Thu, Dec 10, 2015 at 1:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Dec 10, 2015 at 1:22 PM, Simon Riggs wrote:
>>> We can seq scan the array at relcache build time and invalidate relcache
>>> when we extend. WAL log any extension to a new segment and write the table
>>> to disk at
On Sun, Nov 15, 2015 at 4:40 AM, Dean Rasheed wrote:
> On 14 November 2015 at 20:05, Tom Lane wrote:
>> I committed this with that change and some other
>> mostly-cosmetic revisions.
>
> Thanks.
This patch, or something nearby, seems to have changed the number of
significant figures produced by
Robert Haas writes:
> On Thu, Dec 10, 2015 at 1:22 PM, Simon Riggs wrote:
>> We can seq scan the array at relcache build time and invalidate relcache
>> when we extend. WAL log any extension to a new segment and write the table
>> to disk at checkpoint.
> Invaliding the relcache when we extend w
Hi
2015-12-08 7:06 GMT+01:00 Catalin Iacob :
> On Thu, Dec 3, 2015 at 6:54 PM, Pavel Stehule
> wrote:
> > Don't understand - if Fatal has same behave as Error, then why it cannot
> be
> > inherited from Error?
> >
> > What can be broken?
>
> Existing code that did "except plpy.Error as exc" will
Andreas Seltenreich writes:
> Tom Lane writes:
>> [2. transitive-lateral-fixes-1.patch]
> I was about to write that sqlsmith likes the patch, but after more than
> 10^8 ok queries the attached ones were generated.
Ah-hah --- the new check I added in join_is_legal understood about
chains of LATER
> postgres=# \crosstabview 4 +month label
>
Maybe using optional int order column instead label is better - then you
can do sort on client side
so the syntax can be "\crosstabview VCol [+/-]HCol [[+-]HOrderCol]
Regards
Pavel
>
> ┌──┬───┬───┬┬───┬──
On Thu, Dec 10, 2015 at 1:22 PM, Simon Riggs wrote:
> On 10 December 2015 at 16:47, Robert Haas wrote:
>>
>> On Thu, Dec 10, 2015 at 11:36 AM, Andres Freund
>> wrote:
>> >> In fact, having no way to get the relation length other than scanning
>> >> 1000 files doesn't seem like an especially good
On 10 December 2015 at 16:47, Robert Haas wrote:
> On Thu, Dec 10, 2015 at 11:36 AM, Andres Freund
> wrote:
> >> In fact, having no way to get the relation length other than scanning
> >> 1000 files doesn't seem like an especially good choice even if we used
> >> a better data structure. Puttin
On Thu, Dec 10, 2015 at 12:55 PM, Greg Stark wrote:
> On Thu, Dec 10, 2015 at 4:47 PM, Robert Haas wrote:
>> It's not straightforward, but I don't think that's the reason. What
>> we could do is look at the call sites that use
>> RelationGetNumberOfBlocks() and change some of them to get the
>>
On 10 December 2015 at 13:04, Jaime Casanova
wrote:
> Hi,
>
> We just notice $SUBJECT. Attached patch fixes it by ignoring USER
> MAPPINGs in shdepReassignOwned() just like it happens with default
> ACLs.
>
BTW, shouldn't we at least give a warning on those cases instead of
asuming that the user
Hi,
We just notice $SUBJECT. Attached patch fixes it by ignoring USER
MAPPINGs in shdepReassignOwned() just like it happens with default
ACLs.
DROP OWNED manages it well.
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
diff --git a
On 2015-12-10 17:55:37 +, Greg Stark wrote:
> It seems to me that if you want to fix the linked lists of files
> that's orthogonal to whether the file lengths on disk are
> authoritative. You can always keep the lengths or at least the number
> of files cached and updated in shared memory in a
On Thu, Dec 10, 2015 at 4:47 PM, Robert Haas wrote:
>
> It's not straightforward, but I don't think that's the reason. What
> we could do is look at the call sites that use
> RelationGetNumberOfBlocks() and change some of them to get the
> information some other way instead. I believe get_relati
On 2015-12-10 18:36:32 +0100, Andres Freund wrote:
> On 2015-12-10 12:19:12 -0500, Robert Haas wrote:
> > On Thu, Dec 10, 2015 at 11:32 AM, Andres Freund wrote:
> > > I've, pushed the fix for the promotion related issue. I'm afraid that
> > > the ALTER TABLE SET TABLESPACE issue is a bit bigger
>
On Tue, Dec 8, 2015 at 6:40 AM, Etsuro Fujita
wrote:
> IMO I want to see the EvalPlanQual fix in the first version for 9.6.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Tue, Dec 8, 2015 at 8:32 AM, Masahiko Sawada wrote:
> I found some lacks of tab-completion for RLS in 9.5.
>
> * ALTER POLICY [TAB]
> I expected to appear the list of policy name, but nothing is appeared.
>
> * ALTER POLICY hoge_policy ON [TAB]
> I expected to appear the list of table name rela
On 2015-12-10 12:19:12 -0500, Robert Haas wrote:
> On Thu, Dec 10, 2015 at 11:32 AM, Andres Freund wrote:
> > I've, pushed the fix for the promotion related issue. I'm afraid that
> > the ALTER TABLE SET TABLESPACE issue is a bit bigger
> > than it though.
>
> I think that I would have preferred
On Tue, Dec 8, 2015 at 6:16 AM, Etsuro Fujita
wrote:
> Attached is a small patch to adjust a comment in setrefs.c; in
> set_foreignscan_references, fdw_recheck_quals also gets adjusted to
> reference foreign scan tuple, in case of a foreign join, so I added
> "etc.", to a comment there, as the com
On Thu, Dec 10, 2015 at 11:32 AM, Andres Freund wrote:
> I've, pushed the fix for the promotion related issue. I'm afraid that
> the ALTER TABLE SET TABLESPACE issue is a bit bigger
> than it though.
I think that I would have preferred to fix this by flushing unlogged
buffers in bulk at the end
On Mon, Nov 30, 2015 at 9:53 PM, Michael Paquier
wrote:
>> I feel quite uncomfortable that it solves the problem from a kind
>> of nature of unlogged object by arbitrary flagging which is not
>> fully corresponds to the nature. If we can deduce the necessity
>> of fsync from some nature, it would
On Thu, Dec 10, 2015 at 11:36 AM, Andres Freund wrote:
>> In fact, having no way to get the relation length other than scanning
>> 1000 files doesn't seem like an especially good choice even if we used
>> a better data structure. Putting a header page in the heap would make
>> getting the length
On Wed, Dec 9, 2015 at 8:30 AM, Aleksander Alekseev
wrote:
> Hello, Robert
>
> Thanks for your review. I believe I fixed items 1, 2 and 3 (see
> attachment). Also I would like to clarify item 4.
>
>> 4. It mixes together multiple ideas in a single patch, not only
>> introducing a hashing concept b
On 2015-12-10 11:10:10 -0500, Robert Haas wrote:
> (More broadly, as Kevin was pointing out to me yesterday, md.c looks
> like it could do with a face lift. Keeping a linked list of 1GB
> segments and chasing down the list to find the length of the file may
> have been fine when relations over 1GB
Hi Michael, Robert,
On 2015-12-10 21:10:57 +0900, Michael Paquier wrote:
> On Thu, Dec 10, 2015 at 9:07 PM, Michael Paquier
> wrote:
> >>> Note that in both cases the patches are not complete, we need to fix
> >>> as well copy_relation_data@tablecmds.c so as the INIT_FORKNUM pages
> >>> are logge
On Wed, Dec 9, 2015 at 2:52 AM, Etsuro Fujita
wrote:
> Thank you for committing the patch!
>
> Sorry, I overlooked a typo in docs: s/more that one/more than one/ Please
> find attached a patch.
Committed, thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
On Wed, Dec 9, 2015 at 12:15 AM, Pavel Stehule wrote:
>> On Wed, Dec 9, 2015 at 2:07 PM, Pavel Stehule
>> wrote:
>> > should be noted, recorded somewhere so this introduce possible
>> > compatibility
>> > issue - due default processing .psqlrc.
>>
>> That's written in the commit log, so I guess t
On Wed, Dec 9, 2015 at 4:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> The comment in mdnblocks.c says this:
>
>> * Because we pass O_CREAT, we will create the
>> next segment (with
>> * zero length) immediately, if the last
>> segment is of len
On Thu, Dec 10, 2015 at 9:49 AM, Tom Lane wrote:
> Robert Haas writes:
>> Oh, please, no. Gosh, this is supposed to be a lightweight facility!
>> Just have a chunk of shared memory and write the data in there. If
>> you try to feed this through the stats collector you're going to
>> increase th
Robert Haas writes:
> Oh, please, no. Gosh, this is supposed to be a lightweight facility!
> Just have a chunk of shared memory and write the data in there. If
> you try to feed this through the stats collector you're going to
> increase the overhead by 100x or more, and there's no benefit. We'
Andres Freund writes:
> Tom, are you applying the patch, or should I?
I can do it ... it was my oversight to begin with :-(
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgres
On 2015-12-10 09:39:30 -0500, Tom Lane wrote:
> Michael Paquier writes:
> > On Thu, Dec 10, 2015 at 10:36 PM, Victor Wagner wrote:
> >> Postgres requires relatively recent Perl. Version objects appeared in
> >> Perl 5.10 and most people would have something newer.
>
> > AFAIK, the minimum requi
On Thu, Dec 10, 2015 at 6:46 AM, Michael Paquier
wrote:
> On Thu, Dec 10, 2015 at 7:23 PM, Amit Langote
> wrote:
>> On 2015/12/10 15:28, Michael Paquier wrote:
>>> - The progress tracking facility adds a whole level of complexity for
>>> very little gain, and IMO this should *not* be part of PgBa
Michael Paquier writes:
> On Thu, Dec 10, 2015 at 10:36 PM, Victor Wagner wrote:
>> Postgres requires relatively recent Perl. Version objects appeared in
>> Perl 5.10 and most people would have something newer.
> AFAIK, the minimum requirement for perl is 5.8...
Yeah, that is our stated requir
On Thu, Dec 10, 2015 at 9:04 AM, Andres Freund wrote:
> On 2015-12-10 08:55:54 -0500, Robert Haas wrote:
>> Maybe. But I think we could use a little more vigorous discussion of
>> that issue, since Andres doesn't seem to be very convinced by your
>> analysis, and I don't currently understand what
On Thu, Dec 10, 2015 at 4:55 AM, Andreas Seltenreich wrote:
> Tom Lane writes:
>
>> Merlin Moncure writes:
>>> Aside from the functional issues, could your changes result in
>>> performance regressions?
> [...]
>> It's a little bit harder to gauge the impact on planner speed. The
>> transitive c
On Thu, Dec 10, 2015 at 10:36 PM, Victor Wagner wrote:
> Postgres requires relatively recent Perl. Version objects appeared in
> Perl 5.10 and most people would have something newer.
AFAIK, the minimum requirement for perl is 5.8...
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-ha
On 2015-12-10 08:55:54 -0500, Robert Haas wrote:
> Maybe. But I think we could use a little more vigorous discussion of
> that issue, since Andres doesn't seem to be very convinced by your
> analysis, and I don't currently understand what you've fixed because I
> can't, as mentioned several times,
On Wed, Dec 9, 2015 at 8:23 PM, Noah Misch wrote:
> On Wed, Dec 09, 2015 at 11:08:32AM -0500, Robert Haas wrote:
>> On Wed, Dec 9, 2015 at 9:43 AM, Noah Misch wrote:
>> > I hope those who have not already read commit 4f627f8 will not waste time
>> > reading it. They should instead ignore multixa
On Thu, 10 Dec 2015 21:19:46 +0900
Michael Paquier wrote:
> On Thu, Dec 10, 2015 at 5:45 PM, Victor Wagner
> > Postgres seems to compile fine with flex 2.6.0.
>
> It seems that 32f15d05 missed to update its equivalent in
> src/tools/msvc. Per se the patch attached as you already found out.
Michael, Jeff thanks for reviewing and testing.
> On 10 Dec 2015, at 02:16, Michael Paquier wrote:
>
> This has better be InvalidXLogRecPtr if unused.
Yes, that’s better. Changed.
> On 10 Dec 2015, at 02:16, Michael Paquier wrote:
> +if (gxact->prepare_lsn)
> +{
> +XlogReadT
On Thu, Dec 10, 2015 at 9:13 PM, Andres Freund wrote:
> On 2015-12-10 21:10:57 +0900, Michael Paquier wrote:
>> In short: should I send patches for all those things or are you on it?
>
> I'm on it. I don't think the new name you gave the function, and the new
> comment, are really an improvement.
On Thu, Dec 10, 2015 at 5:45 PM, Victor Wagner wrote:
> Recently (about a month ago) flex 2.6.0 have been released.
>
> But when we tried to compile PostgreSQL 9.5 beta 1 from git with it on
> Windows, we've encountered that src/tools/msvc/pgflex.pl explicitely
> checks that minor version of flex
On 2015-12-10 21:10:57 +0900, Michael Paquier wrote:
> In short: should I send patches for all those things or are you on it?
I'm on it. I don't think the new name you gave the function, and the new
comment, are really an improvement. We already have 'SyncOneBuffer'
(unusable for our purpose unfor
On Thu, Dec 10, 2015 at 9:07 PM, Michael Paquier
wrote:
> On Thu, Dec 10, 2015 at 8:56 PM, Andres Freund wrote:
>>> So, do we go for something like the patch you attached in
>>> 20151208125716.gs4...@alap3.anarazel.de for master and 9.5, and for
>>> ~9.4 we use the one I wrote in
>>> cab7npqsxerp
On Thu, Dec 10, 2015 at 8:56 PM, Andres Freund wrote:
>> So, do we go for something like the patch you attached in
>> 20151208125716.gs4...@alap3.anarazel.de for master and 9.5, and for
>> ~9.4 we use the one I wrote in
>> cab7npqsxerpzj+bz-mfopzfzp5pabie9jwbucjy6qayertt...@mail.gmail.com?
>
> I'm
> So, do we go for something like the patch you attached in
> 20151208125716.gs4...@alap3.anarazel.de for master and 9.5, and for
> ~9.4 we use the one I wrote in
> cab7npqsxerpzj+bz-mfopzfzp5pabie9jwbucjy6qayertt...@mail.gmail.com?
I'm more thinking of using something like my patch for all branch
On Thu, Dec 10, 2015 at 7:23 PM, Amit Langote
wrote:
> On 2015/12/10 15:28, Michael Paquier wrote:
>> - The progress tracking facility adds a whole level of complexity for
>> very little gain, and IMO this should *not* be part of PgBackendStatus
>> because in most cases its data finishes wasted. W
On Thu, Dec 10, 2015 at 4:57 PM, Andres Freund wrote:
> On December 10, 2015 5:02:27 AM GMT+01:00, Michael Paquier
> wrote:
>>On Wed, Dec 9, 2015 at 9:07 PM, Andres Freund
>>wrote:
>>> On 2015-12-09 21:03:47 +0900, Michael Paquier wrote:
Oh, OK. I didn't read though your lines correctly. S
Tom Lane writes:
> Merlin Moncure writes:
>> Aside from the functional issues, could your changes result in
>> performance regressions?
[...]
> It's a little bit harder to gauge the impact on planner speed. The
> transitive closure calculation could be expensive in a query with many
> lateral re
On 2015/12/10 15:28, Michael Paquier wrote:
> On Thu, Dec 10, 2015 at 4:40 AM, Robert Haas wrote:
>> It's going to be *really* important that this facility provides a
>> lightweight way of updating progress, so I think this whole API is
>> badly designed. VACUUM, for example, is going to want a w
On Sun, Dec 6, 2015 at 9:52 AM, Andreas Seltenreich wrote:
> I've added new grammar rules to sqlsmith and improved some older ones.
Could you possibly teach sqlsmith about INSERT ... ON CONFLICT DO
UPDATE/IGNORE? I think that that could be very helpful, especially if
it could be done in advance o
Tom Lane writes:
> [2. transitive-lateral-fixes-1.patch]
I was about to write that sqlsmith likes the patch, but after more than
10^8 ok queries the attached ones were generated.
regards,
Andreas
post-patch-errors.sql
Description: application/sql
--
Sent via pgsql-hackers mailing list (pgsq
+1
On Thu, Dec 10, 2015 at 9:58 AM, Peter Geoghegan wrote:
> On Thu, Dec 10, 2015 at 12:34 AM, Andres Freund
> wrote:
> >> > Ripping it out and replacing it monolithically will not
> >> > change that; it will only make the detailed history harder to
> >> > reconstruct, and I *will* want to reco
On Thu, Dec 10, 2015 at 12:34 AM, Andres Freund wrote:
>> > Ripping it out and replacing it monolithically will not
>> > change that; it will only make the detailed history harder to
>> > reconstruct, and I *will* want to reconstruct it.
>>
>> What's something that might happen six months from now
Collegues,
Recently (about a month ago) flex 2.6.0 have been released.
But when we tried to compile PostgreSQL 9.5 beta 1 from git with it on
Windows, we've encountered that src/tools/msvc/pgflex.pl explicitely
checks that minor version of flex is equal to 5.
unless ($verparts[0] == 2 && $v
Hello,
At Wed, 9 Dec 2015 10:31:06 -0800, David Fetter wrote in
<20151209183106.gc10...@fetter.org>
> On Wed, Dec 09, 2015 at 03:49:20PM +, Greg Stark wrote:
> > On Wed, Dec 9, 2015 at 2:27 PM, David Fetter wrote:
> > > Agreed that the "whole new language" aspect seems like way too big a
>
On 2015-12-09 20:23:06 -0500, Noah Misch wrote:
> By the way, it occurs to me that I should also make pg_upgrade blacklist the
> range of catversions that might have data loss. No sense in putting ourselves
> in the position of asking whether data files of a 9.9.3 cluster spent time in
> a 9.5beta
94 matches
Mail list logo
