Re: [HACKERS] statistics for shared catalogs not updated when autovacuum is off

On Wed, May 25, 2016 at 05:50:41PM -0400, Tom Lane wrote: > I wrote: > > OK. I'm going to work on replacing the DBWriteRequest structure with > > an OID list, and on improving the comments some more, but I don't > > anticipate further functional changes. > > Here's the end result of that. You

Re: [HACKERS] ORDER/GROUP BY expression not found in targetlist

On Wed, May 25, 2016 at 7:12 PM, Andres Freund wrote: > > =# CREATE TABLE twocol(col01 int, col02 int); > =# SELECT DISTINCT col01, col02, col01 FROM twocol ; > ERROR: XX000: ORDER/GROUP BY expression not found in targetlist > LOCATION: get_sortgroupref_tle, tlist.c:341 > >

[HACKERS] ORDER/GROUP BY expression not found in targetlist

Hi, trying to reproduce a performance problem I just found: =# CREATE TABLE twocol(col01 int, col02 int); =# SELECT DISTINCT col01, col02, col01 FROM twocol ; ERROR: XX000: ORDER/GROUP BY expression not found in targetlist LOCATION: get_sortgroupref_tle, tlist.c:341 which appears to be a 9.6

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

At Wed, 25 May 2016 10:11:28 -0400, Tom Lane wrote in <24577.1464185...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > I tried it on Windows 7/64 but first of all, I'm surprised to see > > that the following command line gets an error but it

Re: [HACKERS] Deleting prepared statements from libpq.

On 25 May 2016 at 18:05, Dmitry Igrishin wrote: > Hello, > > According to > > https://www.postgresql.org/docs/current/static/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY > there are Close message for closing prepared statements or portals, but > according to > >

Re: [HACKERS] Inheritance

On 26 May 2016 at 01:56, Jim Nasby wrote: > On 5/24/16 8:52 PM, Craig Ringer wrote: > > Absolutely, and I use OO heavily. But a half-assed "object relational" > > feature in the database that only kind-of works isn't OO, and it's > > generally less useful than using

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

Andres Freund writes: > Might be worthwhile to look into 'uncrustify'. It's fairly > customizable. A colleague at citus made all citus code be formatted by > it; and while there's some minor details I dislike, it seems to work > ok. Hmm ... a quick look says that it's been

Re: [HACKERS] [BUGS] BUG #13473: VACUUM FREEZE mistakenly cancel standby sessions

