On Thu, Oct 19, 2017 at 12:16 PM, Amit Langote <
langote_amit...@lab.ntt.co.jp> wrote:
> Description of the attached patches:
>
> 0001: add new tests for partition-pruning
>
> 0002: patch that makes all the changes needed in the planer (adds a stub
> function in partition.c)
>
> 0003: patch
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 other hand pg_dump
> > dump the create database comm
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 yet exist (it is a parti
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 agr
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:
! ERROR: cache lookup failed for relation
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
inheritanc
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, too.
Yep.
>
> The
> 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 progress",
>> that's what I'd want retu
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 note that that's funda
> 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 transaction calling
txid_status()?
I
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.
The extern declaration seems to hav
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, but I'm no expert.
>>
>> What are you going to use
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, but
> you are on it, right?
Sorr
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 all the arguments is particularly special ---
for
> 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 think that that context is
> likely
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 via pgsql-hackers ma
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:
{
Transa
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
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 a
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 used after conversion
o
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
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 possibly use this. You migh
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 the
dependencies should
В письме от 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 MAX_BLOOM_LEN
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 the new code paths added by the patch
> wer
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
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 the mj2 lists in
> order to deal with cases wher
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 happens now
and then, and wi
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.
29 matches
Mail list logo
