Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

2017-10-22 Thread Haribabu Kommi
On Sun, Oct 22, 2017 at 3:08 AM, Robert Haas wrote: > On Sat, Oct 21, 2017 at 1:30 AM, Haribabu Kommi > wrote: > > Before refactoring, pg_dumpall doesn't print "create database" commands > > for both tempalte1 and postgres database, but on the

Re: [HACKERS] legitimacy of using PG_TRY , PG_CATCH , PG_END_TRY in C function

2017-10-22 Thread Tom Lane
John Lumby writes: > I have a C function (a trigger function) which uses the PG_TRY() > construct to handle certain ERROR conditions. > One example is where invoked as INSTEAD OF INSERT into a view. It > PG_TRYs INSERT into the real base table, > but this table may not

Re: [HACKERS] alter table doc fix

2017-10-22 Thread Amit Langote
On 2017/10/18 20:37, Alvaro Herrera wrote: > Amit Langote wrote: >> Hi. >> >> Noticed that a alter table sub-command's name in Description (where it's >> OWNER) differs from that in synopsis (where it's OWNER TO). Attached >> patch to make them match, if the difference is unintentional. > > I

Re: [HACKERS] Block level parallel vacuum WIP

2017-10-22 Thread Amit Langote
On 2017/10/22 5:25, Thomas Munro wrote: > On Sun, Oct 22, 2017 at 5:09 AM, Robert Haas wrote: >> On Tue, Sep 19, 2017 at 3:31 AM, Masahiko Sawada >> wrote: Down at the bottom of the build log in the regression diffs file you can see:

[HACKERS] legitimacy of using PG_TRY , PG_CATCH , PG_END_TRY in C function

2017-10-22 Thread John Lumby
I have a C function (a trigger function) which uses the PG_TRY() construct to handle certain ERROR conditions. One example is where invoked as INSTEAD OF INSERT into a view. It PG_TRYs INSERT into the real base table, but this table may not yet exist (it is a partitioned child of an

[HACKERS] Re: [BUGS] BUG #14849: jsonb_build_object doesn't like VARIADIC calls very much

2017-10-22 Thread Michael Paquier
On Mon, Oct 23, 2017 at 6:11 AM, Tom Lane wrote: > This comment is neither correct nor intelligible: > > /* important for value, key cannot being NULL */ > > I'd say just drop it. Yep. > The checks for "could not determine data type" errors seem > rather duplicative,

Re: [HACKERS] How to determine that a TransactionId is really aborted?

2017-10-22 Thread Eric Ridge
> On Oct 22, 2017, at 3:24 PM, Peter Geoghegan wrote: > > On Sun, Oct 22, 2017 at 2:19 PM, Eric Ridge wrote: >> I'm looking for the status as any concurrent open transaction might see it. >> For example, if any concurrent transaction might see it as "in

Re: [HACKERS] How to determine that a TransactionId is really aborted?

2017-10-22 Thread Peter Geoghegan
On Sun, Oct 22, 2017 at 2:19 PM, Eric Ridge wrote: > I'm looking for the status as any concurrent open transaction might see it. > For example, if any concurrent transaction might see it as "in progress", > that's what I'd want returned. Does that make sense? Maybe, but

Re: [HACKERS] How to determine that a TransactionId is really aborted?

2017-10-22 Thread Eric Ridge
> On Oct 22, 2017, at 2:50 PM, Jaime Casanova > wrote: > > so, what you want is txid_status() [1]... while this is new in v10 you > can use the code as guide or just migrate to v10 ;) Oh neat, thanks. Doesn't that tell you the status relative to the

Re: [HACKERS] [BUGS] BUG #14849: jsonb_build_object doesn't like VARIADIC calls very much

2017-10-22 Thread Tom Lane
Andrew Dunstan writes: > Sorry. Here it is. This comment is neither correct nor intelligible: /* important for value, key cannot being NULL */ I'd say just drop it. The checks for "could not determine data type" errors seem rather duplicative, too.

Re: [HACKERS] How to determine that a TransactionId is really aborted?

2017-10-22 Thread Jaime Casanova
On 22 October 2017 at 15:00, Eric Ridge wrote: >> On Oct 22, 2017, at 1:50 PM, Peter Geoghegan wrote: >> >> On Sun, Oct 22, 2017 at 12:23 PM, Eric Ridge wrote: >>> Can anyone confirm or deny that this is correct? I feel like it is >>> correct,

[HACKERS] Re: [BUGS] BUG #14849: jsonb_build_object doesn't like VARIADIC calls very much

2017-10-22 Thread Andrew Dunstan
On 10/22/2017 04:35 PM, Michael Paquier wrote: > On Mon, Oct 23, 2017 at 1:44 AM, Andrew Dunstan > wrote: > >> here's a patch that works that way, based on Michael's code. > Patch not attached :) > I still have a patch half-cooked, that I can send if necessary,

[HACKERS] Re: [BUGS] BUG #14849: jsonb_build_object doesn't like VARIADIC calls very much

2017-10-22 Thread Michael Paquier
On Mon, Oct 23, 2017 at 1:44 AM, Andrew Dunstan wrote: > > > On 10/22/2017 12:11 PM, Andrew Dunstan wrote: >> >> On 10/21/2017 07:33 PM, Michael Paquier wrote: >>> On Sun, Oct 22, 2017 at 1:43 AM, Tom Lane wrote: I don't think collecting

Re: [HACKERS] How to determine that a TransactionId is really aborted?

2017-10-22 Thread Eric Ridge
> On Oct 22, 2017, at 1:50 PM, Peter Geoghegan wrote: > > On Sun, Oct 22, 2017 at 12:23 PM, Eric Ridge wrote: >> Can anyone confirm or deny that this is correct? I feel like it is correct, >> but I'm no expert. > > What are you going to use the code for? I

