I have a test where a user creates a temp table and then disconnect,
concurrently we try to do DROP OWNED BY CASCADE on the same user. Seems
this causes race condition between temptable deletion during disconnection
(@RemoveTempRelations(myTempNamespace)) and DROP OWNED BY CASCADE operation
which
On Mon, Jan 06, 2020 at 04:32:39PM -0500, Stephen Frost wrote:
> RESTRICT, yes. I don't know about ONLY being sensible as we don't
> really deal with inheritance and foreign tables very cleanly today, as I
> said up-thread, so I'm not sure if we really want to put in the effort
> that it'd
At Fri, 3 Jan 2020 16:11:38 +0100, Jehan-Guillaume de Rorthais
wrote in
> Hi,
>
> On Mon, 23 Dec 2019 15:38:16 +0100
> Jehan-Guillaume de Rorthais wrote:
> [...]
> > My idea would be to return a row from pg_stat_get_wal_receiver() as soon as
> > a wal receiver has been replicating during the
On Tue, Jan 07, 2020 at 06:15:09AM +, Nagaraj Raj wrote:
> and this error is occurring in large tables only, and current table
> size which is running about 700GB
>
> /pg_repack --version
> pg_repack 1.4.3
>
> DB version: PostgreSQL 9.6.11 on x86_64-pc-linux-gnu, compiled by gcc (GCC)
>
On Tue, Jan 7, 2020 at 12:43 AM Christoph Berg wrote:
>
> Re: Tom Lane 2020-01-06 <3764.1578323...@sss.pgh.pa.us>
> > > Does not work on Ubuntu bionic, xenial. (Others not tested.)
> >
> > Hmm ... do we care? The test output seems to show that xenial's
> > 3.1-20150325-1ubuntu2 libedit is
Hello,
When I tried to repack my bloated table an error occurred:
FATAL: terminating connection due to idle-in-transaction timeout
ERROR: query failed: SSL connection has been closed unexpectedly
DETAIL: query was: SAVEPOINT repack_sp1
and this error is occurring in large tables only, and
On Tue, Jan 07, 2020 at 09:21:03AM +0530, Dilip Kumar wrote:
> On Tue, Jan 7, 2020 at 1:29 AM Justin Pryzby wrote:
> >
> > Find attached cleaned up patch.
> > For now, I updated the regress/expected/, but I think the test maybe has to
> > be
> > updated to do what it was written to do.
>
> I
On Tue, Jan 7, 2020 at 1:29 AM Justin Pryzby wrote:
>
> Find attached cleaned up patch.
> For now, I updated the regress/expected/, but I think the test maybe has to be
> updated to do what it was written to do.
I have noticed that in "cost_index" we have used the indexCorrelation
for computing
Vik Fearing writes:
> On 06/01/2020 17:03, Tom Lane wrote:
>> So it's not clear to me whether we have any meeting of the minds
>> on wanting this patch. In the meantime, though, the cfbot
>> reports that the patch breaks the ssl tests. Why is that?
> I have no idea. I cannot reproduce the
Hello Merlin,
For low-level arithmetic code like this one, with tests and loops
containing very few hardware instructions, I think that helping compiler
optimizations is a good idea.
Do you have any performance data to back that up?
Yep.
A generic data is the woes about speculative
Hi,
This patch is currently in "needs review" state, but the last message is
from August 29, and my understanding is that there have been a couple of
objections / disagreements about the architecture, difficulties with
producing the set of syscalls, and not providing any built-in policy.
I
On Mon, Jan 06, 2020 at 09:37:54AM -0500, Tom Lane wrote:
> Magnus Hagander writes:
>> Not having thought about it in much detail, but it's a fairly common
>> scenario to have a much newer version of libpq (and the platform it's
>> built on) than the server. E.g. a v12 libpq against a v9.6
On Mon, Jan 06, 2020 at 12:33:47PM -0500, Tom Lane wrote:
> Robert Haas writes:
>> I'm not arguing for a revert of 246a6c8. I think we should just change this:
>> ...
>> To look more like:
>
>> char *nspname = get_namespace_name(classForm->relnamespace);
>> if (nspname != NULL)
>>
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Perhaps I'm wrong, but I wouldn't think changing this from a
> > default-role based approach over to a GRANT'able right using our
> > existing GRANT system would be a lot of work.
>
> Nobody has proposed a GRANT-based
Stephen Frost writes:
> Perhaps I'm wrong, but I wouldn't think changing this from a
> default-role based approach over to a GRANT'able right using our
> existing GRANT system would be a lot of work.
Nobody has proposed a GRANT-based API that seems even close to
acceptable from where I sit. A
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Mon, Jan 6, 2020 at 1:27 PM Tom Lane wrote:
> >> After sleeping on it, I'm liking that idea; it's simple, and it
> >> preserves the existing behavior that DB owners can install trusted PLs
> >> without any extra
Christoph Berg writes:
> Re: Tom Lane 2020-01-06 <3764.1578323...@sss.pgh.pa.us>
>>> Does not work on Ubuntu bionic, xenial. (Others not tested.)
>> Hmm ... do we care? The test output seems to show that xenial's
>> 3.1-20150325-1ubuntu2 libedit is completely broken. Maybe there's
>> a way to
Greetings -hackers,
Google Summer of Code is back for 2020! They have a similar set of
requirements, expectations, and timeline as last year.
Now is the time to be working to get together a set of projects we'd
like to have GSoC students work on over the summer. Similar to last
year, we need
Robert Haas writes:
> On Mon, Jan 6, 2020 at 1:27 PM Tom Lane wrote:
>> After sleeping on it, I'm liking that idea; it's simple, and it
>> preserves the existing behavior that DB owners can install trusted PLs
>> without any extra permissions. Now, if we follow this up by marking
>> most of
On Fri, Jul 26, 2019 at 04:13:23PM +, Fabien COELHO wrote:
FETCH_COUNT does not work with combined queries, and probably has
never worked since 2006.
For the record, this bug has already been reported & discussed by
Daniel Vérité a few months back, see:
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2020-Jan-06, Stephen Frost wrote:
>
> > > I wonder if part of the confusion might be due to the synonyms we're
> > > using here for "in use". Things seem to be "got running", "set up",
> > > "operating", "negotiated", ... -
Julien Rouhaud writes:
> On Mon, Jan 6, 2020 at 7:57 PM Pierre Ducroquet wrote:
>> My deepest apologies for the patch being broken, I messed up when
>> transferring
>> it between my computers after altering the comments. The verbatim one
>> attached
>> to this email applies with no issue on
Hello,
On 2020-Jan-06, Robbie Harwood wrote:
> This looks correct to me (and uses plenty of parentheticals, so it feels
> in keeping with something I'd write) :)
(You know, long ago I used to write with a lot of parenthicals (even
nested ones). But I read somewhere that prose is more natural
On 2020-Jan-06, Stephen Frost wrote:
> > I wonder if part of the confusion might be due to the synonyms we're
> > using here for "in use". Things seem to be "got running", "set up",
> > "operating", "negotiated", ... - maybe that's part of the barrier to
> > understanding?
>
> How about
On Thu, Nov 28, 2019 at 2:15 PM Andrew Dunstan
wrote:
>
>
> On 11/27/19 9:35 PM, Michael Paquier wrote:
> > On Fri, Nov 15, 2019 at 09:45:59PM +0100, Pavel Stehule wrote:
> >> Maybe ERRCODE_NULL_VALUE_NOT_ALLOWED, and "NULL is not allowed",
> >> errdetail - a exception due setting
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Thu, Jan 02, 2020 at 09:46:44AM -0500, Stephen Frost wrote:
> > I agree that the FDW callback should support multiple tables in the
> > TRUNCATE, but I think it also should include CASCADE as an option and
> > have that be passed on
Stephen Frost writes:
>> Alvaro Herrera writes:
>
> How about something like this?
>
> * If GSSAPI Encryption is enabled, then call pg_GSS_have_cred_cache()
> * which will return true if we can acquire credentials (and give us a
> * handle to use in conn->gcred), and then send a packet to
Greetings,
* Robbie Harwood (rharw...@redhat.com) wrote:
> Alvaro Herrera writes:
>
> > How about this?
> >
> > * If GSSAPI is enabled and we can reach a credential cache,
> > * set up a handle for it; if it's operating, just send a
> > * GSS
On Mon, Jan 6, 2020 at 1:27 PM Tom Lane wrote:
> So, is that actually an objection to the current proposal, or just
> an unrelated rant?
Well, you brought up the topic of remaining bits in the context of the
proposal, so I guess it's related. And I said pretty clearly that it
wasn't necessarily
On Mon, Jan 6, 2020 at 6:52 AM Fabien COELHO wrote:
>
>
> Hello Robert,
>
> >> if (arg1 == PG_INT32_MIN)
> >> if (arg2 == 0 || arg2 == PG_INT32_MIN)
> >>
> >> And possibly a "likely" on the while.
> >
> > I don't think decoration the code with likely() and unlikely() all
> > over the place is
On Mon, Jan 6, 2020 at 9:31 AM Julien Rouhaud wrote:
>
> On Mon, Jan 6, 2020 at 9:21 AM Michael Paquier wrote:
> >
> > On Mon, Jan 06, 2020 at 09:07:26AM +0100, Peter Eisentraut wrote:
> > > This is a new bug in PG12. When you have a database with an OID above
> > > INT32_MAX (signed), then
Find attached cleaned up patch.
For now, I updated the regress/expected/, but I think the test maybe has to be
updated to do what it was written to do.
>From 36f547d69b8fee25869d6ef3ef26d327a8ba1205 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 1 Jan 2019 16:17:28 -0600
Subject: [PATCH
Hi Andrey,
Thanks for the comment!
The unimproved cases you mentioned all fall into the category “correlated
subquery”. This category is explicitly disallowed by existing code to convert
to join in convert_ANY_sublink_to_join:
/*
* The sub-select must not refer to any Vars of the
Hi,
I spent a little bit of time trying to explain the problem we are facing
clearly, and provide a reproducible benchmark.
So here it is.
What triggered our investigation is that we have a PostgreSQL cluster
containing about 15 databases, most of them being used as sources for logical
On Mon, Jan 6, 2020 at 7:57 PM Pierre Ducroquet wrote:
>
> On Monday, January 6, 2020 6:57:33 PM CET Tom Lane wrote:
> > Pierre Ducroquet writes:
> > > Attached to this email is a patch with better comments regarding the
> > > XLogSendLogical change.
> >
> > Hi,
> > This patch entirely fails
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Thu, Nov 7, 2019 at 2:13 PM Stephen Frost wrote:
> >> I do not agree that we should just shift to using default roles instead
> >> of adding new options to GRANT because of an entirely internal
> >> implementation
Re: Tom Lane 2020-01-06 <3764.1578323...@sss.pgh.pa.us>
> > Does not work on Ubuntu bionic, xenial. (Others not tested.)
>
> Hmm ... do we care? The test output seems to show that xenial's
> 3.1-20150325-1ubuntu2 libedit is completely broken. Maybe there's
> a way to work around that, but it's
On Monday, January 6, 2020 6:57:33 PM CET Tom Lane wrote:
> Pierre Ducroquet writes:
> > Attached to this email is a patch with better comments regarding the
> > XLogSendLogical change.
>
> Hi,
> This patch entirely fails to apply for me (and for the cfbot too).
> It looks like (a) it's
On Sun, Jan 5, 2020 at 11:00 PM chenhj wrote:
> According to above information, the flags of the heap page (163363) with the
> problem tuple (163363, 9) is 0x0001 (HAS_FREE_LINES), that is, ALL_VISIBLE is
> not set.
>
> However, according hexdump content of the corresponding vm file, that
>
Robert Haas writes:
> On Thu, Nov 7, 2019 at 2:13 PM Stephen Frost wrote:
>> I do not agree that we should just shift to using default roles instead
>> of adding new options to GRANT because of an entirely internal
>> implementation detail that we could fix (and should, as I've said for
>>
po 6. 1. 2020 v 18:22 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > út 10. 12. 2019 v 13:56 odesílatel Karl O. Pinc napsal:
> >> I'm marking it ready for a committer.
>
> > Thank you for review
>
> Pushed with minor adjustments. Notably, I didn't like having
> get_min_scale() depend
Pierre Ducroquet writes:
> Attached to this email is a patch with better comments regarding the
> XLogSendLogical change.
Hi,
This patch entirely fails to apply for me (and for the cfbot too).
It looks like (a) it's missing a final newline and (b) all the tabs
have been mangled into spaces,
On 06/01/2020 17:03, Tom Lane wrote:
> So it's not clear to me whether we have any meeting of the minds
> on wanting this patch. In the meantime, though, the cfbot
> reports that the patch breaks the ssl tests. Why is that?
I have no idea. I cannot reproduce the failure locally.
--
Vik
Robert Haas writes:
> I'm not arguing for a revert of 246a6c8. I think we should just change this:
> ...
> To look more like:
> char *nspname = get_namespace_name(classForm->relnamespace);
> if (nspname != NULL)
>ereport(..."autovacuum: dropping orphan temp table \"%s.%s.%s\"...)
> else
>
On Sun, Jan 5, 2020 at 8:42 PM Michael Paquier wrote:
> The behavior of the code in 246a6c8 has changed so as a non-existing
> temporary namespace is considered as not in use, in which case
> autovacuum would consider this relation to be orphaned, and it would
> then try to drop it. Anyway, just
Pavel Stehule writes:
> út 10. 12. 2019 v 13:56 odesílatel Karl O. Pinc napsal:
>> I'm marking it ready for a committer.
> Thank you for review
Pushed with minor adjustments. Notably, I didn't like having
get_min_scale() depend on its callers having stripped trailing zeroes
to avoid getting
On Thu, Nov 7, 2019 at 2:13 PM Stephen Frost wrote:
> I do not agree that we should just shift to using default roles instead
> of adding new options to GRANT because of an entirely internal
> implementation detail that we could fix (and should, as I've said for
> probably 10 years now...).
+1.
On Sat, 28 Dec 2019 at 16:45, David Fetter wrote:
>
> On Sat, Dec 28, 2019 at 12:12:30AM -0300, Alvaro Herrera wrote:
> > On 2019-Dec-28, David Fetter wrote:
> >
> > > While noodling around with an upcoming patch to remove user-modifiable
> > > RULEs, I noticed that WHEN conditions were
So it's not clear to me whether we have any meeting of the minds
on wanting this patch. In the meantime, though, the cfbot
reports that the patch breaks the ssl tests. Why is that?
regards, tom lane
Peter Eisentraut wrote:
> Also, there is a way to optimize the "is normalized" test for common
> cases, described in UTR #15. For that we'll need an additional data
> file from Unicode. In order to simplify that, I would like my patch
> "Add support for automatically updating Unicode
On Fri, Dec 27, 2019 at 04:36:14AM +0300, Nikita Glukhov wrote:
On 26.12.2019 4:59, Alexander Korotkov wrote:
I've tried to add patch #4 to comparison, but I've catch assertion
failure.
TRAP: FailedAssertion("key->includeNonMatching", File: "ginget.c",
Line: 1340)
There simply should be
Christoph Berg writes:
> I lost track of what bug is supposed to be where, so here's a summary
> of the state at apt.postgresql.org:
> PG13 head work on Debian unstable, buster, stretch.
Cool.
> Does not work on Ubuntu bionic, xenial. (Others not tested.)
Hmm ... do we care? The test output
Magnus Hagander writes:
> Not having thought about it in much detail, but it's a fairly common
> scenario to have a much newer version of libpq (and the platform it's
> built on) than the server. E.g. a v12 libpq against a v9.6 postgres
> server is very common. For example, debian based systems
On Mon, Jan 6, 2020 at 7:02 AM Michael Paquier wrote:
>
> On Thu, Jan 02, 2020 at 09:46:44PM +, cary huang wrote:
> > I agree with Arthur that it makes sense to check the validity of
> > "conn->sslmaxprotocolversion" first before checking if it is larger
> > than "conn->sslminprotocolversion"
po 6. 1. 2020 v 13:17 odesílatel Dean Rasheed
napsal:
> On Mon, 6 Jan 2020 at 11:01, Tomas Vondra
> wrote:
> >
> > On Mon, Jan 06, 2020 at 01:04:15PM +0800, 曾文旌(义从) wrote:
> >
> > >2 We feel that gtt needs to maintain statistics, but there is no
> > >agreement on what it will be done.
> > >
> >
Hi,
This patch got mostly ignored since 2019-07 commitfest :-( The latest
patch (sent by Nikita) does not apply because of a minor conflict in
contrib/ltree/ltxtquery_io.c.
I see the patch removes a small bit of ltree_plpython tests which would
otherwise fail (with the "I don't know plpython"
On Sat, 6 Jul 2019 at 09:53, Amit Kapila wrote:
>
> On Mon, Jul 1, 2019 at 10:05 PM Alvaro Herrera
wrote:
> >
> > Do we have an actual patch here?
> >
>
> We have a patch, but it needs some more work like finding similar
> places and change all of them at the same time and then change the
>
On Mon, Jan 06, 2020 at 12:17:43PM +, Dean Rasheed wrote:
On Mon, 6 Jan 2020 at 11:01, Tomas Vondra wrote:
On Mon, Jan 06, 2020 at 01:04:15PM +0800, 曾文旌(义从) wrote:
>2 We feel that gtt needs to maintain statistics, but there is no
>agreement on what it will be done.
>
I certainly agree
Hello Robert,
if (arg1 == PG_INT32_MIN)
if (arg2 == 0 || arg2 == PG_INT32_MIN)
And possibly a "likely" on the while.
I don't think decoration the code with likely() and unlikely() all
over the place is a very good idea.
Odds are good that we'll end up with a bunch that are actually
On Sat, 4 Jan 2020 at 15:11, cary huang wrote:
>
> Hello Sawada and all
>
> I would like to elaborate more on Sehrope and Sawada's discussion on passing
> NULL IV in "pg_cipher_encrypt/decrypt" functions during kmgr_wrap_key and
> kmgr_unwrap_key routines in kmgr_utils.c. Openssl implements key
Bonjour Michaël,
Without looking at the context I thought that argv[0] was the program name,
which is not the case here. I put it back everywhere, including the DEBUG
message.
The variable names in Command are confusing IMO...
Somehow, yes. Note that there is a logic, it will indeed be the
ALTER TABLE ... SET STORAGE does not propagate to indexes, even though
indexes created afterwards get the new storage setting. So depending on
the order of commands, you can get inconsistent storage settings between
indexes and tables. For example:
create table foo1 (a text);
alter table
On Mon, 6 Jan 2020 at 11:01, Tomas Vondra wrote:
>
> On Mon, Jan 06, 2020 at 01:04:15PM +0800, 曾文旌(义从) wrote:
>
> >2 We feel that gtt needs to maintain statistics, but there is no
> >agreement on what it will be done.
> >
>
> I certainly agree GTT needs to maintain statistics, otherwise it'll
On Sat, Jan 4, 2020 at 4:21 PM Fabien COELHO wrote:
> In GCD implementations, for instance:
>
> if (arg1 == PG_INT32_MIN)
> if (arg2 == 0 || arg2 == PG_INT32_MIN)
>
> And possibly a "likely" on the while.
I don't think decoration the code with likely() and unlikely() all
over the place is a
Hi Amit,
I went through this patch set once again today and here are my two cents.
On Mon, 16 Dec 2019 at 10:19, Amit Langote wrote:
>
> Attached updated patches.
- differently partitioned setup. Attempts to replicate tables other than
- base tables will result in an error.
+
On Mon, Jan 6, 2020 at 4:36 PM Amit Kapila wrote:
>
> On Mon, Jan 6, 2020 at 3:56 PM Dilip Kumar wrote:
> >
> > On Mon, Jan 6, 2020 at 2:11 PM Amit Kapila wrote:
> > >
> > > 3.
> > > +static void
> > > +ReorderBufferStreamTXN(ReorderBuffer *rb, ReorderBufferTXN *txn)
> > > {
> > > ..
> > > + /*
On Mon, Jan 6, 2020 at 3:56 PM Dilip Kumar wrote:
>
> On Mon, Jan 6, 2020 at 2:11 PM Amit Kapila wrote:
> >
> > 3.
> > +static void
> > +ReorderBufferStreamTXN(ReorderBuffer *rb, ReorderBufferTXN *txn)
> > {
> > ..
> > + /*
> > + * If this is a subxact, we need to stream the top-level
On Mon, Jan 06, 2020 at 01:04:15PM +0800, 曾文旌(义从) wrote:
In the previous communication
1 we agreed on the general direction
1.1 gtt use local (private) buffer
1.2 no replica access in first version
OK, good.
2 We feel that gtt needs to maintain statistics, but there is no
agreement on what
Re: Tom Lane 2020-01-05 <25771.1578249...@sss.pgh.pa.us>
> The current state of play on this is that I committed a hacky workaround
> [1], but there is now a fix for it in libedit upstream [2][3]. I gather
> from looking at Debian's package page that the fix could be expected to
> propagate to
On 2019-12-16 14:37, Peter Eisentraut wrote:
New patch attached.
I have committed this and backpatched it to PG10.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, Jan 6, 2020 at 2:11 PM Amit Kapila wrote:
>
> On Mon, Jan 6, 2020 at 9:21 AM Dilip Kumar wrote:
> >
> > On Sat, Jan 4, 2020 at 4:07 PM Amit Kapila wrote:
> > >
> > >
> > > It is better to merge it with the main patch for
> > > "Implement-streaming-mode-in-ReorderBuffer", otherwise, it
On Mon, Jan 6, 2020 at 9:21 AM Dilip Kumar wrote:
>
> On Sat, Jan 4, 2020 at 4:07 PM Amit Kapila wrote:
> >
> >
> > It is better to merge it with the main patch for
> > "Implement-streaming-mode-in-ReorderBuffer", otherwise, it is a bit
> > difficult to review.
> Actually, we can merge 0008,
On Mon, Dec 16, 2019 at 2:50 PM Amit Langote wrote:
>
> Thanks for checking.
>
> On Thu, Dec 12, 2019 at 12:48 AM Peter Eisentraut
> wrote:
> > On 2019-12-06 08:48, Amit Langote wrote:
> > > 0001: Adding a partitioned table to a publication implicitly adds all
> > > its partitions. The
On Mon, Jan 6, 2020 at 9:21 AM Michael Paquier wrote:
>
> On Mon, Jan 06, 2020 at 09:07:26AM +0100, Peter Eisentraut wrote:
> > This is a new bug in PG12. When you have a database with an OID above
> > INT32_MAX (signed), then pg_basebackup fails thus:
>
> Yep. Introduced by 6b9e875.
Indeed.
On Mon, Jan 06, 2020 at 09:07:26AM +0100, Peter Eisentraut wrote:
> This is a new bug in PG12. When you have a database with an OID above
> INT32_MAX (signed), then pg_basebackup fails thus:
Yep. Introduced by 6b9e875.
> pg_basebackup: error: could not get write-ahead log end position from
>
On Fri, Nov 29, 2019 at 8:40 AM Andrew Gierth
wrote:
> This patch is a rather hacky implementation of the basic idea for
> implementing FETCH ... WITH TIES, and potentially also PERCENT, by using
> a window function expression to compute a stopping point.
>
> Large chunks of this (the
On Fri, Jan 03, 2020 at 01:01:18PM +0100, Fabien COELHO wrote:
> Without looking at the context I thought that argv[0] was the program name,
> which is not the case here. I put it back everywhere, including the DEBUG
> message.
The variable names in Command are confusing IMO...
> Ok. I
This is a new bug in PG12. When you have a database with an OID above
INT32_MAX (signed), then pg_basebackup fails thus:
pg_basebackup: error: could not get write-ahead log end position from
server: ERROR: value "30" is out of range for type integer
The cause appears to be commit
On Fri, Dec 27, 2019 at 05:25:58PM +0100, Peter Eisentraut wrote:
> I was wondering why we have a separate libpq.rc for libpq and use
> win32ver.rc for all other components. I suspect this is also a leftover
> from the now-removed client-only Windows build. With a bit of tweaking we
> can use
79 matches
Mail list logo
