On Thu, Feb 13, 2020 at 3:23 AM Justin Pryzby wrote:
> Forking this thread for two tangential patches which I think are more
> worthwhile than the original topic's patch.
> https://www.postgresql.org/message-id/20200207143935.GP403%40telsasoft.com
>
> Is there a better place to implement
Am 12.02.2020 um 00:27 schrieb Tom Lane:
Vik Fearing writes:
Actually, I was imagining that it would end the transaction as it does
today, just with an error code.
This is backed up by General Rule 9 which says "The current
SQL-transaction is terminated."
Hm ... that would be sensible, but
On Thu, Feb 13, 2020 at 10:30 AM Kyotaro Horiguchi
wrote:
> At Mon, 10 Feb 2020 14:32:44 +0900, Amit Langote
> wrote in
> > Agree that ObjectIsUserObject(oid) is easier to read than oid >=
> > FirstNormalObject. I would have not bothered, for example, if it was
> > something like oid >=
On Thu, Feb 13, 2020 at 03:35:50PM +0900, Fujii Masao wrote:
> I found that the wait events "LogicalRewriteTruncate" and
> "GSSOpenServer" are not documented. I'm thinking to add
> them into doc separately if ok.
Nice catch. The ordering of the entries is not respected either for
GSSOpenServer
On Thu, Feb 13, 2020 at 02:51:44PM +1300, Thomas Munro wrote:
> Ok, how about this?
Alvaro's point sounds sensible to me. I like the approach you are
taking in 0001. At least it avoids more issues with WIN32 and stat()
(I hope to work on that at some point, we'll see..).
+/*
+ * pg_file_size
On 2020/02/13 12:28, Michael Paquier wrote:
On Thu, Feb 13, 2020 at 02:29:20AM +0900, Fujii Masao wrote:
When I saw pg_stat_activity.wait_event while pg_basebackup -X none
is waiting for WAL archiving to finish, it was either NULL or
CheckpointDone. I think this is confusing. What about
On Tue, Feb 4, 2020 at 2:23 AM Andres Freund wrote:
> On 2019-12-31 17:05:31 +1300, Thomas Munro wrote:
> > There is one potentially interesting case that doesn't require any
> > kind of shared cache invalidation AFAICS. XLogReadBufferExtended()
> > calls smgrnblocks() for every buffer access,
On Thu, 13 Feb 2020 at 09:46, Amit Kapila wrote:
>
> On Tue, Feb 11, 2020 at 9:13 PM Tom Lane wrote:
> >
> > I took a brief look through this patch. I agree with the fundamental
> > idea that we shouldn't need to use the heavyweight lock manager for
> > relation extension, since deadlock is not
Hi PAscal,
On Tue, 11 Feb 2020 15:04:12 -0700 (MST)
legrand legrand wrote:
>
> regarding syntax REFRESH MATERIALIZED VIEW x WITH NO DATA
>
> I understand that triggers are removed from the source tables, transforming
> the INCREMENTAL MATERIALIZED VIEW into a(n unscannable) MATERIALIZED VIEW.
On 2/10/20 12:55 PM, Luís Roberto Weck wrote:
> Em 10/02/2020 13:46, Jonathan S. Katz escreveu:
>> Hi,
>>
>> Attached is a draft for the 2020-02-13 press release. I would appreciate
>> any review for accuracy, notable omissions, and the inevitable typos I
>> tend to have on drafts (even though I
On Sat, 8 Feb 2020 at 10:01, Justin Pryzby wrote:
>
> On Tue, Feb 04, 2020 at 01:58:20PM +0900, Masahiko Sawada wrote:
> > Here is the comment for v16 patch:
> >
> > 2.
> > I think we can set the error context for heap scan again after
> > freespace map vacuum finishing, maybe after reporting the
On Thu, Feb 13, 2020 at 9:46 AM Amit Kapila wrote:
>
> On Tue, Feb 11, 2020 at 9:13 PM Tom Lane wrote:
> >
> > I took a brief look through this patch. I agree with the fundamental
> > idea that we shouldn't need to use the heavyweight lock manager for
> > relation extension, since deadlock is
On Tue, Feb 11, 2020 at 9:13 PM Tom Lane wrote:
>
> I took a brief look through this patch. I agree with the fundamental
> idea that we shouldn't need to use the heavyweight lock manager for
> relation extension, since deadlock is not a concern and no backend
> should ever need to hold more than
On Tue, 11 Feb 2020 at 10:57, Andres Freund wrote:
>
> Hi,
>
> On 2020-02-08 12:07:57 -0500, Tom Lane wrote:
> > For the same reason, I don't think that an "internal key management"
> > feature in the core code is ever going to be acceptable. It has to
> > be an extension. (But, as long as it's
On Wed, Feb 12, 2020 at 01:59:05PM -0300, Fabrízio de Royes Mello wrote:
> In parallel mode it's firing the EventTrigger and it can't be happen.
> Poking around it I did some test with attached just to leave EventTriggers
> in pending_list to process it in restore_toc_entries_postfork and
>
On Wed, Feb 12, 2020 at 09:46:48AM -0500, Tom Lane wrote:
> Yeah; I don't think it's *that* unlikely for it to happen again. But
> my own principal concern about this mirrors what somebody else already
> pointed out: the one-major-release-per-year schedule is not engraved on
> any stone tablets.
On Thu, Feb 13, 2020 at 01:23:41AM +0100, Andreas Karlsson wrote:
> On 1/28/20 9:21 PM, Peter Eisentraut wrote:
>> You're right, this didn't make any sense. Here is a new patch set with
>> that fixed.
>
> Thanks for this patch. This is a feature which has been on my personal todo
> list for a
On Thu, Feb 13, 2020 at 11:28:05AM +0900, Kyotaro Horiguchi wrote:
> I think it is reasonable.
Indeed, that makes sense to me as well. I am adding Peter Eisentraut
in CC as the author/committer of 8a3d942 to comment on that.
> By the way, I'm not sure the criteria of setting a GUC variable as
>
On Thu, Feb 13, 2020 at 02:29:20AM +0900, Fujii Masao wrote:
> When I saw pg_stat_activity.wait_event while pg_basebackup -X none
> is waiting for WAL archiving to finish, it was either NULL or
> CheckpointDone. I think this is confusing. What about introducing
> new wait_event like
On Wed, Feb 12, 2020 at 10:23 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Wed, Feb 12, 2020 at 7:36 AM Masahiko Sawada
> > wrote:
> >> On Wed, 12 Feb 2020 at 00:43, Tom Lane wrote:
> >>> I would like to suggest that we do something similar to Robert Haas'
> >>> excellent hack (daa7527af)
At Thu, 13 Feb 2020 02:37:29 +0900, Fujii Masao wrote
in
> On Fri, Nov 8, 2019 at 4:24 PM Amit Langote wrote:
> >
> > Hello.
> >
> > On Tue, Nov 5, 2019 at 5:15 PM Moon, Insung
> > wrote:
> > > Deal Hackers.
> > >
> > > The value of ssl_passphrase_command is set so that an external command
>
On Thu, Feb 13, 2020 at 5:30 AM Alvaro Herrera wrote:
> On 2020-Feb-12, Thomas Munro wrote:
> > Hmm. Well, on Unix we have to choose between "tell me the size but
> > also change the position that I either don't care about or have to
> > undo", and "tell me the size but also tell me all this
At Mon, 10 Feb 2020 14:32:44 +0900, Amit Langote
wrote in
> On Mon, Feb 10, 2020 at 2:23 PM Masahiko Sawada
> wrote:
> > On Mon, 10 Feb 2020 at 14:09, Michael Paquier wrote:
> > >
> > > On Mon, Feb 10, 2020 at 01:16:30PM +0900, Amit Langote wrote:
> > > > On Mon, Feb 10, 2020 at 1:06 PM
Ranier Vilela writes:
> Coverity detected a dead code in the src / interfaces / libpq / fe-auth.c
> file, to correct it, a simplification was made and the oom_error goto was
> removed, since it is clearly redundant and its presence can be confusing.
I'm kind of disinclined to let Coverity
On 1/28/20 9:21 PM, Peter Eisentraut wrote:
You're right, this didn't make any sense. Here is a new patch set with
that fixed.
Thanks for this patch. This is a feature which has been on my personal
todo list for a while and something which I have wished to have a couple
of times.
I took a
Hi,
Coverity detected a dead code in the src / interfaces / libpq / fe-auth.c
file, to correct it, a simplification was made and the oom_error goto was
removed, since it is clearly redundant and its presence can be confusing.
The second part of the patch refers to the file src / interfaces /
Hi,
On Wed, Feb 12, 2020 at 02:52:53PM +0100, Andreas Karlsson wrote:
> On 2/12/20 12:07 AM, Alvaro Herrera wrote:
> > marcelo zen escribió:
> > > I'd rather have releases being made when the software is ready and
> > > not when the calendar year mandates it. It seems like a terrible
> > > idea.
On 12/02/2020 21:10, David Fetter wrote:
> On Wed, Feb 12, 2020 at 05:25:15PM +0100, Juan José Santamaría Flecha wrote:
>> On Wed, Feb 12, 2020 at 3:47 PM Tom Lane wrote:
>>
>>>
>>> Yeah; I don't think it's *that* unlikely for it to happen again. But
>>> my own principal concern about this
On Wed, Feb 12, 2020 at 05:25:15PM +0100, Juan José Santamaría Flecha wrote:
> On Wed, Feb 12, 2020 at 3:47 PM Tom Lane wrote:
>
> >
> > Yeah; I don't think it's *that* unlikely for it to happen again. But
> > my own principal concern about this mirrors what somebody else already
> > pointed
On Thu, Feb 13, 2020 at 9:16 AM Julien Rouhaud wrote:
> On Wed, Feb 12, 2020 at 08:55:06PM +0100, Laurenz Albe wrote:
> > I didn't study the patch in detail, but do I get it right that there will
> > be no
> > warnings about version incompatibilities with libc collations?
>
> No, libc is also be
On Wed, Feb 12, 2020 at 08:55:06PM +0100, Laurenz Albe wrote:
> On Wed, 2020-02-12 at 20:13 +0100, Julien Rouhaud wrote:
> > On Wed, Feb 05, 2020 at 05:17:25PM +0100, Julien Rouhaud wrote:
> > > Note that I didn't change any syntax (or switched to native functions
> > > for the binary pg_dump) as
On Wed, 12 Feb 2020 at 14:58, Laurenz Albe wrote:
> On Wed, 2020-02-12 at 12:32 -0500, Christopher Browne wrote:
> > All said, I think there's some merit to avoiding a PostgreSQL 13
> release, because
> > there's enough superstition out there about the infamous "number 13."
>
> It would make me
On Wed, 2020-02-12 at 12:32 -0500, Christopher Browne wrote:
> All said, I think there's some merit to avoiding a PostgreSQL 13 release,
> because
> there's enough superstition out there about the infamous "number 13."
It would make me sad if the project kotowed to superstition like Oracle did.
On Wed, 2020-02-12 at 20:13 +0100, Julien Rouhaud wrote:
> On Wed, Feb 05, 2020 at 05:17:25PM +0100, Julien Rouhaud wrote:
> > Note that I didn't change any syntax (or switched to native functions
> > for the binary pg_dump) as it's still not clear to me what exactly
> > should be implemented.
>
> > > For most places it'd probably end up being easier to read and to
> > > optimize if we just wrote them as
> > > if (unlikely(isinf(result)) && !isinf(arg))
> > > float_overflow_error();
> > > and when needed added a
> > > else if (unlikely(result == 0) && arg1 != 0.0)
> > >
Andres Freund writes:
> I'm inclined that we should backpatch that, and just leave the inline
> function (without in core callers) in place in 12?
Yeah, we can't remove the inline function in 12. But we don't have
to use it.
regards, tom lane
Hi,
On 2020-02-12 14:18:30 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I do wonder if we're just punching ourselves in the face with the
> > signature of these checks. Part of the problem here really comes from
> > using the same function to handle a number of different checks.
>
> Yeah,
Andres Freund writes:
> I do wonder if we're just punching ourselves in the face with the
> signature of these checks. Part of the problem here really comes from
> using the same function to handle a number of different checks.
Yeah, I've thought that too. It's *far* from clear that this thing
Hi,
On 2020-02-12 13:15:22 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I'd just rename the macro to the name of the inline function. No need to
> > have a verbose change in all callsites just to update the name imo.
>
> +1, that's what I had in mind too. That does suggest though that we
Forking this thread for two tangential patches which I think are more
worthwhile than the original topic's patch.
https://www.postgresql.org/message-id/20200207143935.GP403%40telsasoft.com
Is there a better place to implement assertion from 0002 ?
On Fri, Feb 07, 2020 at 08:39:35AM -0600, Justin
Andres Freund writes:
> I'd just rename the macro to the name of the inline function. No need to
> have a verbose change in all callsites just to update the name imo.
+1, that's what I had in mind too. That does suggest though that we
ought to make sure the macro has single-eval behavior, so
On 2020-02-12 17:49:14 +, Emre Hasegeli wrote:
> > Nor do I see how it's going to be ok to just rename the function in a
> > stable branch.
>
> I'll post another version to keep them around.
I'd just rename the macro to the name of the inline function. No need to
have a verbose change in all
> Wait, no. Didn't we get to the point that we figured out that the
> primary issue is the reversal of the order of what is checked is the
> primary problem, rather than the macro/inline piece?
Reversal of the order makes a small or no difference. The
macro/inline change causes the real slowdown
On Fri, Nov 8, 2019 at 4:24 PM Amit Langote wrote:
>
> Hello.
>
> On Tue, Nov 5, 2019 at 5:15 PM Moon, Insung
> wrote:
> > Deal Hackers.
> >
> > The value of ssl_passphrase_command is set so that an external command
> > is called when the passphrase for decrypting an SSL file such as a
> >
On Wed, 12 Feb 2020 at 08:28, Alvaro Herrera
wrote:
> marcelo zen escribió:
> > I'd rather have releases being made when the software is ready and not
> when
> > the calendar year mandates it.
> > It seems like a terrible idea.
>
> But we do actually release on calendar year. While it seems not
Hi,
When I saw pg_stat_activity.wait_event while pg_basebackup -X none
is waiting for WAL archiving to finish, it was either NULL or
CheckpointDone. I think this is confusing. What about introducing
new wait_event like WAIT_EVENT_BACKUP_WAIT_WAL_ARCHIVE
(BackupWaitWalArchive) and reporting it
Hi,
I am very interested in this feature that will conform to the SQL standard and
I read that :
Session 1:
create global temp table gtt(x integer);
insert into gtt values (generate_series(1,10));
Session 2:
insert into gtt values (generate_series(1,20));
Session1:
create
Hi,
On 2020-02-12 11:54:13 +, Emre Hasegeli wrote:
> From fb5052b869255ef9465b1de92e84b2fb66dd6eb3 Mon Sep 17 00:00:00 2001
> From: Emre Hasegeli
> Date: Fri, 7 Feb 2020 10:27:25 +
> Subject: [PATCH] Bring back CHECKFLOATVAL() macro
>
> The inline functions added by 6bf0bc842b caused
On 2020/01/22 9:06, David Fetter wrote:
On Tue, Jan 21, 2020 at 03:27:50PM +0900, Fujii Masao wrote:
Hi,
When I was researching the maximum length of password in PostgreSQL
to answer the question from my customer, I found that there are two
minor issues in .pgpass file.
(1) If the length of
Hi all,
Today digging into a customer issue about errors in pg_restore I realized
that pg_restore dispatch a worker to restore EventTrigger
during restore_toc_entries_parallel. IMHO EventTriggers should be restored
during the restore_toc_entries_postfork in serial mode.
For example this simple
Amit Kapila writes:
> On Wed, Feb 12, 2020 at 7:36 AM Masahiko Sawada
> wrote:
>> On Wed, 12 Feb 2020 at 00:43, Tom Lane wrote:
>>> I would like to suggest that we do something similar to Robert Haas'
>>> excellent hack (daa7527af) for the !HAVE_SPINLOCK case in lmgr/spin.c,
>> My original
On 2020-Feb-12, Thomas Munro wrote:
> Hmm. Well, on Unix we have to choose between "tell me the size but
> also change the position that I either don't care about or have to
> undo", and "tell me the size but also tell me all this other stuff I
> don't care about". Since Windows apparently has
On Wed, Feb 12, 2020 at 3:47 PM Tom Lane wrote:
>
> Yeah; I don't think it's *that* unlikely for it to happen again. But
> my own principal concern about this mirrors what somebody else already
> pointed out: the one-major-release-per-year schedule is not engraved on
> any stone tablets. So I
Andreas Karlsson escribió:
> On 2/12/20 12:07 AM, Alvaro Herrera wrote:
> > marcelo zen escribió:
> > > I'd rather have releases being made when the software is ready and not
> > > when
> > > the calendar year mandates it.
> > > It seems like a terrible idea.
> >
> > But we do actually release
Hi,
In postgresGetForeignJoinPaths(), I see
/* Estimate costs for bare join relation */
estimate_path_cost_size(root, joinrel, NIL, NIL, NULL,
, , _cost, _cost);
/* Now update this information in the joinrel */
joinrel->rows = rows;
Thank you for both your feedback. Yes, as indicated by Peter, we indeed use
that technique in comparison in index, and now we will try passing
comparator to the storage engine according to Alvaro's suggestion.
Best,
Shichao
On Tue, 11 Feb 2020 at 17:16, Peter Geoghegan wrote:
> On Tue, Feb
Continuing the discussion in [0], here is a patch that allows parameter
references in the arguments of the EXECUTE command. The main purpose is
submitting protocol-level parameters, but the added regression test case
shows another way to exercise it.
What's confusing is that the code already
Andreas Karlsson writes:
> On 2/12/20 12:07 AM, Alvaro Herrera wrote:
>> But we do actually release on calendar year. While it seems not
>> unreasonable that we might fail to ship in time, that would likely lead
>> to one month, two months of delay. Four months? I don't think anybody
>> even
On 2/12/20 12:07 AM, Alvaro Herrera wrote:
marcelo zen escribió:
I'd rather have releases being made when the software is ready and not when
the calendar year mandates it.
It seems like a terrible idea.
But we do actually release on calendar year. While it seems not
unreasonable that we
marcelo zen escribió:
> I'd rather have releases being made when the software is ready and not when
> the calendar year mandates it.
> It seems like a terrible idea.
But we do actually release on calendar year. While it seems not
unreasonable that we might fail to ship in time, that would likely
> On 12 Feb 2020, at 11:54, Peter Eisentraut
> wrote:
>
> On 2020-02-11 10:34, Daniel Gustafsson wrote:
>> Pardon my weak autoconf-skills, what does the inverted brackets (]foo[ as
>> opposed to [foo]) do in the below?
>> -Please also contact to see about
>> +Please also contact
> Should we update the same macro in contrib/btree_gist/btree_utils_num.h too?
I posted another version incorporating this.
> But the comment does not explain that this test has to be in that
> order, or the compiler will for non-constant arguments evalute
> the (now) right-side first. E.g. if I understand this correctly:
>
> + if (!(zero_is_valid) && unlikely((val) == 0.0)
>
> would have the same problem of
On 2020-02-11 10:34, Daniel Gustafsson wrote:
Pardon my weak autoconf-skills, what does the inverted brackets (]foo[ as
opposed to [foo]) do in the below?
-Please also contact to see about
+Please also contact <]AC_PACKAGE_BUGREPORT[> to see about
AC_PACKAGE_BUGREPORT is an Autoconf macro,
On Wed, Feb 12, 2020 at 10:24 AM Andres Freund wrote:
>
> Hi,
>
> On 2020-02-11 08:01:34 +0530, Amit Kapila wrote:
> > I don't see much downside with the patch, rather there is a
> > performance increase of 3-9% in various scenarios.
>
> As I wrote in [1] I started to look at this patch. My
On Tue, Feb 11, 2020 at 1:20 AM Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
> So looks like PG-13 provides significant advantages in OLAP queries
> comparing with 9.6!
> Definitely it doesn't mean that vectorized executor is not needed for new
> version of Postgres.
> Once been
On Wed, Feb 12, 2020 at 5:42 AM, Craig Ringer wrote:
> > It seems performance difference is big in case of read only tests. The
> > reason is that write time is relatively longer than the
> > processing time of the logic I added in the patch.
>
> That's going to be a pretty difficult performance
Thanks Andres,
On Tue, Feb 11, 2020 at 5:30 AM Andres Freund wrote:
> HHi,
>
> On 2020-02-10 16:04:21 +0800, Hubert Zhang wrote:
> > Currently we only print block number and relation path when checksum
> check
> > fails. See example below:
> >
> > ERROR: invalid page in block 333571 of relation
On Wed, Feb 12, 2020 at 7:36 AM Masahiko Sawada
wrote:
>
> On Wed, 12 Feb 2020 at 00:43, Tom Lane wrote:
> >
> > I took a brief look through this patch. I agree with the fundamental
> > idea that we shouldn't need to use the heavyweight lock manager for
> > relation extension, since deadlock is
Hi,
In commit 3eb77eba we made it possible for any subsystem that wants a
file to be flushed as part of the next checkpoint to ask the
checkpointer to do that, as previously only md.c could do.
In the past, foreground CLOG flush stalls were a problem, but then
commit 33aaa139 cranked up the
Here is another patch set to enable this functionality.
0001 enables Unix-domain sockets on Windows, but leaves them turned off
by default at run time, using the mechanism introduced by a9cff89f7e.
This is relatively straightforward, except perhaps some aesthetic
questions about how these
On 12/02/2020 05:35, Michael Paquier wrote:
> On Tue, Feb 11, 2020 at 10:05:25AM -0500, Robert Haas wrote:
>> No objections here. I'm glad that we put in the effort to get more
>> opinions, but I agree that an overall vote of ~58 to ~8 is a pretty
>> strong consensus.
>
> Clearly, so done as
72 matches
Mail list logo
