Peter Geoghegan writes:
> On Fri, Jul 31, 2015 at 5:56 PM, Andreas Seltenreich
> wrote:
>> sqlsmith triggered the following assertion in master (c188204).
>
> Thanks for writing sqlsmith. It seems like a great tool.
>
> I wonder, are you just running the tool with assertions enabled when
> Postg
On Tue, Jul 7, 2015 at 9:14 PM, Andres Freund wrote:
> On 2015-06-19 06:41:19 +, Brendan Jurd wrote:
>> I'm marking this "Waiting on Author". Once the problems have been
>> corrected, it should be ready for a committer.
>
> Vik, are you going to update the patch?
Seeing no activity on this t
On 29 July 2015 at 03:45, Heikki Linnakangas wrote:
> On 07/28/2015 04:14 AM, David Rowley wrote:
>
>> On 27 July 2015 at 20:11, Heikki Linnakangas wrote:
>>
>> On 07/27/2015 08:34 AM, David Rowley wrote:
>>>
>>> In this function I also wasn't quite sure if it was with comparing both
non-NU
On Mon, Aug 3, 2015 at 1:03 AM, Nikolay Shaplov
wrote:
> Hi!
>
> I've created a patch for pageinspect that allows to see data stored in the
> tuple.
>
> This patch has two main purposes:
>
> 1. Practical: Make manual DB recovery more simple
To what are you referring to in this case? Manual manipu
On Sat, Aug 1, 2015 at 9:20 PM, Andres Freund wrote:
> On August 1, 2015 2:17:24 PM GMT+02:00, Michael Paquier wrote:
>>> For instance, if you told me to choose between ShareLock and
>>> ShareUpdateExclusiveLock I wouldn't know which one is strongest. I
>>> don't it's sensible to have the "lock mo
On 31 July 2015 23:10, Robert Haas Wrote:
On Tue, Jul 28, 2015 at 6:01 AM, Craig Ringer wrote:
>> That should be practical to special-case by maintaining a list of
>> parent transaction (virtual?) transaction IDs. Attempts to wait on a
>> lock held by any of those should fail immediately. There
On Thu, Jul 9, 2015 at 3:48 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
> 2. New catalog - This method takes out the need to have separate method for
>>> C1, C5 and even C2, also the synchronization will be taken care of by row
>>> locks, there will be no limit on the number of f
Hi,
sorry for asking this really old commit.
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7ab9b2f3b79177e501a1ef90ed004cc68788abaf
I could not understand why "releases the lock on the buffer" is
a problem since vacuum will lock and check the page bit again before
set the vm.
On Sun, Aug 2, 2015 at 4:01 AM, Heikki Linnakangas wrote:
> Perhaps it's best if we copy all the WAL files from source in copy-mode, but
> not in libpq mode. Regarding old WAL files in the target, it's probably best
> to always leave them alone. They should do no harm, and as a general
> principle
On Sun, Aug 02, 2015 at 11:31:16PM -0400, Tom Lane wrote:
> Stephen Frost writes:
> > Noah,
> >> A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic
> >> INT/UINT or field order corrections. The non-cosmetic changes involve
> >> CustomPath, CustomScan, and CreatePolicyStmt
Stephen Frost writes:
> Noah,
>> A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic
>> INT/UINT or field order corrections. The non-cosmetic changes involve
>> CustomPath, CustomScan, and CreatePolicyStmt. Feature committers, if the
>> existing treatments (ignore custom_
On Mon, Aug 03, 2015 at 01:32:10AM +, Kouhei Kaigai wrote:
> > On Mon, Apr 16, 2012 at 06:25:15AM -0400, Noah Misch wrote:
> > > I observed these inconsistencies in node support functions:
> >
> > A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic
> > INT/UINT or field
On Thu, Jul 30, 2015 at 5:35 PM, Michael Paquier
wrote:
> Note as well that I will be fine with any decision taken by the
> committer who picks up this, this test case is useful by itself in any
> case.
And I just recalled that I actually did no tests for this thing on
Windows. As this uses the T
On Mon, Aug 3, 2015 at 1:30 AM, Tom Lane wrote:
> I haven't looked to find out why the unlinks happen in this order, but on
> a heavily loaded machine, it's certainly possible that the process would
> lose the CPU after unlink("postmaster.pid"), and then a new postmaster
> could get far enough to
> On Mon, Apr 16, 2012 at 06:25:15AM -0400, Noah Misch wrote:
> > I observed these inconsistencies in node support functions:
>
> A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic
> INT/UINT or field order corrections. The non-cosmetic changes involve
> CustomPath, Custo
On 07/15/2015 09:30 PM, Robert Haas wrote:
On Tue, Jul 14, 2015 at 5:57 PM, Jim Nasby wrote:
On 7/7/15 7:07 AM, Andres Freund wrote:
On 2015-07-03 18:03:58 -0400, Tom Lane wrote:
I have just looked through this thread, and TBH I think we should reject
this patch altogether --- not RWF, but "n
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> On Mon, Apr 16, 2012 at 06:25:15AM -0400, Noah Misch wrote:
> > I observed these inconsistencies in node support functions:
>
> A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic
> INT/UINT or field order corrections. The n
* Andres Freund (and...@anarazel.de) wrote:
> On 2015-08-01 19:13:05 -0400, Noah Misch wrote:
> > On Wed, Jul 29, 2015 at 04:42:55PM -0400, Andrew Dunstan wrote:
> > > The next hump is this, in restoring contrib_regression_test_ddl_parse:
> > >
> > >pg_restore: creating FUNCTION "public"."text
On 2015-08-02 19:06:49 -0400, Andrew Dunstan wrote:
> I'm fine with fixing it, but what's the actual use case for a long lived
> shell type?
The use-case imo is that we shouldn't just break if somebody did
something stupid or was busy creating a new type while a scheduled
backup ran.
Andres
--
On 08/02/2015 04:00 PM, Tom Lane wrote:
Andres Freund writes:
On 2015-08-01 19:13:05 -0400, Noah Misch wrote:
That's a bug. The test_ddl_deparse suite leaves a shell type, which
pg_upgrade fails to reproduce. Whether to have pg_upgrade support that or
just error out cleanly is another quest
On Sun, Aug 2, 2015 at 3:07 PM, Peter Geoghegan wrote:
> I'm surprised that this stuff was only ever used for logical decoding
> infrastructure so far.
On second thought, having tried it, one reason is that that breaks
things that are considered legitimate for historical reasons. For
example, Att
On Sun, Aug 2, 2015 at 1:28 PM, Noah Misch wrote:
> A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic
> INT/UINT or field order corrections.
I was responsible for a couple of the cosmetic ones. Sorry about that.
It occurs to me that we could do a little more to prevent
Noah Misch writes:
> On Mon, Apr 16, 2012 at 06:25:15AM -0400, Noah Misch wrote:
>> I observed these inconsistencies in node support functions:
> A fresh audit found the attached problems new in 9.5[1].
Many thanks for doing that; I'd had the same checking on my personal to-do
list, but now will
On Mon, Apr 16, 2012 at 06:25:15AM -0400, Noah Misch wrote:
> I observed these inconsistencies in node support functions:
A fresh audit found the attached problems new in 9.5[1]. Most are cosmetic
INT/UINT or field order corrections. The non-cosmetic changes involve
CustomPath, CustomScan, and C
Piotr Stefaniak writes:
> On 08/01/2015 05:59 PM, Tom Lane wrote:
>> Well, I certainly think all of these represent bugs:
>>> 1 | ERROR: could not find pathkey item to sort
> sqlsmith was able to find these two queries that trigger the error on my
> machine:
Hmm ... I see no error with these q
Andres Freund writes:
> On 2015-08-01 19:13:05 -0400, Noah Misch wrote:
>> That's a bug. The test_ddl_deparse suite leaves a shell type, which
>> pg_upgrade fails to reproduce. Whether to have pg_upgrade support that or
>> just error out cleanly is another question.
> There seems little justifi
Piotr Stefaniak writes:
> these two queries will make the assertions below fail:
> SELECT STDDEV(0.0);
> SELECT 0.0 * 0;
Fixed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
I wrote:
> Further experimentation says that 9.0-9.2 do this in the expected order;
> so somebody broke it during 9.3.
Depressingly enough, the somebody was me. Fixed now.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On 7/28/15 9:20 AM, Robert Haas wrote:
> Well, I think that we can eventually downgrade or remove the message
> once (1) we've actually fixed all of the known multixact bugs and (2)
> a couple of years have gone by and most people are in the clear.
Fair enough. But we should document this better
I wrote:
> unlink("/tmp/.s.PGSQL.5432")= 0
> unlink("postmaster.pid")= 0
> unlink("/tmp/.s.PGSQL.5432.lock") = 0
> exit_group(0) = ?
> +++ exited with 0 +++
> I haven't looked to find out why the unlinks happen in this order, but on
> a h
On 2015-08-02 12:34:43 -0400, Robert Haas wrote:
> On Sat, Aug 1, 2015 at 11:14 AM, Andres Freund wrote:
> > According to https://www.openssl.org/blog/blog/2015/08/01/cla/ openssl
> > is planning to relicense to the apache license 2.0. While APL2 is not
> > compatible with GLP2 it *is* compatible
On 2015-08-02 12:33:06 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I plan to commit the patch tomorrow, so it's included in alpha2.
>
> Please try to commit anything you want in alpha2 *today*. I'd
> prefer to see some successful buildfarm cycles on such patches
> before we wrap.
Ok, wil
On Sat, Aug 1, 2015 at 11:14 AM, Andres Freund wrote:
> According to https://www.openssl.org/blog/blog/2015/08/01/cla/ openssl
> is planning to relicense to the apache license 2.0. While APL2 is not
> compatible with GLP2 it *is* compatible with GPL3.
What's the connection to libedit?
--
Robert
Andres Freund writes:
> I plan to commit the patch tomorrow, so it's included in alpha2.
Please try to commit anything you want in alpha2 *today*. I'd
prefer to see some successful buildfarm cycles on such patches
before we wrap.
regards, tom lane
--
Sent via pgsql-ha
Observe the smoking gun at
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mule&dt=2015-08-02%2003%3A30%3A02
to wit this extract from pg_upgrade_server.log:
command:
"/home/pg/build-farm-4.15.1/build/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/install//home/pg/build-farm-4.15.1/build/HE
Hi!
I've created a patch for pageinspect that allows to see data stored in the
tuple.
This patch has two main purposes:
1. Practical: Make manual DB recovery more simple
2. Educational: Seeing what data is actually stored in tuple, allows to get
better understanding of how does postgres actual
Hi Jeff, Heikki,
On 2015-07-31 09:48:28 -0700, Jeff Janes wrote:
> I had run it for 24 hours, while it usually took less than 8 hours to look
> up before. I did see it within a few minutes one time when I checked out a
> new HEAD and then forgot to re-apply your or Heikki's patch.
>
> But now I'
On 2015-08-02 17:04:07 +0200, Andres Freund wrote:
> I've attached a version of the patch that should address Heikki's
> concern. It imo also improves the API and increases debuggability by not
> having stale variable values in the variables anymore. (also attached is
> a minor optimization that He
On 2015-08-01 19:13:05 -0400, Noah Misch wrote:
> On Wed, Jul 29, 2015 at 04:42:55PM -0400, Andrew Dunstan wrote:
> > The next hump is this, in restoring contrib_regression_test_ddl_parse:
> >
> >pg_restore: creating FUNCTION "public"."text_w_default_in("cstring")"
> >pg_restore: [archiver
Hi all,
Commit 4046e58c (dated of 2001) has introduced the following comment
in vacuumlazy.c:
+ /* If any tuples need to be deleted, perform final vacuum cycle */
+ /* XXX put a threshold on min nuber of tuples here? */
+ if (vacrelstats->num_dead_tuples > 0)
In short, we may wan
Tom Lane writes:
> Well, I certainly think all of these represent bugs:
>
>> 3 | ERROR: plan should not reference subplan's variable
>> 2 | ERROR: failed to assign all NestLoopParams to plan nodes
These appear to be related. The following query produces the former,
but if you replace
Attached patch fixes this issue. This was missed by
78efd5c1edb59017f06ef96773e64e6539bfbc86
--
Peter Geoghegan
From 47ba4759c3d460fa100f0c218b2b06834abfb3f5 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan
Date: Sun, 2 Aug 2015 02:07:55 -0700
Subject: [PATCH] Fix comment.
Commit 78efd5c1edb59017
On Fri, Jul 31, 2015 at 5:56 PM, Andreas Seltenreich wrote:
> sqlsmith triggered the following assertion in master (c188204).
Thanks for writing sqlsmith. It seems like a great tool.
I wonder, are you just running the tool with assertions enabled when
PostgreSQL is built? If so, it might make se
43 matches
Mail list logo
