At 2016-04-28 13:44:23 -0700, and...@anarazel.de wrote:
>
> Abhijit had a patch implementing automatically running fsync whenever
> reenabled IIRC. Abhijit?
The patch I had written is attached, and it's not quite the same thing.
Here's how I originally described it in response to a question from
R
On Fri, Apr 29, 2016 at 2:42 PM, 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 ??
As Tom said, you must be looking at an O
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.
Additionally, the offending query was not reported in the error context
a
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 ??
Regards,
Harsha
On Fri, Apr 29, 2016 at 10:03 AM, Tom Lane wrote:
> sri harsha writes:
> >A
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 != NULL)
sprintf(r,
sri harsha writes:
>Assume the following query ,
> (SELECT a * 1 , b FROM TABLE_1) UNION ALL (SELECT a *1 , b FROM TABLE_2);
> In this query , attribute number of the VARs are 141 and 2 respectively !!
I doubt it.
Maybe you're looking at something that's not a Var, possibly an OpExpr,
but a
On 04/25/2016 03:11 AM, Michael Paquier wrote:
On Mon, Apr 25, 2016 at 4:29 AM, Christian Ullrich wrote:
Andrew wrote:
OK, here's my final version of the patch, which I will apply in 24 hours
or so unless there is an objection.
Thanks Andrew for the updated patch!
This one doesn't matter
Hi,
Assume the following query ,
(SELECT a * 1 , b FROM TABLE_1) UNION ALL (SELECT a *1 , b FROM TABLE_2);
In this query , attribute number of the VARs are 141 and 2 respectively !!
What is the reason for this ??
I am trying to implement a FDW , so i need attribute numbers to fetch the
respe
On 29 April 2016 at 10:12, Bruce Momjian wrote:
>
> My larger question was, was 9.6 an ideal time to do this, and if so, why
> did this issue not get done. If 9.6 wasn't in some way ideal, we can do
> it in 9.7.
>
>
Doing it at the very beginning of the release cycle seems like a good idea.
I
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 = depth1.c)
>> where depth0.c @@ depth1.c limit 1;
>
> What's
On Thu, Apr 28, 2016 at 10:07:40PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Are we going to rename pg_xlog or pg_clog for 9.6?
>
> NO. We don't even have a patch for this, much less one that's been
> through any review. This suggestion is at least two months too late.
My larger quest
On Mon, Apr 18, 2016 at 03:37:21PM -0300, Alvaro Herrera wrote:
> The PostgreSQL Project needs you!
>
> The Release Management Team would like your input regarding the patch or
> patches which, in your opinion, are the most likely sources of major
> bugs or instabilities in PostgreSQL 9.6.
>
> Pl
Bruce Momjian writes:
> Are we going to rename pg_xlog or pg_clog for 9.6?
NO. We don't even have a patch for this, much less one that's been
through any review. This suggestion is at least two months too late.
regards, tom lane
--
Sent via pgsql-hackers mailing list
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 = depth1.c)
> where depth0.c @@ depth1.c limit 1;
What's going on here is that add_partial_path is recycling a now-dom
On Fri, Apr 1, 2016 at 05:55:58PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > The reason for the failure is that pg_dump knows that 9.6 installations
> > have the amtype column -- but on your older devel 9.6 install, it
> > doesn't exist. To fix it we would have to compare catalog versio
On Thu, Apr 28, 2016 at 04:30:39PM -0700, Andres Freund wrote:
> On 2016-04-28 19:23:26 -0400, Bruce Momjian wrote:
> >
> > Are we going to rename pg_xlog or pg_clog for 9.6?
>
> If we do so, we should do it at a good bit earlier in the cycle imo.
Well, we talked about it in May of 2015, but did
On 2016-04-28 19:23:26 -0400, Bruce Momjian wrote:
>
> Are we going to rename pg_xlog or pg_clog for 9.6?
If we do so, we should do it at a good bit earlier in the cycle imo.
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
Are we going to rename pg_xlog or pg_clog for 9.6?
---
On Sun, May 31, 2015 at 10:44:54PM +0200, Joel Jacobson wrote:
> On Sun, May 31, 2015 at 7:46 PM, Tom Lane wrote:
> > Hm. I think the impact on third-party backup tool
Hi,
the following query against the regression database crashes master as of
23b09e15.
select 1 from depth0 inner join depth1 on (depth0.c = depth1.c)
where depth0.c @@ depth1.c limit 1;
regards,
Andreas
Program terminated with signal SIGSEGV, Segmentation fault.
#0 create_projection_
On Wed, Apr 27, 2016 at 7:09 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Sun, Apr 24, 2016 at 3:02 PM, Sehrope Sarkuni
> wrote:
>
>> Attached is a *very* work in progress patch that adds a
>> jsonb_compact(jsonb)::text function. It generates a text representation
>> without ex
Hello everyone!
We have some issue with truncated pg_control file on Windows after power
failure.My questions is : 1) Is pg_control protected from say , power crash or
partial write? 2) How PG update pg_control? By writing in it or writing in some
temp file and after that rename it to pg_control
On 2016-04-28 21:32:37 +0200, Simon Riggs wrote:
> On 27 April 2016 at 17:04, Craig Ringer wrote:
>
> > On 27 April 2016 at 21:44, Tom Lane wrote:
> >
> >> Petr Jelinek writes:
> >> > +1 (Abhijit's wording with data loss changed to data corruption)
> >>
> >> I'd suggest something like
> >>
> >>
On 28 April 2016 at 22:30, David G. Johnston
wrote:
> On Thursday, April 28, 2016, Simon Riggs wrote:
>
>> On 27 April 2016 at 17:04, Craig Ringer wrote:
>>
>>> On 27 April 2016 at 21:44, Tom Lane wrote:
>>>
Petr Jelinek writes:
> +1 (Abhijit's wording with data loss changed to data
On Thursday, April 28, 2016, Simon Riggs wrote:
> On 27 April 2016 at 17:04, Craig Ringer > wrote:
>
>> On 27 April 2016 at 21:44, Tom Lane > > wrote:
>>
>>> Petr Jelinek >> > writes:
>>> > +1 (Abhijit's wording with data loss changed to data corruption)
>>>
>>> I'd suggest something like
>>>
>>
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 nit-pick but that's called conv
createdb: database creation failed: ERROR: checkpoint request failed
HINT: Consult recent messages in the server log for details.
Attached is a simpler/faster version, based on the previous script, I just
added a CHECKPOINT after the EXPLAIN ANALYSE.
It fails on head with:
HINT: Consid
On 27 April 2016 at 17:04, Craig Ringer wrote:
> On 27 April 2016 at 21:44, Tom Lane wrote:
>
>> Petr Jelinek writes:
>> > +1 (Abhijit's wording with data loss changed to data corruption)
>>
>> I'd suggest something like
>>
>> #fsync = on # flush data to disk for cra
On Wed, Apr 27, 2016 at 10:58 AM, Craig Ringer wrote:
> Now, we can't rename fsync to disable_crash_safety=on or
> corrupt_my_database=on. But the comment needs changing.
Fwiw we've done similar things in the past. We can provide
backwards-compatibility support for "fsync" but make the setting
a
On Wed, Apr 27, 2016 at 05:05:18PM -0400, 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 traff
On Thu, Apr 28, 2016 at 10:00 AM, Ryan Pedela
wrote:
> On Tue, Apr 26, 2016 at 10:49 AM, Stephen Frost
> wrote:
>
>> * Ryan Pedela (rped...@datalanche.com) wrote:
>> > On Sun, Apr 24, 2016 at 4:02 PM, Sehrope Sarkuni
>> wrote:
>> > > The default text representation of jsonb adds whitespace in b
On Tue, Apr 26, 2016 at 10:49 AM, Stephen Frost wrote:
> * Ryan Pedela (rped...@datalanche.com) wrote:
> > On Sun, Apr 24, 2016 at 4:02 PM, Sehrope Sarkuni
> wrote:
> > > The default text representation of jsonb adds whitespace in between
> > > key/value pairs (after the colon ":") and after suc
On 2016-04-28 17:41:29 +0100, Thom Brown wrote:
> I've noticed another breakage, which I can reproduce consistently.
>
> createdb pgbench
> pgbench -i -s 100 --unlogged-tables pgbench
> psql -f pgbench_partitions.sql pgbench
> vacuumdb -z pgbench
> createdb test
>
> Which produces:
>
> createdb:
Robert Haas writes:
> I compared the result of running pgindent with the typedefs.list file
> as updated by me manually with the result of running pgindent using
> the buildfarm list and ... the buildfarm list is better. Shows what I
> know. Should we go ahead and commit the current version of t
Bruce Momjian writes:
> On Sun, Mar 27, 2016 at 05:14:44PM -0400, Tom Lane wrote:
>> A note about comparing this to upstream: I found that the best
>> way to do that was to run the IANA source files through a sed
>> filter like this: ...
> Is this documented for use next time?
Yes, see the READM
On Wed, Apr 27, 2016 at 1:05 PM, Daniel Verite wrote:
> Robert Haas wrote:
>> Of course, we could make this value 1-based rather than 0-based, as
>> Peter Geoghegan suggested a while back. But as I think I said at the
>> time, I think that's more misleading than helpful. The leader
>> pa
On Thu, Apr 28, 2016 at 7:39 AM, Bruce Momjian wrote:
> On Wed, Apr 27, 2016 at 11:38:57PM -0400, Robert Haas wrote:
>> > On what grounds do you claim the buildfarm result is unstable?
>> > I've been using that for a long time and it works fine. Moreover,
>> > ignoring that data is a bad idea bec
I think this number should be specified only once, in .h file.
Yep, that sounds true.
It may be a good idea to make something similar for contrib/bloom if >
0 values are defined for amstrategies or amsupport for consistency.
Thank you, pushed.
--
Teodor Sigaev
The more I think about it, the more I think gin is just an innocent
bystander, for which I just happen to have a particularly demanding
test. I think something about snapshots and wrap-around may be
broken.
After 10 hours of running I've got
1587 XX000 2016-04-28 05:57:09.964 MSK:ERROR: unexp
While doing some archaeology I came across a couple of macros in pgstattuple
and pageinspect contrib code which seems to have been unused for some time.
CHECK_PAGE_OFFSET_RANGE is unused in both modules and commit 6405842 which
introduced contrib/pageinspect moved the code making CHECK_RELATION_BLO
On Tue, Apr 26, 2016 at 10:17 PM, Nikolay Shaplov
wrote:
> While working with postgres code, I found that for gist index number of
> amsupport procs are defined two times. First in src/include/access/gist.h
>
> #define GISTNProcs 9
>
> and second in src/backend/access/gist/gist.c
On 2016/03/14 17:56, Ashutosh Bapat wrote:
On Mon, Mar 14, 2016 at 1:29 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
/*
* Build the fdw_private list that will be available to the
executor.
* Items in the list must match order in enum FdwScanPri
On Sun, Mar 27, 2016 at 05:14:44PM -0400, Tom Lane wrote:
> Well, that was just about as tedious as I feared it might be, but
> attached is a patch for $SUBJECT. We should apply this, and
> probably eventually back-patch it, but it'd be wise to let it
> age awhile in HEAD first. Is anyone interes
On Wed, Apr 27, 2016 at 11:38:57PM -0400, Robert Haas wrote:
> > On what grounds do you claim the buildfarm result is unstable?
> > I've been using that for a long time and it works fine. Moreover,
> > ignoring that data is a bad idea because it reflects platform-specific
> > variations in the set
Hello,
At Wed, 27 Apr 2016 18:05:26 -0400, Tom Lane wrote in
<3167.1461794...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > Sorry, I have attached an empty patch. This is another one that should
> > be with content.
>
> I pushed this after whacking it around some, and cleaning up some
> sort-
[Cc'ing -hackers]
I said:
> That said, there's a build failure on s390x:
>
> https://buildd.debian.org/status/fetch.php?pkg=citus&arch=s390x&ver=5.0.1-1&stamp=1461670278
>
> gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
> -Wendif-labels -Wmissing-format-attribute
* Michael Paquier wrote:
On Wed, Apr 27, 2016 at 5:15 PM, Christian Ullrich wrote:
OK then, hopefully last round attached.
Thanks. Those are fine in my view. It is hard to tell if a committer
is going to have a look at that soon, so I think that it would be
wiser to add that to the next CF s
46 matches
Mail list logo
