David Rowley wrote:
> It's not for this patch to decide what ports clients can connect to
> PostgreSQL on. As far as I'm aware Windows has no restrictions on what
> ports unprivileged users can listen on. I think we're likely going to
> upset a handful of people if we block the client tools from co
On Wed, Oct 2, 2019 at 2:57 PM vignesh C wrote:
>
> Hi,
>
> I noticed that some of the header files inclusion is not ordered as
> per the usual standard that is followed.
> The attached patch contains the fix for the order in which the header
> files are included.
> Let me know your thoughts on th
On Tue, Oct 8, 2019 at 11:06 AM Michael Paquier wrote:
>
> On Mon, Oct 07, 2019 at 02:14:05PM +0530, vignesh C wrote:
> > Sorry Michael for the miscommunication, the patch was present in the
> > first mail of this mail thread.
> > I'm re-attaching the patch in this mail.
> > Let me know if anythin
On Tue, Oct 8, 2019 at 12:57 AM Robert Haas wrote:
>
> On Sun, Oct 6, 2019 at 6:55 AM Amit Kapila wrote:
> > We wanted to decide how a parallel vacuum should use memory? Can each
> > worker consume maintenance_work_mem to clean up the gin Index or all
> > workers should use no more than mainte
On Tue, Oct 8, 2019 at 1:48 AM Peter Geoghegan wrote:
>
> On Mon, Oct 7, 2019 at 12:28 PM Robert Haas wrote:
> > I would say that sucks, because it makes it harder to set
> > maintenance_work_mem correctly. Not sure how hard it would be to fix,
> > though.
>
> ginInsertCleanup() may now be the w
On Mon, Oct 07, 2019 at 02:14:05PM +0530, vignesh C wrote:
> Sorry Michael for the miscommunication, the patch was present in the
> first mail of this mail thread.
> I'm re-attaching the patch in this mail.
> Let me know if anything is required.
Thanks. It looks like I have been able to miss the
On Mon, Oct 07, 2019 at 05:11:40PM +0200, Juan José Santamaría Flecha wrote:
> About the broken links in win32_port.h, they are all referring to
> ntstatus. As for first case that shows the code groups, there is an up
> to date alternative. There is also an alternative for second case that
> points
On Mon, Oct 07, 2019 at 09:56:20PM +0200, Peter Eisentraut wrote:
> On 2019-10-06 04:20, Noah Misch wrote:
> > elog(ERROR, \
> > "%s yielded %u, expected %s (%u) in file \"%s\" line %u", \
> > #result_expr, result, #expected_expr, expected, __FILE__, __LINE__); \
> I've been meaning t
On Mon, Oct 07, 2019 at 03:31:45PM +0300, Alexey Kondratov wrote:
> On 07.10.2019 4:06, Michael Paquier wrote:
>> - --dry-run coverage is basically the same with the local and remote
>> modes, so it seems like a waste of resource to run it for all the
>> tests and all the modes.
>
> My point was t
From: Amit Kapila Sent: Friday, 4 October 2019 4:50 PM
>>How about I just define them both the same?
>>#define INIT_ALL_ELEMS_ZERO {0}
>>#define INIT_ALL_ELEMS_FALSE {0}
>
>I think using one define would be preferred, but you can wait and see if
>others prefer defining different macros fo
On Mon, 7 Oct 2019 at 03:15, Anders Åstrand wrote:
> Hello
>
> Attached is a patch for adding uri as an encoding option for
> encode/decode. It uses what's called "percent-encoding" in rfc3986
> (https://tools.ietf.org/html/rfc3986#section-2.1).
>
> The background for this patch is that I could e
On Mon, Oct 7, 2019 at 12:28 PM Robert Haas wrote:
> I would say that sucks, because it makes it harder to set
> maintenance_work_mem correctly. Not sure how hard it would be to fix,
> though.
ginInsertCleanup() may now be the worst piece of code in the entire
tree, so no surprised that it gets
Hi,
On 2019-10-07 21:58:08 +0200, Peter Eisentraut wrote:
> On 2019-10-07 19:57, Tom Lane wrote:
> > I'd just put them all in c.h. I see no reason why a new header
> > is helpful.
>
> Assert stuff is already in there, but surely stuff that calls elog()
> doesn't belong in there?
Make it call an
Hi,
On 2019-10-07 13:57:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-10-05 17:08:38 +, Noah Misch wrote:
> >> Report test_atomic_ops() failures consistently, via macros.
>
> > I wonder if we should put these (and a few more, for other types), into
> > a more general place. I
Peter Eisentraut writes:
> On 2019-10-07 19:57, Tom Lane wrote:
>> I'd just put them all in c.h. I see no reason why a new header
>> is helpful.
> Assert stuff is already in there, but surely stuff that calls elog()
> doesn't belong in there?
True, though I had the impression that Andres wanted
Robert Haas writes:
> On Sun, Oct 6, 2019 at 1:17 PM Tom Lane wrote:
>> The attached proposed patch fixes this by making bgworker spawning
>> include a canAcceptConnections() test.
> I think it used to work this way -- not sure if it was ever committed
> this way, but it at least did during deve
On Mon, Oct 7, 2019 at 09:40:22PM +0200, Tomas Vondra wrote:
> On Mon, Oct 07, 2019 at 10:22:22AM -0400, Bruce Momjian wrote:
> > > So essentially the argument is - if you have hw crypto acceleration (aka
> > > AES-NI), then the overhead of all-cluster encryption is so low it does
> > > not make s
On 2019-10-07 19:57, Tom Lane wrote:
> I'd just put them all in c.h. I see no reason why a new header
> is helpful.
Assert stuff is already in there, but surely stuff that calls elog()
doesn't belong in there?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development,
On 2019-10-06 04:20, Noah Misch wrote:
>> Seems like putting ASSERT_{EQ,LT,...}_{U32,S32,...} (or Assert_Eq_...,
>> but that'd imo look weirder than the inconsistency) into c.h would make
>> sense, and EXPECT_ somewhere in common/pg_test.h or such?
>
> Sounds reasonable. For broader use, I would
On Sun, Oct 6, 2019 at 1:17 PM Tom Lane wrote:
> Over in [1] we have a report of a postmaster shutdown that seems to
> have occurred because some client logic was overaggressively spawning
> connection requests, causing the postmaster's child-process arrays to
> be temporarily full, and then some
On Mon, Oct 7, 2019 at 09:14:38AM +0200, Anders Åstrand wrote:
> Hello
>
> Attached is a patch for adding uri as an encoding option for
> encode/decode. It uses what's called "percent-encoding" in rfc3986
> (https://tools.ietf.org/html/rfc3986#section-2.1).
Oh, that's a cool idea. Can you add i
On Mon, Oct 7, 2019 at 3:01 PM Antonin Houska wrote:
> However the design doesn't seem to be stable enough at the
> moment for coding to make sense.
Well, I think the question is whether working further on your patch
could produce some things that everyone would agree are a step
forward. If ever
On Mon, Oct 07, 2019 at 10:22:22AM -0400, Bruce Momjian wrote:
On Sat, Oct 5, 2019 at 09:13:59PM +0200, Tomas Vondra wrote:
On Fri, Oct 04, 2019 at 08:14:44PM -0400, Bruce Momjian wrote:
> On Sat, Oct 5, 2019 at 12:54:35AM +0200, Tomas Vondra wrote:
> > On Fri, Oct 04, 2019 at 06:06:10PM -0400
On Sun, Oct 6, 2019 at 6:55 AM Amit Kapila wrote:
> As per docs [1] (see maintenance_work_mem), the maximum amount of memory used
> by the Vacuum command must be no more than maintenance_work_mem. However,
> during the review/discussion of the "parallel vacuum" patch [2], we observed
> that it
Noah Misch writes:
> [ fetch-add-gcc-xlc-unify-v2.patch ]
This still fails on Apple's compilers. The first failure I get is
ccache gcc -std=gnu99 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-al
Robert Haas wrote:
> On Fri, Oct 4, 2019 at 5:49 PM Bruce Momjian wrote:
> > We spend a lot of time figuring out exactly how to safely encrypt WAL,
> > heap, index, and pgsql_tmp files. The idea of doing this for another
> > 20 types of files --- to find a safe nonce, to be sure a file rewrite
On Mon, Oct 7, 2019 at 5:48 PM Bruce Momjian wrote:
> On Mon, Oct 7, 2019 at 11:26:24AM -0400, Robert Haas wrote:
> > On Mon, Oct 7, 2019 at 11:02 AM Bruce Momjian wrote:
> > > For clog, it is not append-only, and bytes are rewritten (from zero to
> > > non-zero), so there would have to be a ne
On 2019-10-03 16:08, Suraj Kharage wrote:
> It is been observed that when we define the generated columns in WHEN
> condition for BEFORE EACH ROW trigger then server throw an error from
> CreateTrigger().
> whereas, for identity columns, server allows us to create trigger for
> same and trigger ge
Andres Freund writes:
> On 2019-10-05 17:08:38 +, Noah Misch wrote:
>> Report test_atomic_ops() failures consistently, via macros.
> I wonder if we should put these (and a few more, for other types), into
> a more general place. I would like to have them for writing both tests
> like regress.
Hi Nikolay,
I like the new approach. And I agree with the ambition — to split out the
representation from StdRdOptions.
However, with that change, in the AM’s *options() function, it looks as if you
could simply add new fields to the relopt_parse_elt list. That’s still not
true, because parseR
On Fri, Oct 4, 2019 at 11:55:21PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Oct 4, 2019 at 05:40:08PM -0500, Justin Pryzby wrote:
> >> I would argue to include in 12.1, since 12 is what most everyone will use
> >> for
> >> upgrades, and patch for .1 will help people upgrading f
On Fri, Oct 4, 2019 at 9:03 PM Fujii Masao wrote:
>
> On Mon, Sep 30, 2019 at 12:49 AM Fujii Masao wrote:
> >
> > Hi,
> >
> > I got the following assertion failure when I enabled
> > recovery_min_apply_delay
> > and started archive recovery (i.e., I put only recovery.signal not
> > standby.signa
On Sat, Oct 5, 2019 at 5:23 PM Nikolay Shaplov wrote:
> This thread is a follow up to the thread
> https://www.postgresql.org/message-id/2620882.s52SJui4ql@x200m where I've
> been trying to remove StdRdOptions
> structure and replace it with unique structure for each relation kind.
>
> I've deci
Kohei KaiGai writes:
> 2019年10月7日(月) 23:44 Robert Haas :
>> But if we want to stick with the ad-hoc method, we could also just
>> have four possible return values: dominates, dominated-by, both, or
>> neither.
> It seems to me this is a bit different from the purpose of this hook.
> I never inten
On Mon, Oct 7, 2019 at 12:34 PM Bruce Momjian wrote:
> On Mon, Oct 7, 2019 at 12:30:37PM -0400, Robert Haas wrote:
> > On Mon, Oct 7, 2019 at 11:48 AM Bruce Momjian wrote:
> > > Well, I am starting with the things I _know_ need encrypting, and am
> > > then waiting for others to tell me what to
On Mon, Oct 7, 2019 at 12:30:37PM -0400, Robert Haas wrote:
> On Mon, Oct 7, 2019 at 11:48 AM Bruce Momjian wrote:
> > Well, I am starting with the things I _know_ need encrypting, and am
> > then waiting for others to tell me what to add. Cybertec has not
> > provided a list and reasons yet, t
On Mon, Oct 7, 2019 at 11:48 AM Bruce Momjian wrote:
> Well, I am starting with the things I _know_ need encrypting, and am
> then waiting for others to tell me what to add. Cybertec has not
> provided a list and reasons yet, that I have seen. This is why I
> started this public thread, so we c
On Tue, Sep 24, 2019 at 6:34 AM Dilip Kumar wrote:
> On Fri, Sep 13, 2019 at 2:13 AM Robert Haas wrote:
> >
> /*
> * Otherwise, do nothing to cursors held over from a previous
> * transaction.
> */
> if (portal->createSubid == InvalidSubTransactionId)
> continue;
>
> /*
> * Do nothing to auto-hel
On Tue, Sep 24, 2019 at 5:31 AM Amit Kapila wrote:
> After this cleanup, I think we don't need At(Sub)Abort_Portals in
> AbortOutOfAnyTransaction() for the states TBLOCK_(SUB)ABORT and
> friends. This is because AbortTransaction itself would have zapped the
> portal.
Not if the ROLLBACK itself fa
2019年10月7日(月) 23:44 Robert Haas :
>
> On Mon, Oct 7, 2019 at 9:56 AM Tom Lane wrote:
> > We could imagine, maybe, that a hook for the purpose of allowing an
> > additional dimension to be considered would be essentially a path
> > comparison function, returning -1, +1, or 0 depending on whether
>
Robert Haas writes:
> On Mon, Oct 7, 2019 at 9:56 AM Tom Lane wrote:
>> We could imagine, maybe, that a hook for the purpose of allowing an
>> additional dimension to be considered would be essentially a path
>> comparison function, returning -1, +1, or 0 depending on whether
>> path A is dominat
On Mon, Oct 7, 2019 at 11:26:24AM -0400, Robert Haas wrote:
> On Mon, Oct 7, 2019 at 11:02 AM Bruce Momjian wrote:
> > For clog, it is not append-only, and bytes are rewritten (from zero to
> > non-zero), so there would have to be a new nonce for every clog file
> > write to the file system. We
On Mon, Oct 7, 2019 at 9:14 AM Fujii Masao wrote:
> Agreed, too. Do you have any idea to implement that? I've not found out
> "smart" way to do that yet.
>
> One idea is, as Michael suggested, to use SetConfigOption() for all the
> archive recovery parameters at the beginning of the startup proces
On Mon, Oct 7, 2019 at 11:02 AM Bruce Momjian wrote:
> For clog, it is not append-only, and bytes are rewritten (from zero to
> non-zero), so there would have to be a new nonce for every clog file
> write to the file system. We can store the nonce in a separate file,
> but the clog contents and n
On Sun, Oct 6, 2019 at 9:41 AM Michael Paquier wrote:
>
> On Sun, Oct 06, 2019 at 09:06:44AM +0530, vignesh C wrote:
> > I could not find the equivalent links for the same.
> > Should we update the links for the same?
>
> If it could be possible to find equivalent links which could update
> to, it
On Mon, Oct 7, 2019 at 09:44:30AM -0400, Robert Haas wrote:
> On Fri, Oct 4, 2019 at 5:49 PM Bruce Momjian wrote:
> > We spend a lot of time figuring out exactly how to safely encrypt WAL,
> > heap, index, and pgsql_tmp files. The idea of doing this for another
> > 20 types of files --- to find
On 2019-10-02 07:30, Peter Eisentraut wrote:
> On 2019-09-30 21:36, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> Instead of AC_STRUCT_TIMEZONE we use our own variant called
>>> PGAC_STRUCT_TIMEZONE that checks for tzname even if other variants were
>>> found first. But since 63bd0db12199c5df04
On Mon, Oct 7, 2019 at 9:56 AM Tom Lane wrote:
> We could imagine, maybe, that a hook for the purpose of allowing an
> additional dimension to be considered would be essentially a path
> comparison function, returning -1, +1, or 0 depending on whether
> path A is dominated by path B (on this new d
On Sat, Oct 5, 2019 at 09:13:59PM +0200, Tomas Vondra wrote:
> On Fri, Oct 04, 2019 at 08:14:44PM -0400, Bruce Momjian wrote:
> > On Sat, Oct 5, 2019 at 12:54:35AM +0200, Tomas Vondra wrote:
> > > On Fri, Oct 04, 2019 at 06:06:10PM -0400, Bruce Momjian wrote:
> > > > For full-cluster TDE with AES
Robert Haas writes:
> On Sun, Oct 6, 2019 at 3:23 PM Tomas Vondra
> wrote:
>> Can you be more specific why you don't think this approach is not
>> useful? I'm not sure whether you consider all hooks to have this issue
>> or just this proposed one.
> I'll start by admitting that that remark was r
On Mon, Oct 7, 2019 at 9:43 AM Ibrar Ahmed wrote:
> What about have an API to get the single file or list of files? We will use a
> single file in
> our application and other tools can get the benefit of list of files.
That sounds a bit speculative to me. Who is to say that anyone will
find that
On Fri, Oct 4, 2019 at 5:49 PM Bruce Momjian wrote:
> We spend a lot of time figuring out exactly how to safely encrypt WAL,
> heap, index, and pgsql_tmp files. The idea of doing this for another
> 20 types of files --- to find a safe nonce, to be sure a file rewrite
> doesn't reuse the nonce, f
On Mon, Oct 7, 2019 at 6:06 PM Robert Haas wrote:
> On Mon, Oct 7, 2019 at 8:48 AM Asif Rehman wrote:
> > Sure. Though the backup manifest patch calculates and includes the
> checksum of backup files and is done
> > while the file is being transferred to the frontend-end. The manifest
> file its
On Mon, Oct 7, 2019 at 6:05 PM Robert Haas wrote:
> On Mon, Oct 7, 2019 at 8:48 AM Asif Rehman wrote:
> > Sure. Though the backup manifest patch calculates and includes the
> checksum of backup files and is done
> > while the file is being transferred to the frontend-end. The manifest
> file its
On Fri, Oct 4, 2019 at 6:09 PM Michael Paquier wrote:
>
> On Wed, Oct 02, 2019 at 03:30:38AM -0400, Stephen Frost wrote:
> > * David Steele (da...@pgmasters.net) wrote:
> >> On 9/28/19 1:26 PM, Fujii Masao wrote:
> >>> There might be some recovery parameters that we can safely use
> >>> even in cr
On Fri, Oct 4, 2019 at 5:51 AM Natarajan R wrote:
> Why postgres not providing freeing shared memory?
Because it's intended to be used mostly for data structures that live
for the entire server lifetime.
There are some cases, such as various hash tables, where the number of
entries can grow and
On Mon, Oct 7, 2019 at 8:48 AM Asif Rehman wrote:
> Sure. Though the backup manifest patch calculates and includes the checksum
> of backup files and is done
> while the file is being transferred to the frontend-end. The manifest file
> itself is copied at the
> very end of the backup. In parall
On Tue, Jul 23, 2019 at 7:29 PM Tom Lane wrote:
> Parallel workers aren't ever allowed to write, in the current
> implementation, so it's not real obvious why they'd have any
> WAL log files open at all.
Parallel workers are not forbidden to write WAL, nor are they
forbidden to modify blocks. The
On Mon, Oct 7, 2019 at 1:52 PM Rushabh Lathia
wrote:
> Thanks Asif for the patch. I am opting this for a review. Patch is
> bit big, so here are very initial comments to make the review process
> easier.
>
Thanks Rushabh for reviewing the patch.
> 1) Patch seems doing lot of code shuffling,
On 07.10.2019 4:06, Michael Paquier wrote:
On Fri, Oct 04, 2019 at 05:21:25PM +0300, Alexey Kondratov wrote:
I've checked your patch, but it seems that it cannot be applied as is, since
it e.g. adds a comment to 005_same_timeline.pl without actually changing the
test. So I've slightly modified y
On Fri, Oct 4, 2019 at 7:05 PM Dilip Kumar wrote:
>
> On Fri, Oct 4, 2019 at 11:01 AM Amit Kapila wrote:
> >
> > On Fri, Oct 4, 2019 at 10:28 AM Masahiko Sawada
> > wrote:
> >>
> Some more comments..
Thank you!
> 1.
> + for (idx = 0; idx < nindexes; idx++)
> + {
> + if (!for_cleanup)
> + lazy
В письме от понедельник, 7 октября 2019 г. 14:57:14 MSK пользователь Michael
Paquier написал:
> On Sun, Oct 06, 2019 at 03:47:46PM +0300, Nikolay Shaplov wrote:
> > This message is follow up to the "Get rid of the StdRdOptions" patch
> > thread: https://www.postgresql.org/message-id/2620882.s52SJu
Thanks Asif for the patch. I am opting this for a review. Patch is
bit big, so here are very initial comments to make the review process
easier.
1) Patch seems doing lot of code shuffling, I think it would be easy
to review if you can break the clean up patch separately.
Example:
a: setup_throt
On Mon, Oct 7, 2019 at 1:18 PM Michael Paquier wrote:
>
> Hi Vignesh,
>
> On Mon, Oct 07, 2019 at 09:38:41AM +0530, vignesh C wrote:
> > The attached patch in previous mail contain the changes for the updated
> > links requested in [1]. It is not the complete set, but it is the first set
> > for w
Hi Vignesh,
On Mon, Oct 07, 2019 at 09:38:41AM +0530, vignesh C wrote:
> The attached patch in previous mail contain the changes for the updated
> links requested in [1]. It is not the complete set, but it is the first set
> for which I could find the equivalent links.
> https://www.postgresql.org
On Fri, Oct 04, 2019 at 02:27:44PM +0530, Ashutosh Sharma wrote:
> Is there any specific reason for hard coding the *base* of a number
> representing the string in strtouint64(). I understand that currently
> strtouint64() is being used just to convert an input string to decimal
> unsigned value bu
Hello
Attached is a patch for adding uri as an encoding option for
encode/decode. It uses what's called "percent-encoding" in rfc3986
(https://tools.ietf.org/html/rfc3986#section-2.1).
The background for this patch is that I could easily build urls in
plpgsql, but doing the actual encoding of the
On Mon, Oct 7, 2019 at 11:05 AM David Rowley
wrote:
>
> On Mon, 7 Oct 2019 at 18:27, Ashutosh Sharma wrote:
> > AFAIU from the information given in the wiki page -[1], the port
> > numbers in the range of 1-1023 are for the standard protocols and
> > services. And there is nowhere mentioned that
Hi Rob,
On Thu, Oct 03, 2019 at 06:27:34PM +0100, Rob wrote:
> I stumbled on a windows-only bug in pg_basebackup which I've reported as
> #16032
> (https://www.postgresql.org/message-id/16032-4ba56823a2b2805f%40postgresql.org).
>
> I'm pretty sure I've fixed it in the attached patch.
Could it b
On Fri, Oct 04, 2019 at 11:56:31AM +0200, Christoph Berg wrote:
> This is starting to hurt in several places:
>
> 04 11:41 mha@xindi:~$ psql
> 04 11:41 /usr/lib/postgresql/9.2/bin/psql: symbol lookup error:
>/usr/lib/postgresql/9.2/bin/psql: undefined symbol:
> pqsignal
>
>
70 matches
Mail list logo