Marco Nenciarini wrote: > diff --git a/src/backend/access/heap/heapam.c > b/src/backend/access/heap/heapam.c > index eb8eada..434880a 100644 > --- a/src/backend/access/heap/heapam.c > +++ b/src/backend/access/heap/heapam.c > @@ -4764,7 +4764,13 @@ heap_xlog_freeze(XLogRecPtr lsn, XLogRecord

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

Alvaro Herrera writes: > Andres Freund wrote: >> On 2016-05-25 22:01:53 +0200, Piotr Stefaniak wrote: >>> On 2016-05-25 21:13, Tom Lane wrote: I'd love to see a fix for its brain damage around function pointer typedef formatting, too. >>> Show me a few

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

On 2016-05-25 18:17:51 -0400, Alvaro Herrera wrote: > Andres Freund wrote: > > On 2016-05-25 22:01:53 +0200, Piotr Stefaniak wrote: > > FWIW, I looked at using clang-format at some point, and it looked like > > it'd be a number of additional options to make it work for our case > > without

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

Andres Freund wrote: > On 2016-05-25 22:01:53 +0200, Piotr Stefaniak wrote: > > On 2016-05-25 21:13, Tom Lane wrote: > > > I'd love to see a fix for its brain damage around function pointer > > > typedef formatting, too. > > > > Show me a few examples and I'll look into it. See

Re: [HACKERS] statistics for shared catalogs not updated when autovacuum is off

I wrote: > OK. I'm going to work on replacing the DBWriteRequest structure with > an OID list, and on improving the comments some more, but I don't > anticipate further functional changes. Here's the end result of that. I went ahead and pushed the original small patch, concluding that that was

Re: [HACKERS] Is the unfair lwlock behavior intended?

On 2016-05-25 17:24:22 -0400, Robert Haas wrote: > On Wed, May 25, 2016 at 3:26 PM, Andres Freund wrote: > > On 2016-05-25 11:15:37 -0700, Andres Freund wrote: > >> On 2016-05-25 14:09:43 -0400, Robert Haas wrote: > >> I don't think anybody was doing that? The first questions

Re: [HACKERS] Is the unfair lwlock behavior intended?

On Wed, May 25, 2016 at 3:26 PM, Andres Freund wrote: > On 2016-05-25 11:15:37 -0700, Andres Freund wrote: >> On 2016-05-25 14:09:43 -0400, Robert Haas wrote: >> I don't think anybody was doing that? The first questions on this thread >> were about upgrading and retesting... >

Re: [HACKERS] Changed SRF in targetlist handling

Andres Freund writes: > On 2016-05-25 15:20:03 -0400, Tom Lane wrote: >> We could certainly make a variant behavior in nodeFunctionscan.c that >> emulates that, if we feel that being exactly bug-compatible on the point >> is actually what we want. I'm dubious about that

Re: [HACKERS] Changed SRF in targetlist handling

On 2016-05-25 15:20:03 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-05-25 15:02:23 -0400, Tom Lane wrote: > >> [ shrug... ] That seems like it's morally equivalent to (but uglier than) > >> what I wanted to do, which is to teach the planner to rewrite the query

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

On 2016-05-25 22:01:53 +0200, Piotr Stefaniak wrote: > On 2016-05-25 21:13, Tom Lane wrote: > > I'd love to see a fix for its brain damage around function pointer typedef > > formatting, too. > > Show me a few examples and I'll look into it. > > > I'm excited about this too, not least because

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

On 2016-05-25 21:13, Tom Lane wrote: I'd love to see a fix for its brain damage around function pointer typedef formatting, too. Show me a few examples and I'll look into it. I'm excited about this too, not least because it suggests that maybe bsdindent isn't quite as opaque as it appears.

Re: [HACKERS] statistics for shared catalogs not updated when autovacuum is off

Michael Paquier writes: > On Tue, May 24, 2016 at 3:52 PM, Tom Lane wrote: >> True, although I'm not sure if adding a dependency on IsSharedRelation() >> here is a good thing. In any case, you took the dependency too far ... > OK. It seemed more

Re: [HACKERS] statistics for shared catalogs not updated when autovacuum is off

On Tue, May 24, 2016 at 3:52 PM, Tom Lane wrote: > Michael Paquier writes: >> At the same time I am not getting why pgstat_fetch_stat_tabentry needs >> to be that complicated. Based on the relation OID we can know if it is >> a shared relation or

Re: [HACKERS] [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind

On Wed, May 25, 2016 at 3:03 PM, Alvaro Herrera wrote: > > Nikolay Shaplov wrote: > > В письме от 25 мая 2016 13:25:38 Вы написали: > > > Teodor Sigaev wrote: > > > > >This all should me moved behind "access method" abstraction... > > > > > > > > +1 relopt_kind should be

Re: [HACKERS] Is the unfair lwlock behavior intended?

Hi, On 2016-05-24 06:03:07 +, Tsunakawa, Takayuki wrote: > At that time, many backend processes (I forgot the number) were acquiring and > releasing share mode lock on ProcArrayLock, most of which were from > TransactionIsInProgress(). FWIW, I suspect that 9.6 might be a fair bit better

Re: [HACKERS] Is the unfair lwlock behavior intended?

On 2016-05-25 11:15:37 -0700, Andres Freund wrote: > On 2016-05-25 14:09:43 -0400, Robert Haas wrote: > I don't think anybody was doing that? The first questions on this thread > were about upgrading and retesting... Something I've repeatedly wondered about around this topic is whether we could

Re: [HACKERS] Changed SRF in targetlist handling

Andres Freund writes: > On 2016-05-25 15:02:23 -0400, Tom Lane wrote: >> [ shrug... ] That seems like it's morally equivalent to (but uglier than) >> what I wanted to do, which is to teach the planner to rewrite the query to >> put the SRFs into a lateral FROM item.

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

Robert Haas writes: > On Sun, May 22, 2016 at 4:16 PM, Piotr Stefaniak > wrote: >> I think I've managed to improve pg_bsd_indent's handling of two types of >> cases. > Wow, that seems pretty great. I haven't scrutinized your changes to >

Re: [HACKERS] PATCH: pg_restore parallel-execution-deadlock issue

On Fri, Apr 8, 2016 at 2:24 AM, Michael Paquier wrote: > On Tue, Apr 5, 2016 at 9:28 AM, Armin Schöffmann > wrote: >> If this is not the correct place to discuss patches, I'd be glad if somebody >> can notify the tool's maintainer, to

Re: [HACKERS] Changed SRF in targetlist handling

On 2016-05-25 15:02:23 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-05-23 13:10:29 -0400, Tom Lane wrote: > >> Would that not lead to, in effect, duplicating all of execQual.c? The new > >> executor node would still have to be prepared to process all expression

Re: [HACKERS] Changed SRF in targetlist handling

Andres Freund writes: > On 2016-05-23 13:10:29 -0400, Tom Lane wrote: >> Would that not lead to, in effect, duplicating all of execQual.c? The new >> executor node would still have to be prepared to process all expression >> node types. > I don't think it necessarily has to.

Re: [HACKERS] Changed SRF in targetlist handling

On 2016-05-23 13:10:29 -0400, Tom Lane wrote: > Andres Freund writes: > > One idea I circulated was to fix that by interjecting a special executor > > node to process SRF containing targetlists (reusing Result possibly?). > > That'd allow to remove the isDone argument from

Re: [HACKERS] statistics for shared catalogs not updated when autovacuum is off

I wrote: > In short, I think the attached is enough to fix it. There's some cosmetic > cleanup that could be done here: a lot of these functions could use better > comments, and I'm not happy about the autovac launcher depending on > MyDatabaseId being zero. But those are not functional

Re: [HACKERS] Is the unfair lwlock behavior intended?

On 2016-05-25 14:09:43 -0400, Robert Haas wrote: > I think this is looking at the problem from the wrong angle. The OP's > complaint is pretty fair: a 30-second wait for ProcArrayLock is > horrendous, and if that's actually something that is happening with > any significant regularity on

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

On Sun, May 22, 2016 at 4:16 PM, Piotr Stefaniak wrote: > I think I've managed to improve pg_bsd_indent's handling of two types of > cases. Wow, that seems pretty great. I haven't scrutinized your changes to pg_bsd_indent, but effect_on_pg.diff looks like a large

Re: [HACKERS] Is the unfair lwlock behavior intended?

On Tue, May 24, 2016 at 6:50 PM, Andres Freund wrote: > Now we potentially could mark individual lwlocks as being fair > locks. But which ones would those be? Certainly not ProcArrayLock, it's > way too heavily contended. I think this is looking at the problem from the wrong

Re: [HACKERS] [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind

Nikolay Shaplov wrote: > В письме от 25 мая 2016 13:25:38 Вы написали: > > Teodor Sigaev wrote: > > > >This all should me moved behind "access method" abstraction... > > > > > > +1 relopt_kind should be moved in am, at least. Or removed. > > > > Hm, but we have tablespace options too, so I'm not

Re: [HACKERS] Inheritance

On 5/24/16 8:52 PM, Craig Ringer wrote: > Absolutely, and I use OO heavily. But a half-assed "object relational" > feature in the database that only kind-of works isn't OO, and it's > generally less useful than using existing relational-to-oo modelling > techniques like FK-related 1:1 child

Re: [HACKERS] Deleting prepared statements from libpq.

2016-05-25 16:50 GMT+03:00 Tom Lane : > Dmitry Igrishin writes: > > "there is no libpq function for deleting a prepared statement". > > Could you tell me please, what is the reason for this? > > You don't really need one, since you can just use DEALLOCATE.

Re: [HACKERS] Does people favor to have matrix data type?

On 5/25/16 7:46 AM, Kouhei Kaigai wrote: My only concern is that domain type is not allowed to define type cast. If we could add type cast on domain, we can define type transformation from other array type to matrix. I've actually wished for that in the past, as well as casting to compound

Re: [HACKERS] [BUGS] BUG #13473: VACUUM FREEZE mistakenly cancel standby sessions

On 27/06/15 01:13, Jim Nasby wrote: > On 6/26/15 8:50 AM, Marco Nenciarini wrote: >>> >In the heap_xlog_freeze we need to subtract one to the value of >>> cutoff_xid >>> >before passing it to ResolveRecoveryConflictWithSnapshot. >>> > >>> > >>> > >> Attached a proposed patch that solves the issue.

Re: [HACKERS] [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind

В письме от 25 мая 2016 13:25:38 Вы написали: > Teodor Sigaev wrote: > > >This all should me moved behind "access method" abstraction... > > > > +1 relopt_kind should be moved in am, at least. Or removed. > > Hm, but we have tablespace options too, so I'm not sure that using AM as > abstraction

Re: [HACKERS] [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind

Teodor Sigaev wrote: > >This all should me moved behind "access method" abstraction... > > +1 relopt_kind should be moved in am, at least. Or removed. Hm, but we have tablespace options too, so I'm not sure that using AM as abstraction level is correct. -- Álvaro Herrera

Re: [HACKERS] To-Do item: skip table scan for adding column with provable check constraints

On 5/24/16 9:56 PM, Craig Ringer wrote: On 25 May 2016 at 06:56, Tom Lane > wrote: ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > Tom Lane

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618

On Wed, May 25, 2016 at 12:11 AM, Amit Kapila wrote: > On Tue, May 17, 2016 at 2:31 AM, Michael Paquier > wrote: >> >> On Tue, May 17, 2016 at 4:16 AM, Amit Kapila >> wrote: >> > On Mon, May 16, 2016 at 9:45 AM,

Re: [HACKERS] Does people favor to have matrix data type?

Kouhei Kaigai writes: > The 'matrix' data type as domain type of real[] is an option to implement. > We can define operators on the domain types, thus, it allows us to process > large amount of calculation by one operation, in native binary speed. Don't go that way, it will

Re: [HACKERS] pg_dump -j against standbys

Magnus Hagander writes: >> Also, why didn't you keep using ExecuteSqlQueryForSingleRow()? > The reason I did that is that ExecuteSqlQueryForSingleRow() is a static > method in pg_dump.c. I was planning to go back and review that, and > consider moving it, but I forgot it :S

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

Kyotaro HORIGUCHI writes: > I tried it on Windows 7/64 but first of all, I'm surprised to see > that the following command line gets an error but it would be > fine because it is consistent with what is written in the manual. > | >pg_dump

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

Jeff Janes writes: > Given what a Bloom filter is/does, I'm having a hard time seeing how it > makes much sense to support the boolean type. > My biggest gripe with it at the moment is that the signature size should be > expressed in bits, and then internally rounded up to

Re: [HACKERS] pg_dump -j against standbys

On 25/05/16 15:59, Magnus Hagander wrote: On Tue, May 24, 2016 at 5:39 PM, Tom Lane wrote: This patch will cause pg_dump to fail entirely against pre-9.0 servers. You need to execute the test conditionally. Ugh. can I blame coding while too jetlagged? You could try

Re: [HACKERS] pg_dump -j against standbys

On Tue, May 24, 2016 at 5:39 PM, Tom Lane wrote: > Magnus Hagander writes: > > I think the cleanest way to do it is to just track if it's a standby in > the > > AH struct as written. > > > Comments? > > This patch will cause pg_dump to fail entirely

Re: [HACKERS] Deleting prepared statements from libpq.

Dmitry Igrishin writes: > "there is no libpq function for deleting a prepared statement". > Could you tell me please, what is the reason for this? You don't really need one, since you can just use DEALLOCATE. regards, tom lane -- Sent via

Re: [HACKERS] [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind

This all should me moved behind "access method" abstraction... +1 relopt_kind should be moved in am, at least. Or removed. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- Sent via

Re: [HACKERS] Does people favor to have matrix data type?

On Wed, May 25, 2016 at 09:10:02AM +, Kouhei Kaigai wrote: > > -Original Message- > > From: Simon Riggs [mailto:si...@2ndquadrant.com] > > Sent: Wednesday, May 25, 2016 4:39 PM > > To: Kaigai Kouhei(海外 浩平) > > Cc: pgsql-hackers@postgresql.org > > Subject: Re: [HACKERS] Does people

Re: [HACKERS] Inheritance

On Tue, May 24, 2016 at 9:47 PM, Craig Ringer wrote: > On 24 May 2016 at 22:45, Konstantin Knizhnik > wrote: >> >> There is one aspect of inheritance support which was not mentioned: >> polymorphic queries. >> Actually polymorphism is the

Re: [HACKERS] Does people favor to have matrix data type?

> On Wed, May 25, 2016 at 10:38 AM, Simon Riggs wrote: > > On 25 May 2016 at 03:52, Kouhei Kaigai wrote: > >> > >> In a few days, I'm working for a data type that represents matrix in > >> mathematical area. Does people favor to have this data type in

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

On May 24, 2016 5:27 PM, "David G. Johnston" wrote: > > Moving my griping to -hackers only > > On Tue, May 24, 2016 at 8:08 PM, Tom Lane wrote: >> >> dig...@126.com writes: >> > postgres=# create unlogged table u_tbl (id int); >> > CREATE TABLE >>

Re: [HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

I wrote: > Re-fuzzing now with your patch applied. This so far yielded three BRIN core dumps on different machines with the same backtraces. Crash recovery fails in these cases. I've put the data directory here (before recovery): http://ansel.ydns.eu/~andreas/brincrash2-spidew.tar.xz

Re: [HACKERS] Does people favor to have matrix data type?

> -Original Message- > From: Simon Riggs [mailto:si...@2ndquadrant.com] > Sent: Wednesday, May 25, 2016 4:39 PM > To: Kaigai Kouhei(海外 浩平) > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Does people favor to have matrix data type? > > On 25 May 2016 at 03:52, Kouhei Kaigai

Re: [HACKERS] Does people favor to have matrix data type?

On Wed, May 25, 2016 at 10:38 AM, Simon Riggs wrote: > On 25 May 2016 at 03:52, Kouhei Kaigai wrote: >> >> In a few days, I'm working for a data type that represents matrix in >> mathematical area. Does people favor to have this data type in the core,

[HACKERS] Deleting prepared statements from libpq.

Hello, According to https://www.postgresql.org/docs/current/static/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY there are Close message for closing prepared statements or portals, but according to https://www.postgresql.org/docs/current/static/libpq-exec.html#LIBPQ-PQPREPARE "there is no libpq

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

At Wed, 25 May 2016 00:15:57 -0400, Tom Lane wrote in <3149.1464149...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > Shouldn't archive_close_connection have an assertion (si->AHX != > > NULL) instead of checking "if (si->AHX)" in each path?

Re: [HACKERS] Does people favor to have matrix data type?

On 25 May 2016 at 03:52, Kouhei Kaigai wrote: > In a few days, I'm working for a data type that represents matrix in > mathematical area. Does people favor to have this data type in the core, > not only my extension? > If we understood the use case, it might help

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618

On Tue, May 17, 2016 at 2:31 AM, Michael Paquier wrote: > > On Tue, May 17, 2016 at 4:16 AM, Amit Kapila wrote: > > On Mon, May 16, 2016 at 9:45 AM, Michael Paquier < michael.paqu...@gmail.com> > > wrote: > >> > >> On Sun, May 15, 2016 at 3:34

Re: [HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

I wrote: > Alvaro Herrera writes: >> How long does it take for you to reproduce this panic in the unpatched >> code? > > I could probably speed it up by creating lots of additional BRIN indexes > in the regression database, and by compiling a sqlsmith that generates > update statements only. This