Re: [HACKERS] How to determine that a TransactionId is really aborted?

2017-10-22 Thread Peter Geoghegan
On Sun, Oct 22, 2017 at 12:23 PM, Eric Ridge wrote: > Can anyone confirm or deny that this is correct? I feel like it is correct, > but I'm no expert. What are you going to use the code for? I think that that context is likely to matter here. -- Peter Geoghegan -- Sent

[HACKERS] How to determine that a TransactionId is really aborted?

2017-10-22 Thread Eric Ridge
When sitting inside an extension, and given an arbitrary TransactionId, how can you determine that it aborted/crashed *and* that no other active transaction thinks it is still running? I've tried to answer this question myself (against the 9.3 sources), and it seems like it's just: {

Re: [HACKERS] Useless(?) asymmetry in parse_func.c

2017-10-22 Thread Tom Lane
I wrote: > While running down loose ends in my domains-over-composite patch, > I wondered why parse_func.c's FuncNameAsType() excludes composite > types as possible type names. > ... > There might still be an argument for rejecting the case on the grounds > that it's confusing or likely to be user

Re: [HACKERS] Discussion on missing optimizations

2017-10-22 Thread Andreas Seltenreich
Alvaro Herrera writes: > Andres Freund wrote: >> Unfortunately it won't help in this specific case (no support for UNION, >> just UNION ALL), but I thought it might be interesting to reference >> https://medium.com/@uwdb/introducing-cosette-527898504bd6 >> here. > > Interesting. I thought about

Re: [HACKERS] [sqlsmith] Failed assertion in adjust_appendrel_attrs_mutator

2017-10-22 Thread Tom Lane
Andreas Seltenreich writes: > testing master as of 7c981590c2, sqlsmith just triggered the following > assertion: > TRAP: FailedAssertion("!(!const Node*)(node))->type) == T_SubLink))", > File: "prepunion.c", Line: 2231) Hmm. adjust_appendrel_attrs() thinks it's only

[HACKERS] [sqlsmith] Failed assertion in adjust_appendrel_attrs_mutator

2017-10-22 Thread Andreas Seltenreich
Hi, testing master as of 7c981590c2, sqlsmith just triggered the following assertion: TRAP: FailedAssertion("!(!const Node*)(node))->type) == T_SubLink))", File: "prepunion.c", Line: 2231) I can reproduce it on a vanilla regression database with the following query: --8<---cut

[HACKERS] Re: [BUGS] BUG #14849: jsonb_build_object doesn't like VARIADIC calls very much

2017-10-22 Thread Andrew Dunstan
On 10/22/2017 12:11 PM, Andrew Dunstan wrote: > > On 10/21/2017 07:33 PM, Michael Paquier wrote: >> On Sun, Oct 22, 2017 at 1:43 AM, Tom Lane wrote: >>> I don't think collecting all the arguments is particularly special --- >>> format() or concat() for instance could

Re: [HACKERS] Allow GiST opcalsses without compress\decompres functions

2017-10-22 Thread Tom Lane
Andrey Borodin writes: > I was looking for a way to correctly drop compress\decompress functions from > opclasses. Making a new opclass seems like a pretty grotty answer; it won't help existing installations. I think what you need is to undo opclasscmds.c's decision that

Re: [HACKERS] [PATCH] Tests for reloptions

2017-10-22 Thread Nikolay Shaplov
В письме от 19 октября 2017 14:20:52 Вы написали: > I'm hesitant to hardcode things like the number of bits in bloom, as you > had in the original. If I understand correctly, that number could > change with compile options (different blocksize?), so I removed that > part. #define

Re: [HACKERS] Allow GiST opcalsses without compress\decompres functions

2017-10-22 Thread Andrey Borodin
Hi, Tom! > 20 сент. 2017 г., в 8:38, Tom Lane написал(а): > > Andrey Borodin writes: >> [ 0001-Allow-uncompressed-GiST-4.patch ] > > Pushed, with a bit more work on the documentation and some minor > cosmetic changes. > > I did not like the fact that

[HACKERS] new field for structured exception - query

2017-10-22 Thread Pavel Stehule
Hi Currently we don't allow a access to internalquery field from PLpgSQL via GET STACKED DIAGNOSTICS. Do you think so has sense to allow the access to this field? The patch can be very small. Regards Pavel

Re: [HACKERS] stalled post to mailing list - wrong filter?

2017-10-22 Thread Pavel Stehule
2017-10-22 9:08 GMT+02:00 Magnus Hagander : > > > On Sun, Oct 22, 2017 at 9:02 AM, Pavel Stehule > wrote: > >> Hi >> >> I sent correct mail, that requires the approval - maybe bad filter? >> > > There are some pretty restrictive filters in place on

Re: [HACKERS] stalled post to mailing list - wrong filter?

2017-10-22 Thread Magnus Hagander
On Sun, Oct 22, 2017 at 9:02 AM, Pavel Stehule wrote: > Hi > > I sent correct mail, that requires the approval - maybe bad filter? > There are some pretty restrictive filters in place on the mj2 lists in order to deal with cases where people send admin requests. This

[HACKERS] stalled post to mailing list - wrong filter?

2017-10-22 Thread Pavel Stehule
Hi I sent correct mail, that requires the approval - maybe bad filter? Your message to pgsql-hackers has been delayed, and requires the approval of the moderators, for the following reason(s): GLOBAL ADMIN BODY: /^\s*get\s+\S+\s+\S+\s*$/i matched "G#E#T STACKED DIAGNOSTICS." at line number 4.