On Fri, Apr 29, 2016 at 7:15 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> > On Fri, Apr 29, 2016 at 12:01 PM, Andreas Seltenreich <
seltenre...@gmx.de>
> > wrote:
> >> tonight's sqlsmith run yielded another core dump:
> >>
> >> TRAP: FailedAssertion("!(MyProc->lockGroupLeader == ((void *)0))",
F
On Fri, Apr 29, 2016 at 7:33 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> >> On Thu, Apr 28, 2016 at 10:06 PM, Tom Lane wrote:
> >>> I'd be inclined to think that it's silly to build GatherPaths in
advance
> >>> of having finalized the list of partial paths for a rel.
>
> > What's happening her
Hi
Evidently over the past 15 or so years I've never needed to type "\l ",
but when isolating a single database entry in a cluster with a lot more
databases than most I've encountered, was suprised to notice it didn't work.
Trivial patch attached, will add to next commitfest.
Regards
Ian Barwi
On 2016-04-30 02:28:22 +0200, Andreas Seltenreich wrote:
> This sounds like it should work to capture more context when the
> Assertion fails the next time. I have to purge the catalogs a bit
> though to avoid stopping early on boring core dumps. Most of them are
> currently caused by acl.c using
On 2016-04-30 02:34:35 +0200, Andreas Seltenreich wrote:
> I didn't think the effort of creating this kind of clean-room testing
> was worth it. If reports of failed assertions with backtrace without a
> recipe to reproduce them are a nuisance, I'll avoid them in the future.
It's obviously better
Simon Riggs writes:
> It's good that the input is fuzzed, but there needs to be a way to re-run
> identical fuzzing or a way to backtrack to find what broke. Not much point
> finding bugs we can't identify later.
sqlsmith is deterministic and allows re-generating a sequence of random
queries with
Alvaro Herrera writes:
> Amit Kapila wrote:
>> It will be helpful if you can find the offending query or plan
>> corresponding to it?
>
> So I suppose the PID of the process starting the workers should be in
> the stack somewhere.
Ja, it's right on the top, but long gone by now…
> With that one s
Hi,
On 2016-04-29 10:38:55 -0700, Jeff Janes wrote:
> I've bisected the errors I was seeing, discussed in
> http://www.postgresql.org/message-id/CAMkU=1xqehc0ok4d+tkjfq1nvuho37pyrkhjp6q8oxifmx7...@mail.gmail.com
>
> It look like they first appear in:
>
> commit 48354581a49c30f5757c203415aa8412d8
On 2016-04-28 17:41:29 +0100, Thom Brown wrote:
> I've noticed another breakage, which I can reproduce consistently.
> 2016-04-28 17:36:08 BST [18108]: [47-1] user=,db=,client= DEBUG: could not
> fsync file "base/24581/24594.1" but retrying: No such file or directory
> 2016-04-28 17:36:08 BST [18
On 04/30/2016 01:19 AM, Tom Lane wrote:
Alvaro Herrera writes:
Surely CREATE OR REPLACE should keep whatever the flag was, rather than
ovewrite it with a bogus value if not specified? In other words IMO the
CREATE OR REPLACE code needs changing, not system_views.sql.
Absolutely not! The def
On Fri, Apr 29, 2016 at 4:19 PM, Tom Lane wrote:
> Alvaro Herrera writes:
> > Andreas Karlsson wrote:
> >> I am currently looking into adding the correct parallel options to all
> >> functions in the extensions and I noticed that some built-in functions
> seems
> >> to have been marked as unsafe
Alvaro Herrera writes:
> Andreas Karlsson wrote:
>> I am currently looking into adding the correct parallel options to all
>> functions in the extensions and I noticed that some built-in functions seems
>> to have been marked as unsafe by accident. The main culprit is
>> system_views.sql which red
Andreas Karlsson wrote:
> Hi,
>
> I am currently looking into adding the correct parallel options to all
> functions in the extensions and I noticed that some built-in functions seems
> to have been marked as unsafe by accident. The main culprit is
> system_views.sql which redefines these function
On Sat, Apr 30, 2016 at 12:22 AM, Petr Jelinek wrote:
> After bit of fighting with the system the "caecilian" reported first
> successful build to the buildfarm.
Thanks! The fight was there as well.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
On Fri, Apr 29, 2016 at 4:06 PM, Andrew Dunstan wrote:
> One other point: I think we really need most of these pieces - if we are
> going to squash the whitespace we need functions to do that cleanly for json
> and to pretty-print json.
I don't think it should be squashed per se -- we just don't
On Fri, Apr 22, 2016 at 8:06 AM, Kevin Grittner wrote:
> On Thu, Apr 21, 2016 at 4:13 PM, Kevin Grittner wrote:
>
>> I have your test case running, and it is not immediately
>> clear why old rows are not being vacuumed away.
>
> I have not found the reason that the vacuuming is not as aggressive
Hi,
I am currently looking into adding the correct parallel options to all
functions in the extensions and I noticed that some built-in functions
seems to have been marked as unsafe by accident. The main culprit is
system_views.sql which redefines these functions and removes the
parallel safe
Andrew Dunstan wrote:
> Support building with Visual Studio 2015
>
> Adjust the way we detect the locale. As a result the minumum Windows
> version supported by VS2015 and later is Windows Vista. Add some tweaks
> to remove new compiler warnings. Remove documentation references to the
> now obsole
On Fri, Apr 29, 2016 at 1:47 PM, Bruce Momjian wrote:
> On Wed, Apr 13, 2016 at 12:57:19PM -0300, Marcelo Zabani wrote:
> > Hi, Tom,
> >
> > You're right, I don't think one can argue that the default parser should
> know
> > HTML.
> > How about your suggestion of there being an HTML parser, is it
On 04/29/2016 02:34 PM, Merlin Moncure wrote:
I wouldn't necessarily be opposed to us having one or more of the following:
a) suppressing whitespace addition in all json generation and text output,
possibly governed by a GUC setting so we could maintain behaviour
compatibility if required
So
On Thu, Apr 14, 2016 at 01:40:21PM -0400, David Steele wrote:
> On 4/14/16 1:33 PM, Tom Lane wrote:
> > David Steele writes:
> >> On 4/14/16 7:16 AM, Andreas Karlsson wrote:
> >>> I am personally not a fan of the pg_get_Xdef() functions due to their
> >>> heavy reliance on the syscache which feels
On 04/29/2016 07:58 AM, Andre Mikulec wrote:
> I am working with pl/r compiled for R.3.2.4 64 bit on PostgreSQL 9.5.1
> 64 bit on Windows 7 64 bit
Who did the compiling? Did you compile everything yourself, or use
binary installers for some of it? If so, which ones?
Joe
--
Crunchy Data - http:/
On Wed, Apr 13, 2016 at 12:57:19PM -0300, Marcelo Zabani wrote:
> Hi, Tom,
>
> You're right, I don't think one can argue that the default parser should know
> HTML.
> How about your suggestion of there being an HTML parser, is it feasible? I ask
> this because I think that a lot of people store HT
On Fri, Apr 29, 2016 at 02:20:40PM -0300, Alvaro Herrera wrote:
> Now, if you still live in a cave and don't use Gmail (like, say, me),
> you could still change the options in Majordomo to send a unique copy of
> each message, that is to say change the delivery class to "unique"
> rather than "each
On 04/29/2016 11:36 AM, Simon Riggs wrote:
Egos.
Consider PgLogical, who is working on this outside of 2Q?
Thank you for volunteering to assist. What would you like to work on?
You are very welcome. I have been testing as you know. I would be happy
to continue that and also was goi
On 2016-04-29 15:27:15 -0300, Alvaro Herrera wrote:
> If consensus is that we should completely forbid cross-posting, we can
> talk about that.
I find xposts rather useful. WRT committers vs. hackers thing, I'll
e.g. be far more likely to be able to keep up with committers than
hackers.
Andres
On 29 April 2016 at 18:40, Joshua D. Drake wrote:
> On 04/29/2016 08:44 AM, Bruce Momjian wrote:
>
>> On Tue, Apr 12, 2016 at 11:07:04PM +0300, Oleg Bartunov wrote:
>>
>>> Our roadmap http://www.postgresql.org/developer/roadmap/ is the
>>> problem. We
>>> don't have clear roadmap and that's why w
On Fri, Apr 29, 2016 at 12:31 PM, Alvaro Herrera
wrote:
> Thanks Alex for finding the previous thread.
>
> Andrew Dunstan wrote:
>>
>> On 04/28/2016 04:29 PM, Alvaro Herrera wrote:
>
>> >Actually we did have someone come up with a patch to "normalize" how
>> >JSON stuff was output, because our cod
Bruce Momjian wrote:
> On Fri, Apr 29, 2016 at 02:49:38PM -0300, Alvaro Herrera wrote:
> > Joshua D. Drake wrote:
> > > On 04/29/2016 10:20 AM, Alvaro Herrera wrote:
> > >
> > > >:0 Wh: msgid.lock
> > > >| formail -D 65536 $HOME/.msgid.cache
> > >
> > > And Alvaro drowns in the drool of his own s
On Fri, Apr 29, 2016 at 02:49:38PM -0300, Alvaro Herrera wrote:
> Joshua D. Drake wrote:
> > On 04/29/2016 10:20 AM, Alvaro Herrera wrote:
> >
> > >:0 Wh: msgid.lock
> > >| formail -D 65536 $HOME/.msgid.cache
> >
> > And Alvaro drowns in the drool of his own sarcasm.
>
> I was going to add an ap
Joshua D. Drake wrote:
> On 04/29/2016 10:20 AM, Alvaro Herrera wrote:
>
> >:0 Wh: msgid.lock
> >| formail -D 65536 $HOME/.msgid.cache
>
> And Alvaro drowns in the drool of his own sarcasm.
I was going to add an apology that this wasn't supposed to be insulting,
only funny, but refrained. There
I've bisected the errors I was seeing, discussed in
http://www.postgresql.org/message-id/CAMkU=1xqehc0ok4d+tkjfq1nvuho37pyrkhjp6q8oxifmx7...@mail.gmail.com
It look like they first appear in:
commit 48354581a49c30f5757c203415aa8412d85b0f70
Author: Andres Freund
Date: Sun Apr 10 20:12:32 2016 -0
Thanks Alex for finding the previous thread.
Andrew Dunstan wrote:
>
> On 04/28/2016 04:29 PM, Alvaro Herrera wrote:
> >Actually we did have someone come up with a patch to "normalize" how
> >JSON stuff was output, because our code seems to do it in three
> >different, inconsistent ways. And ou
On 04/29/2016 10:20 AM, Alvaro Herrera wrote:
:0 Wh: msgid.lock
| formail -D 65536 $HOME/.msgid.cache
And Alvaro drowns in the drool of his own sarcasm.
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full sta
On 04/29/2016 09:40 AM, Joshua D. Drake wrote:
On 04/29/2016 08:44 AM, Bruce Momjian wrote:
Consider PgLogical, who is working on this outside of 2Q? Where is the
git repo for it? Where is the bug tracker? Where is the mailing list?
Oh, its -hackers, except that it isn't, is it?
FTR: I am n
Bruce Momjian wrote:
>
> What is the recommended procedure for replying to a pgsql-committers
> messsage? Is cross-posting to hackers really the right approach, as it
> causes duplicate messages. (pgsql-committers CC removed.)
CCing pgsql-hackers when replying to -committers was discussed some
What is the recommended procedure for replying to a pgsql-committers
messsage? Is cross-posting to hackers really the right approach, as it
causes duplicate messages. (pgsql-committers CC removed.)
---
On Tue, Apr 12, 2016
On 04/29/2016 08:44 AM, Bruce Momjian wrote:
On Tue, Apr 12, 2016 at 11:07:04PM +0300, Oleg Bartunov wrote:
Our roadmap http://www.postgresql.org/developer/roadmap/ is the problem. We
don't have clear roadmap and that's why we cannot plan future feature full
release. There are several postgres-c
On 29/04/2016 18:05, Tom Lane wrote:
> Julien Rouhaud writes:
>> The segfault is caused by quals_match_foreign_key() calling get_leftop()
>> and get_rightop() on a ScalarArrayOpExpr node.
>
>> Reordering the common fields of OpExpr and ScalarArrayOpExpr at the
>> beginning of the struct so the ge
On Fri, Apr 29, 2016 at 11:02 AM, Simon Riggs wrote:
> On 12 April 2016 at 20:25, Josh berkus wrote:
>
>>
>> Here's the features I can imagine being worth major backwards
>> compatibility breaks:
>>
>> 1. Fully pluggable storage with a clean API.
>>
>> 2. Total elimination of VACUUM or XID freezi
On Fri, Apr 29, 2016 at 7:15 AM, Merlin Moncure wrote:
> Andrew mentions several solutions. I like them all except I would
> prefer not to introduce a GUC for controlling the output format. I do
> not think it's a good idea to set the expectation that clients can
> rely on text out byte for byt
Julien Rouhaud writes:
> The segfault is caused by quals_match_foreign_key() calling get_leftop()
> and get_rightop() on a ScalarArrayOpExpr node.
> Reordering the common fields of OpExpr and ScalarArrayOpExpr at the
> beginning of the struct so the get_*op() work with either (as in
> attached pa
On 12 April 2016 at 20:25, Josh berkus wrote:
> Here's the features I can imagine being worth major backwards
> compatibility breaks:
>
> 1. Fully pluggable storage with a clean API.
>
> 2. Total elimination of VACUUM or XID freezing
>
> 3. Fully transparent-to-the user MM replication/clustering
On 29/04/2016 13:20, Michael Paquier wrote:
> On Fri, Apr 29, 2016 at 7:25 PM, Stefan Huehner wrote:
>> If you need any more info or testing done just let me know.
>
> The information you are providing is sufficient to reproduce the
> problem, thanks! I have added this bug to the list of open ite
On Tue, Apr 12, 2016 at 11:07:04PM +0300, Oleg Bartunov wrote:
> Our roadmap http://www.postgresql.org/developer/roadmap/ is the problem. We
> don't have clear roadmap and that's why we cannot plan future feature full
> release. There are several postgres-centric companies, which have most of
> dev
Sorry for this repost: I forgot the subject line! My bad ... :-<
Hi, there.
First, my particulars:
* Ubuntu Trusty build and runtime environment
* PostgreSQL 9.3.10 Ubuntu source code
* Using a FIPS enabled version of OpenSSL (i.e. 1.0.1p version of the
library and 2.0
On Fri, Apr 29, 2016 at 08:37:57AM -0700, Joshua Drake wrote:
> >Technically, this is exactly what pg_upgrade does. I think what you
> >really mean is for the backend binary to be able to read the system
> >tables and WAL files of the old clusters --- something I can't see us
> >implementing anyti
On 04/29/2016 08:32 AM, Bruce Momjian wrote:
On Tue, Apr 12, 2016 at 11:25:21AM -0700, Josh Berkus wrote:
Here's the features I can imagine being worth major backwards
compatibility breaks:
...
5. Transparent upgrade-in-place (i.e. allowing 10.2 to use 10.1's tables
without pg_upgrade or other
On Tue, Apr 12, 2016 at 11:25:21AM -0700, Josh Berkus wrote:
> Here's the features I can imagine being worth major backwards
> compatibility breaks:
...
> 5. Transparent upgrade-in-place (i.e. allowing 10.2 to use 10.1's tables
> without pg_upgrade or other modification).
Technically, this is exac
Hi, there.
First, my particulars:
* Ubuntu Trusty build and runtime environment
* PostgreSQL 9.3.10 Ubuntu source code
* Using a FIPS enabled version of OpenSSL (i.e. 1.0.1p version of the
library and 2.0.9 of the FIPS canister source code)
* I initially posted
On Tue, Apr 12, 2016 at 01:43:41PM -0400, Robert Haas wrote:
> I'm going to throw down the gauntlet (again) and say more or less what
> I previously said on the pgsql-advocacy thread. I think that:
>
> 1. Large backward compatibility breaks are bad. Therefore, if any of
> these things are absolu
On 29/04/16 16:02, Michael Paquier wrote:
On Fri, Apr 29, 2016 at 9:13 PM, Andrew Dunstan wrote:
Yeah, I noticed the ugliness, should have fixed it. Applied your fix and
committed.
Thanks for the commit!
+1
After bit of fighting with the system the "caecilian" reported first
successful b
I am working with pl/r compiled for R.3.2.4 64 bit on PostgreSQL 9.5.1 64 bit
on Windows 7 64 bit
At the end of this issue, I am getting the following error.
https://github.com/postgres-plr/plr/issues/1
ERROR: could not open file "base/12373/2663": No such file or directory
LINE 1: SELECT
On 29 April 2016 at 15:40, Craig Ringer wrote:
> I don't think pg_recvlogical can do anything about the need for that dummy
> write, since the client has no way to determine the exact LSN of the commit
> record of the xact of interest. It can't rely
> on pg_current_xlog_insert_location() or pg_c
On Fri, Apr 29, 2016 at 1:37 PM, Thomas Munro wrote:
> Hi,
>
> Here is a patch to fix a typo in dsm_impl.h.
>
Applied, thanks.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Wed, Apr 27, 2016 at 4:05 PM, Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> On Tue, Apr 26, 2016 at 11:49 AM, Stephen Frost wrote:
>> > As I mentioned to Sehrope on IRC, at least for my 2c, if you want a
>> > compact JSON format to reduce the amount of traffic over the
Amit Kapila writes:
>> On Thu, Apr 28, 2016 at 10:06 PM, Tom Lane wrote:
>>> I'd be inclined to think that it's silly to build GatherPaths in advance
>>> of having finalized the list of partial paths for a rel.
> What's happening here is that to form joinrel, we need to call
> add_paths_to_joinr
On Fri, Apr 29, 2016 at 9:13 PM, Andrew Dunstan wrote:
> Yeah, I noticed the ugliness, should have fixed it. Applied your fix and
> committed.
Thanks for the commit!
Nitpick comment:
+ * Also for VS2015, add a define that stops compiler complaints about
Two spaces instead of one between "Also"
Amit Kapila writes:
> On Fri, Apr 29, 2016 at 12:01 PM, Andreas Seltenreich
> wrote:
>> tonight's sqlsmith run yielded another core dump:
>>
>> TRAP: FailedAssertion("!(MyProc->lockGroupLeader == ((void *)0))", File:
>> "proc.c", Line: 1787)
>>
>> I couldn't identifiy a query for it though: deb
On Fri, Apr 29, 2016 at 3:18 PM, Andrew Dunstan wrote:
>
> On 04/28/2016 04:29 PM, Alvaro Herrera wrote:
>
>>
>>> Actually we did have someone come up with a patch to "normalize" how
>> JSON stuff was output, because our code seems to do it in three
>> different, inconsistent ways. And our respo
Abhijit Menon-Sen writes:
> Do you want a patch along those lines now, or is it too late?
We're certainly not going to consider fooling with this in 9.6.
The situation for manual fsync-twiddling is no worse than it was in
any prior release, and we are long past feature freeze.
If you want to put
On 04/29/2016 09:29 AM, Christian Ullrich wrote:
* Andrew Dunstan wrote:
Support building with Visual Studio 2015
http://git.postgresql.org/pg/commitdiff/da52474f3d3cbdf38d8a6677a4ebedaf402ade3a
diff --git a/src/port/win32env.c b/src/port/win32env.c
index 7e4ff62..d6b0ebe 100644 (file)
--
sri harsha writes:
> Its not an OpExpr . It is a VAR , got it from "reltargetlist" in base
> relation ( RelOptInfo) .
Read the comment:
*reltargetlist - List of Var and PlaceHolderVar nodes for the values
*we need to output from this relation.
*
* Andrew Dunstan wrote:
Support building with Visual Studio 2015
http://git.postgresql.org/pg/commitdiff/da52474f3d3cbdf38d8a6677a4ebedaf402ade3a
diff --git a/src/port/win32env.c b/src/port/win32env.c
index 7e4ff62..d6b0ebe 100644 (file)
--- a/src/port/win32env.c
+++ b/src/port/win32env.c
@@ -
On 04/28/2016 04:29 PM, Alvaro Herrera wrote:
David G. Johnston wrote:
On Thu, Apr 28, 2016 at 10:00 AM, Ryan Pedela
wrote:
In addition, every JSON implementation I have ever seen fully minimizes
JSON by default. PG appears to deviate from standard practice for no
apparent reason.
Sorry to
On 29 April 2016 at 08:31, Andreas Seltenreich wrote:
> Hi,
>
> tonight's sqlsmith run yielded another core dump:
>
> TRAP: FailedAssertion("!(MyProc->lockGroupLeader == ((void *)0))", File:
> "proc.c", Line: 1787)
>
> I couldn't identifiy a query for it though: debug_query_string is empty.
> Add
On 04/29/2016 12:39 AM, Tom Lane wrote:
Andrew Dunstan writes:
latest patch attached. I have also cleaned up the docs some, and removed
references to the now redundant msysGit.
Please don't do stuff like this:
@@ -232,6 +265,10 @@ win32_langinfo(const char *ctype)
if (r != N
Amit Kapila wrote:
> On Fri, Apr 29, 2016 at 12:01 PM, Andreas Seltenreich
> wrote:
> > I couldn't identifiy a query for it though: debug_query_string is empty.
> > Additionally, the offending query was not reported in the error context
> > as it typically is for non-parallel executor crashes.
>
Hi,
Here is a patch to fix a typo in dsm_impl.h.
--
Thomas Munro
http://www.enterprisedb.com
typo.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Apr 29, 2016 at 7:25 PM, Stefan Huehner wrote:
> If you need any more info or testing done just let me know.
The information you are providing is sufficient to reproduce the
problem, thanks! I have added this bug to the list of open items for
9.6.
--
Michael
--
Sent via pgsql-hackers
On Wed, Apr 6, 2016 at 12:57:16PM +0200, Andres Freund wrote:
> Hi,
>
> While benchmarking on hydra
> (c.f.
> http://archives.postgresql.org/message-id/20160406104352.5bn3ehkcsceja65c%40alap3.anarazel.de),
> which has quite slow IO, I was once more annoyed by how incredibly long
> the vacuum at
Hello,
@Tomas put you in CC as it looks like related to work on fk -> join estimates
i did a tiny bit of testing of our software against the nightly postgresql-9.6
debs from apt.postgresql.org
Specifically against:
ii postgresql-9.6
9.6~~devel~20160428.1605-1~664.git23b0
On 28 April 2016 at 02:29, Andres Freund wrote:
>
> I don't object either, I was looking for the feature myself a number of
> times (for tap tests in my case).
>
Exactly what I want it for.
> It requires a some amount of thinking about what the limit applies to
> though. "messages sent by ser
On Fri, Apr 29, 2016 at 12:01 PM, Andreas Seltenreich
wrote:
>
> Hi,
>
> tonight's sqlsmith run yielded another core dump:
>
> TRAP: FailedAssertion("!(MyProc->lockGroupLeader == ((void *)0))", File:
"proc.c", Line: 1787)
>
> I couldn't identifiy a query for it though: debug_query_string is empty.
An interesting complement about the previous failing test:
Although I disabled the "flushing" feature...
sh> grep flush_after xxx/postgresql.conf
bgwriter_flush_after = 0# 0 disables,
backend_flush_after = 0 # 0 disables,
wal_writer_flush_after = 0 #
On Fri, Apr 29, 2016 at 8:07 AM, Robert Haas wrote:
>
> On Thu, Apr 28, 2016 at 10:06 PM, Tom Lane wrote:
> > Andreas Seltenreich writes:
> >> the following query against the regression database crashes master as
of
> >> 23b09e15.
> >
> >> select 1 from depth0 inner join depth1 on (depth0.c = de
On Fri, Apr 29, 2016 at 11:12 AM, sri harsha
wrote:
>
> Its not an OpExpr . It is a VAR , got it from "reltargetlist" in base
> relation ( RelOptInfo) . Can you shed some light on where the conversion
> from 141 to "original" attribute number takes place ??
>
If you try to print the node as *(No
77 matches
Mail list logo
