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

> Sounds reasonable. I look into this further. I looked into that and found one problem in the patch. > Next, I got the following behavior for the following command, > then freeze. Maybe stopping at the same point with the next > paragraph but I'm not sure. The same thing occurs this patch on > t

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 ma

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 > > which appears to be a

[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 r

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 would be > > fine because it is consistent with what i

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 > > https://www.postgresql.org/docs/curr

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 existing relational-to-oo mode

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 around for awhile and

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 *reco

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 examples and I'll look into it.

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 changing

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 src/include/repli

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 f

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 on this thread > >> w

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... > > Something I've rep

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 though, not least >> becau

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 to > >> put the SRFs

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 it

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 simple to me to have the dependency on catalog.h

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 not, there is no point in doing two times the >> s

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 moved in am, at least. Or

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 her

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 sp

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. Splitting the tlist into two

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 > pg_bsd_indent, but effect_on_pg.diff looks like a large i

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 take a look into it. > > Here or -bugs are correct places 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 > >> node types. > >

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. ISTM that if we add

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 ExecEval*/ExecProject* >

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 problems.

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 well-conf

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 improvement. -- Robert Haas En

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 angle. The OP's comp

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 tables

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. > Yes, but there are also Parse(F) messa

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 typ

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 l

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 Herrerahttp://w

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 mailto:t...@sss.pgh.pa.us>> wrote: ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > Tom Lane mailto:t...@sss.pgh.pa.us>> writes: >> ... and if the CHECK exp

[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, Michael Paquier >> > >> > wrote: >> >> >> >> On Sun, May 15, 2016 at 3:34 PM, Amit

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 cause you nothing but

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 > I think the clean t

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 postgres://horiguti:hoge@localhost/postgres --jobs=9 -Fd -

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 a multiple of 16, > rat

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 blaming Magnus. Oh, wai

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 against pre-9.0 servers. > You need to execute

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 pgsql-hackers mailing list (pg

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 pgsq

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 favor

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 fundamental feature of OOP, without it there >> is no beha

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, > >> not only my extension? > > > >

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 >> > postgres=# create index idx_u_tbl on u_tbl usin

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 (9.1M

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 wro

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, >> not only my extension? > > > If we underst

[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 funct

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? > > I thought about that but didn't see any really go

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 understand whether to include it

[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 PM, Amit Kapila > >> wrote: > >> > Sounds sensible,