On 2019-11-03 23:40, Tom Lane wrote:
* The patch now always quotes completed filenames, so quote_if_needed()
is misnamed and overcomplicated for this use-case. I left the extra
generality in place for possible future use. On the other hand, this
is the*only* use-case, so you could also argue
On Thu, Jan 2, 2020 at 8:56 PM Robert Haas wrote:
> On Thu, Jan 2, 2020 at 5:23 AM Amit Kapila
> wrote:
> > LGTM. I will commit this tomorrow unless someone has any comments.
>
> LGTM, too.
>
>
Pushed.
> Thanks, Jon, for the patch.
>
+1.
--
With Regards,
Amit Kapila.
EnterpriseDB:
In May of last year (2019), I set up pg_ssl_init on gitlab:
https://gitlab.com/osfda/pg_ssl_init
And announced it on this list:
https://www.postgresql.org/message-id/1621ef11-f246-8519-018d-57ba36ecc16b%40osfda.org
pg_ssl_init is a set of python3 scripts that configures SSL certificates
to
On Thu, Jan 02, 2020 at 11:34:55PM +0100, Tomas Vondra wrote:
> It's probably time I've done one of these, so if there are no other
> volunteers I'll take care of it this one.
Nobody has raised his/her hand yet, but let's see. If you take care
of it, that would be great. Thanks!
--
Michael
On Thu, Jan 02, 2020 at 11:45:37PM -0500, Tom Lane wrote:
> Ah. The CF app doesn't understand that (and hence the cfbot ditto),
> so you might want to repost just the currently-proposed patch to get
> the cfbot to try it.
Yes, let's do that. Here you go with a v2. While on it, I have
noticed
Further, if a table type (a.k.a. composite type or row type) having null
value or holding no data in it is assigned to a record variable there is no
structure provided to the record variable. However when the same table
having no data in it is assigned to the record variable, it does provide
On Fri, Jan 3, 2020 at 7:10 AM Tomas Vondra
wrote:
> On Thu, Jan 02, 2020 at 02:39:04AM +1300, Thomas Munro wrote:
> >Based on ideas from earlier discussions[1][2], here is an experimental
> >WIP patch to improve recovery speed by prefetching blocks. If you set
> >wal_prefetch_distance to a
On Fri, Jan 3, 2020 at 8:29 AM Amit Kapila wrote:
> On Thu, Jan 2, 2020 at 5:44 PM Amit Kapila
> wrote:
>
>> On Tue, Dec 24, 2019 at 2:31 PM Amit Khandekar
>> wrote:
>> >
>> >
>> > Ok. I tested pg94_95_use_vfd_for_logrep.patch for 9.6 branch, and it
>> > works there. So please use this patch
Michael Paquier writes:
> On Thu, Jan 02, 2020 at 09:30:42AM -0500, Tom Lane wrote:
>> BTW, the referenced patch only removes the configure check for
>> SSL_get_current_compression
> The actual patch I am proposing to finish merging is
> 0003 as posted here, which is the remaining piece:
>
On Thu, Jan 2, 2020 at 5:39 PM Amit Kapila wrote:
>
> Hi,
>
> I am starting a new thread for some of the decisions for a parallel vacuum in
> the hope to get feedback from more people. There are mainly two points for
> which we need some feedback.
>
> 1. Tomas Vondra has pointed out on the
On Thu, Jan 2, 2020 at 5:44 PM Amit Kapila wrote:
> On Tue, Dec 24, 2019 at 2:31 PM Amit Khandekar
> wrote:
> >
> >
> > Ok. I tested pg94_95_use_vfd_for_logrep.patch for 9.6 branch, and it
> > works there. So please use this patch for all the three branches.
> >
>
> Pushed!
>
I see one
On Thu, Jan 02, 2020 at 09:30:42AM -0500, Tom Lane wrote:
> BTW, the referenced patch only removes the configure check for
> SSL_get_current_compression, which is fine, but is that even
> moving any goalposts? The proposed commit message says the
> function exists down to 0.9.8, which is already
On Tue, Dec 17, 2019 at 2:57 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Thanks for the patch! If I understand correctly from this thread,
> approach B is more preferable, so I've concentrated on the patch 0001
> and have a few commentaries/questions:
>
Thanks so much for the review!
>
I wrote:
> I no longer use state variables to track scanner state, and in fact I
> removed the existing "state_before" variable in ECPG. Instead, I used
> the Flex builtins yy_push_state(), yy_pop_state(), and yy_top_state().
> These have been a feature for a long time, it seems, so I think we're
On 01/01/2020 02:35, Tom Lane wrote:
Peter Eisentraut writes:
With the attached patch, I propose to enable the colored output by
default in PG13.
FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find
On Thu, Jan 02, 2020 at 11:22:33PM +0900, Michael Paquier wrote:
Hi all,
Happy new year to all!
As we have entered in January, the commit fest for 2020-01 has
officially begun, and I have switched the status of this commit fest
to "In Progress" a couple of minutes ago. Unfortunately, we still
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Hello
I have applied the patch and did some basic testing with
On Wed, Jan 1, 2020 at 1:00 PM Peter Geoghegan wrote:
> Attached patch shows what I have in mind. The new comment block has
> been copied from _bt_delitems_vacuum().
I also think that the WAL record and function signature of
_bt_delitems_delete() should be brought closer to
Stephen Frost writes:
> On Thu, Jan 2, 2020 at 15:50 Tom Lane wrote:
>> To cover the proposed functionality, you'd still need some way to
>> select not-superuser. So I don't think this fully answers the need
>> even if we wanted to do it.
> Sorry- why do we need that..? The first match for a
Greetings,
On Thu, Jan 2, 2020 at 15:50 Tom Lane wrote:
> Andrew Gierth writes:
> > "Tom" == Tom Lane writes:
> > Tom> Meh. If the things aren't actually roles, I think this'd just add
> > Tom> confusion. Or were you proposing to implement them as roles? I'm
> > Tom> not sure if that would
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Meh. If the things aren't actually roles, I think this'd just add
> Tom> confusion. Or were you proposing to implement them as roles? I'm
> Tom> not sure if that would be practical in every case.
> In fact my original suggestion when
On Mon, Dec 30, 2019 at 6:46 PM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
> On Tue, Dec 31, 2019 at 9:38 AM Tom Lane wrote:
>
> >
> > This doesn't seem like a reason not to allow a higher limit, like a
> > megabyte or so, but I'm not sure that pushing it to the moon would be
> >
## Stephen Frost (sfr...@snowman.net):
> We already have a reserved namespace when it comes to roles,
> specifically "pg_".. why invent something new like this '&' prefix when
> we could just declare that 'pg_superusers' is a role to which all
> superusers are members? Or something along those
Greetings,
On Thu, Jan 2, 2020 at 15:04 Tom Lane wrote:
> Stephen Frost writes:
> > We already have a reserved namespace when it comes to roles,
> > specifically "pg_".. why invent something new like this '&' prefix when
> > we could just declare that 'pg_superusers' is a role to which all
>
> "Tom" == Tom Lane writes:
> Stephen Frost writes:
>> We already have a reserved namespace when it comes to roles,
>> specifically "pg_".. why invent something new like this '&' prefix
>> when we could just declare that 'pg_superusers' is a role to which
>> all superusers are members?
On 02/01/2020 20:52, Stephen Frost wrote:
> Greetings,
>
> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> On 29/12/2019 23:10, Vik Fearing wrote:
>>> On 29/12/2019 17:31, Tom Lane wrote:
Robert Haas writes:
> On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing
> wrote:
>> I'm
Stephen Frost writes:
> We already have a reserved namespace when it comes to roles,
> specifically "pg_".. why invent something new like this '&' prefix when
> we could just declare that 'pg_superusers' is a role to which all
> superusers are members? Or something along those lines?
Meh. If
Greetings,
* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> On 29/12/2019 23:10, Vik Fearing wrote:
> > On 29/12/2019 17:31, Tom Lane wrote:
> >> Robert Haas writes:
> >>> On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing
> >>> wrote:
> I'm all for this (and even suggested it during the IRC
Robert Haas writes:
> On Thu, Jan 2, 2020 at 12:59 PM Mahendra Singh wrote:
>> While reading code and doing some testing, I found that if we create a
>> temporary table with same name as we created a normal(global) table, then \d
>> is showing only temporary table info.
> That's because the
On Thu, Jan 2, 2020 at 12:59 PM Mahendra Singh wrote:
> While reading code and doing some testing, I found that if we create a
> temporary table with same name as we created a normal(global) table, then \d
> is showing only temporary table info.
That's because the query that \d issues to the
On Thu, Jan 2, 2020 at 1:03 PM David Fetter wrote:
> I believe jq has an excellent one that's available under a suitable
> license.
>
> Making jq a dependency seems like a separate discussion, though. At
> the moment, we don't use git tools like submodel/subtree, and deciding
> which (or whether)
On Thu, Jan 02, 2020 at 02:39:04AM +1300, Thomas Munro wrote:
Hello hackers,
Based on ideas from earlier discussions[1][2], here is an experimental
WIP patch to improve recovery speed by prefetching blocks. If you set
wal_prefetch_distance to a positive distance, measured in bytes, then
the
On Wed, Jan 01, 2020 at 08:57:11PM -0500, Robert Haas wrote:
> On Wed, Jan 1, 2020 at 7:46 PM Tom Lane wrote:
> > David Fetter writes:
> > > On Wed, Jan 01, 2020 at 01:43:40PM -0500, Robert Haas wrote:
> > >> So, if someone can suggest to me how I could read JSON from a tool in
> > >> src/bin
Hi hackers,
While reading code and doing some testing, I found that if we create a
temporary table with same name as we created a normal(global) table, then
\d is showing only temporary table info. I think, ideally we should
display info of both the tables. Below is the example:
postgres=#
I wrote:
> Here is a further step on this journey. It's still just parser
> refactoring, and doesn't (AFAICT) result in any change in generated
> parse trees, but it seems worth posting and committing separately.
Pushed at 5815696bc.
> 2. Add per-column information to the ParseNamespaceItems.
On Thu, Jan 2, 2020 at 12:11 PM Peter Geoghegan wrote:
> The difference between datum_image_eq() and datumIsEqual() is that
> only the former will consider two datums equal when they happen to
> have different TOAST input states -- we need that here.
Ah, OK. Sorry for the noise.
--
Robert Haas
> 2 янв. 2020 г., в 19:13, Robert Haas написал(а):
>
> On Sun, Dec 29, 2019 at 4:13 AM Andrey Borodin wrote:
>> Not loosing data - is a nice property of the database either.
>
> Sure, but there's more than one way to fix that problem, as I pointed
> out in my first response.
Sorry, it took
I think this proposal is the same as [1], so you might want to read that thread.
1-
https://www.postgresql.org/message-id/flat/201DD0641B056142AC8C6645EC1B5F62014B919631%40SYD1217
On Thu, Jan 2, 2020 at 5:38 PM Justin Pryzby wrote:
>
> Is there any appetite for use of array initializer
On Thu, Jan 2, 2020 at 6:42 AM Robert Haas wrote:
> On Mon, Dec 30, 2019 at 6:58 PM Peter Geoghegan wrote:
> > I propose that we adopt the following definition: For an operator
> > class to be safe, its equality operator has to always agree with
> > datum_image_eq() (i.e. two datums must be
On Sat, Dec 28, 2019 at 12:15 PM Fabien COELHO wrote:
>
>
> Bonsoir Vik,
>
> > I recently came across the need for a gcd function (actually I needed
> > lcm) and was surprised that we didn't have one.
>
> Why not.
Proliferation of code in the public namespace; it can displace code
that is
Is there any appetite for use of array initializer rather than memset, as in
attached ? So far, I only looked for "memset.*null", and I can't see that any
of these are hot paths, but saves a cycle or two and a line of code for each.
gcc 4.9.2 with -O2 emits smaller code with array initializer
On Thu, Dec 26, 2019 at 09:57:04AM -0600, Justin Pryzby wrote:
> So rebasified against your patch.
Rebased against your patch in master this time.
>From dadb8dff6ea929d78f3695f606de9ade7674b7a1 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Wed, 27 Nov 2019 20:07:10 -0600
Subject: [PATCH v8
On Thu, Jan 2, 2020 at 5:23 AM Amit Kapila wrote:
> LGTM. I will commit this tomorrow unless someone has any comments.
LGTM, too.
Thanks, Jon, for the patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Stephen Frost writes:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> I'm not objecting to adding it, I'm just curious. In fact, I think
>> that if we do add this, then we should probably add lcm() at the same
>> time, since handling its overflow cases is sufficiently non-trivial to
>>
Greetings,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> I'm not objecting to adding it, I'm just curious. In fact, I think
> that if we do add this, then we should probably add lcm() at the same
> time, since handling its overflow cases is sufficiently non-trivial to
> justify not requiring
Out of curiosity, what was the original use-case for this?
I'm not objecting to adding it, I'm just curious. In fact, I think
that if we do add this, then we should probably add lcm() at the same
time, since handling its overflow cases is sufficiently non-trivial to
justify not requiring users to
Greetings,
* Kohei KaiGai (kai...@heterodb.com) wrote:
> 2020年1月2日(木) 20:56 Alvaro Herrera :
> > On 2020-Jan-02, Kohei KaiGai wrote:
> > > 2020年1月2日(木) 12:16 Alvaro Herrera :
> > > > I think this would need to preserve the notion of multi-table truncates.
> > > > Otherwise it won't be possible to
On Mon, Dec 30, 2019 at 6:58 PM Peter Geoghegan wrote:
> I propose that we adopt the following definition: For an operator
> class to be safe, its equality operator has to always agree with
> datum_image_eq() (i.e. two datums must be bitwise equal after
> detoasting).
I suggested using
Michael Paquier writes:
> For now, please note that I have added an entry in the CF app:
> https://commitfest.postgresql.org/26/2413/
BTW, the referenced patch only removes the configure check for
SSL_get_current_compression, which is fine, but is that even
moving any goalposts? The proposed
On Mon, Dec 30, 2019 at 9:39 AM Bruce Momjian wrote:
> This gets to the heart of something I was hoping to discuss. When is
> something committed? You would think it is when the client receives the
> commit message, but Postgres can commit something, and try to inform the
> client but fail to
Michael Paquier writes:
> Sorry for letting this thread down for a couple of weeks, but I was
> hesitating to apply the last patch of the series as the cleanup of the
> code related to OpenSSL 0.9.8 and 1.0.0 is not that much. An extra
> argument in favor of the removal is that this can allow
Hi all,
Happy new year to all!
As we have entered in January, the commit fest for 2020-01 has
officially begun, and I have switched the status of this commit fest
to "In Progress" a couple of minutes ago. Unfortunately, we still
lack a commit fest manager.
Are there any volunteers? Please
Hi,
(Moving discussion from [1] to this thread)
On 2019-12-28 11:32:26 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-12-27 08:20:17 +0900, Michael Paquier wrote:
> >> Hm, I am not sure that it is actually that much used, such stuff is
> >> very specialized.
>
> > That's true for
On Sun, Dec 29, 2019 at 4:13 AM Andrey Borodin wrote:
> Not loosing data - is a nice property of the database either.
Sure, but there's more than one way to fix that problem, as I pointed
out in my first response.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
Justin Pryzby writes:
> On Mon, Dec 30, 2019 at 02:18:17PM -0500, Tom Lane wrote:
>> This answer is simply broken. You've caused it to estimate half
>> of the bucket, which is an insane estimate for the given bucket
>> boundaries and WHERE constraint.
> I'm fine if the isnan() logic changes,
On Fri, Dec 06, 2019 at 09:21:55AM +0100, Daniel Gustafsson wrote:
> On 6 Dec 2019, at 02:33, Michael Paquier wrote:
>> Another argument in favor of dropping 1.0.0 and 0.9.8 is that
>> it is a pain to check an OpenSSL patch across that many versions,
>> multiplied by the number of Postgres
On Mon, Dec 30, 2019 at 02:18:17PM -0500, Tom Lane wrote:
> > On v12, my test gives:
> > |DROP TABLE t; CREATE TABLE t(t) AS SELECT generate_series(now(), now()+'1
> > day', '5 minutes');
> > |INSERT INTO t VALUES('-infinity');
> > |ALTER TABLE t ALTER t SET STATISTICS 1; ANALYZE t;
> > |explain
Robert Haas writes:
> On Wed, Jan 1, 2020 at 11:01 PM Tom Lane wrote:
>> I see Randall Munroe has weighed in on this topic:
>> https://xkcd.com/2249/
> And the conclusion is ... the whole discussion is stupid?
Well, it's not terribly useful anyway. Arguments founded on an
assumption that
On Tue, Dec 31, 2019 at 10:46:55AM +0100, Peter Eisentraut wrote:
> It appears that the removal of old OpenSSL support is stalled or abandoned
> for now, so this patch set is on hold for now as well, as far as I'm
> concerned. I have committed the change of the Python exception syntax in
> the
Le jeu. 2 janv. 2020 à 13:09, Amit Kapila a
écrit :
> Hi,
>
> I am starting a new thread for some of the decisions for a parallel vacuum
> in the hope to get feedback from more people. There are mainly two points
> for which we need some feedback.
>
> 1. Tomas Vondra has pointed out on the main
On Wed, Jan 01, 2020 at 10:19:52PM +0100, Fabien COELHO wrote:
> Bonjour Michaël, et excellente année 2020 !
Toi aussi! Bonne année.
>> Hmm. Wouldn't it make sense to output the log generated as
>> information from the test using pg_log_info() instead of using
>> fprintf(stderr) (the logs of
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
This patch replaced query string by parse state on few places. It
2020年1月2日(木) 20:56 Alvaro Herrera :
>
> On 2020-Jan-02, Kohei KaiGai wrote:
>
> > 2020年1月2日(木) 12:16 Alvaro Herrera :
> > >
> > > I think this would need to preserve the notion of multi-table truncates.
> > > Otherwise it won't be possible to truncate tables linked by FKs. I
> > > think this
On Wed, Jan 1, 2020 at 11:01 PM Tom Lane wrote:
> Bruce Momjian writes:
> > Does the next decade start on 2020-01-01 or 2021-01-01?
>
> I see Randall Munroe has weighed in on this topic:
>
> https://xkcd.com/2249/
And the conclusion is ... the whole discussion is stupid?
--
Robert Haas
On Tue, Dec 24, 2019 at 2:31 PM Amit Khandekar wrote:
>
> On Tue, 24 Dec 2019 at 10:41, Amit Kapila wrote:
> >
> > On Fri, Dec 20, 2019 at 9:31 AM Amit Khandekar
> > wrote:
> > > Attached are the patches from master back up to 94 branch.
> > >
> > > PG 9.4 and 9.5 have a common patch to be
Hi,
I am starting a new thread for some of the decisions for a parallel vacuum
in the hope to get feedback from more people. There are mainly two points
for which we need some feedback.
1. Tomas Vondra has pointed out on the main thread [1] that by default the
parallel vacuum should be enabled
On 2020-Jan-02, Kohei KaiGai wrote:
> 2020年1月2日(木) 12:16 Alvaro Herrera :
> >
> > I think this would need to preserve the notion of multi-table truncates.
> > Otherwise it won't be possible to truncate tables linked by FKs. I
> > think this means the new entrypoint needs to receive a list of
On Thu, Jan 2, 2020 at 9:03 AM Amit Kapila wrote:
>
> On Thu, Jan 2, 2020 at 8:29 AM Masahiko Sawada
> wrote:
> >
> > On Tue, 31 Dec 2019 at 12:39, Amit Kapila wrote:
> > >
> > > On Mon, Dec 30, 2019 at 6:46 PM Tomas Vondra
> > > wrote:
> > > >
> > > > On Mon, Dec 30, 2019 at 08:25:28AM +0530,
On Tue, Dec 31, 2019 at 6:41 AM Jon Jensen wrote:
>
> Hi, hackers.
>
> Attached are 2 tiny doc typo fixes.
>
LGTM. I will commit this tomorrow unless someone has any comments.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Tue, Dec 31, 2019 at 9:09 AM Amit Kapila wrote:
>
> On Mon, Dec 30, 2019 at 6:46 PM Tomas Vondra
> wrote:
> >
> > On Mon, Dec 30, 2019 at 08:25:28AM +0530, Amit Kapila wrote:
> > >On Mon, Dec 30, 2019 at 2:53 AM Tomas Vondra
> > > wrote:
> > >> I think there's another question we need to ask
70 matches
Mail list logo
