On Mon, Aug 18, 2014 at 4:01 PM, Michael Paquier
wrote:
> On Mon, Aug 18, 2014 at 3:48 PM, Fujii Masao wrote:
>> On Mon, Aug 18, 2014 at 2:38 PM, Michael Paquier
>> wrote:
> And now looking at your patch there is additional refactoring possible
> with IDENTIFY_SYSTEM and pg_basebackup as well...
On Mon, Aug 18, 2014 at 7:50 PM, Heikki Linnakangas
wrote:
>
> I didn't follow the original discussions, but now that I look at this I
have to wonder:
>
> Why does pg_basebackup -T create the symlink pointing to the wrong
location in the first place, only to fix it later?
Good question.
>Wouldn'
On Tue, Aug 19, 2014 at 12:34 PM, Noah Misch wrote:
> Committed after making several fixes, notably:
Thanks a lot, especially for the additional comments.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
Committed after making several fixes, notably:
On Thu, Aug 14, 2014 at 03:59:57PM +0900, Michael Paquier wrote:
> --- a/src/test/isolation/Makefile
> +++ b/src/test/isolation/Makefile
> @@ -6,12 +6,15 @@ subdir = src/test/isolation
> top_builddir = ../../..
> include $(top_builddir)/src/Makefile
On Fri, Aug 15, 2014 at 11:26:55PM -0400, Noah Misch wrote:
> Barring objections, I will commit your latest patch with some comments about
> why truncation is harmless for those two particular calls.
Done.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Mon, Aug 18, 2014 at 6:35 PM, Heikki Linnakangas
wrote:
>
> On 08/18/2014 08:05 AM, Alvaro Herrera wrote:
>>
>> Marco Nenciarini wrote:
>>
>>> To calculate the md5 checksum I've used the md5 code present in pgcrypto
>>> contrib as the code in src/include/libpq/md5.h is not suitable for large
>>
Hi All,
This is a "proof-of-concept" patch for a new model around role attributes
and fine grained permissions meant to alleviate the current over dependence
on superuser.
This is not yet complete and only serves as a proof-of-concept at this
point, but I wanted to share it in the hopes of receiv
> Thank you for updating the patch.
>
> I did not get error with applying, and compiling.
> It works fine. I think this function code has no problem.
> Could you please submit patch to commit fest app?
Thanks for the review!
As you pointed out, submitted patch to commit fest app.
Regards,
--
F
On 08/19/2014 01:03 AM, Robert Haas wrote:
> 2. I agree that it's not good to have this get controlled by a GUC.
> If the behavior change is big enough that it's going to break clients,
> adding a GUC isn't a sufficient remedy. If it's not, adding a GUC is
> unnecessary.
There's plenty of agreeme
On Mon, Aug 18, 2014 at 12:54 PM, Heikki Linnakangas
wrote:
> server_cert_valid: Did the server present a valid certificate? "yes" or
> "no"
Is this just whether the signature verifies? Or whether the chain is
all verified? Or whether the chain leads to a root in the directory?
Does it include
On Mon, Aug 18, 2014 at 5:47 PM, Robert Haas wrote:
> Sounds pretty weird
I recall GIST being really slow in the distant past in cases where the
page split choices were really bad. Is timerange an interval? Or a
Range?I wonder if the pagesplit function for some of the newish data
types like range
On 08/12/2014 10:26 AM, Steve Crawford wrote:
On 08/07/2014 04:30 PM, Joshua D. Drake wrote:
Hello,
I know this has been brought up before:
http://www.postgresql.org/message-id/20140724080902.ga28...@msg.df7cb.de
For reference, libpq and packaging issues discussed here as well:
http://www
On 08/18/2014 07:33 PM, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
On 08/18/2014 08:05 AM, Alvaro Herrera wrote:
We already have the FNV checksum implementation in the backend --
can't we use that one for this and avoid messing with MD5?
(I don't think we're looking for a cryptographic
On 08/18/2014 07:47 PM, Robert Haas wrote:
I think something's missing from your report, though, because if there
is 3.5 Mb/s of write I/O and only 8 b/s of file growth, nearly all of
the writes are doing something other than extending that file.
Hmm. Sounds like it's churning through temporary
On 18 Aug 2014 20:05, "Greg Stark" wrote:
>Having it in the commit message guarantees the client never has to deal
with strange states like " I know this transaction committed but I know
when"
Sigh. Typing on the phone. "But I *don't* know when"
On 15 Aug 2014 14:54, "Tom Lane" wrote:
>
> Andres Freund writes:
> > On 2014-08-14 12:21:38 -0400, Robert Haas wrote:
> >> And what does that actually do? Send back a result-set, or a new
> >> protocol message?
>
> > What I was thinking of was to return "COMMIT X/X" instead of
> > "COMMIT". Sin
On Mon, Aug 18, 2014 at 1:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> I thought you were printing actual pointer addresses. If you're just
>> printing offsets relative to wherever the segment happens to be
>> mapped, I don't care about that.
>
> Well, that just means that it's not an *obviou
On Fri, Aug 15, 2014 at 7:30 PM, Joachim Wieland wrote:
> Attached is a patch that doesn't add any new functionality or
> features, all it does is get rid of the global variables that
> pg_dump.c is full of.
I think this is an excellent idea.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb
On 2014-08-18 13:27:07 -0400, Tom Lane wrote:
> I still like the idea of providing something comparable to
> MemoryContextStats, rather than creating a SQL interface. The problem
> with a SQL interface is you can't interrogate it unless (1) you are not
> already inside a query and (2) the client i
Robert Haas writes:
> I thought you were printing actual pointer addresses. If you're just
> printing offsets relative to wherever the segment happens to be
> mapped, I don't care about that.
Well, that just means that it's not an *obvious* security risk.
I still like the idea of providing some
Robert Haas wrote:
> Moreover, even if somebody is (rather oddly, IMV) checking for
> command_tag == "COMMIT", it's not going to be a difficult change to
> check for command_tag == "COMMIT" or substr(command_tag,0,7) ==
> "COMMIT ". That's a level of incompatibility that would certainly
> deserve
On Mon, Aug 18, 2014 at 12:51 PM, Andres Freund wrote:
> On 2014-08-18 12:50:27 -0400, Robert Haas wrote:
>> On Mon, Aug 18, 2014 at 12:46 PM, Andres Freund
>> wrote:
>> > You realize that you can pretty much recompute the offsets from the
>> > sizes of the individual allocations anyway?
>>
>> S
On Thu, Jul 3, 2014 at 3:58 PM, Rahila Syed wrote:
> Updated version of patches are attached.
> Changes are as follows
> 1. Improved readability of the code as per the review comments.
> 2. Addition of block_compression field in BkpBlock structure to store
> information about compression of block.
On 2014-08-18 13:06:15 -0400, Robert Haas wrote:
> On Mon, Aug 18, 2014 at 7:19 AM, Rahila Syed wrote:
> >>According to the measurement result, the amount of WAL generated in
> >>"Multiple Blocks in one run" than that in "Single Block in one run".
> >>So ISTM that compression of multiple blocks at
On Mon, Aug 18, 2014 at 7:19 AM, Rahila Syed wrote:
>>According to the measurement result, the amount of WAL generated in
>>"Multiple Blocks in one run" than that in "Single Block in one run".
>>So ISTM that compression of multiple blocks at one run can improve
>>the compression ratio. Am I missin
On Mon, Aug 18, 2014 at 12:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Aug 15, 2014 at 9:54 AM, Tom Lane wrote:
>>> Au contraire: it will break any piece of code that is expecting a COMMIT
>>> command tag to look like exactly "COMMIT" and not "COMMIT something".
>
>> Well, I remember
Robert Haas writes:
> I wouldn't mind having a MemoryContextStats()-type function that could
> be used to print this information out by attaching to the backend with
> gdb, but the utility of exposing it at the SQL level seems very
> marginal to me.
+1 for doing it like that.
On 2014-08-18 12:50:27 -0400, Robert Haas wrote:
> On Mon, Aug 18, 2014 at 12:46 PM, Andres Freund
> wrote:
> > You realize that you can pretty much recompute the offsets from the
> > sizes of the individual allocations anyway?
>
> Sure, if you know the segment base. Do you?
Err? The offset do
On Mon, Aug 18, 2014 at 12:46 PM, Andres Freund wrote:
> On 2014-08-18 12:41:58 -0400, Robert Haas wrote:
>> On Mon, Aug 18, 2014 at 12:00 PM, Andres Freund
>> wrote:
>> >> Unfortunately, that information also has some security implications.
>> >> I'm sure someone trying to exploit any future st
Robert Haas writes:
> On Fri, Aug 15, 2014 at 9:54 AM, Tom Lane wrote:
>> Au contraire: it will break any piece of code that is expecting a COMMIT
>> command tag to look like exactly "COMMIT" and not "COMMIT something".
> Well, I remember debating this with you once before, when we were
> decidi
On Fri, Aug 15, 2014 at 5:59 PM, worthy7 wrote:
> CREATE INDEX USING GIST(timerange);
>
> On 1.3 million rows this took only 30 seconds.
> on 70 million its already taken over a day. I swear it didn't take this long
> on version 9.3
>
>
> Is there some kind of known bug with GIST? CPU is at 4% or
On 2014-08-18 12:41:58 -0400, Robert Haas wrote:
> On Mon, Aug 18, 2014 at 12:00 PM, Andres Freund
> wrote:
> >> Unfortunately, that information also has some security implications.
> >> I'm sure someone trying to exploit any future stack-overrun
> >> vulnerability will be very happy to have more
On Mon, Aug 18, 2014 at 12:00 PM, Andres Freund wrote:
>> Unfortunately, that information also has some security implications.
>> I'm sure someone trying to exploit any future stack-overrun
>> vulnerability will be very happy to have more rather than less
>> information about the layout of the pro
Andres Freund writes:
> On 2014-08-18 12:33:44 -0400, Tom Lane wrote:
>> Well, we could have the implementation code in those modules but not
>> provide any SQL-level access to it without installing an extension.
>> The only extra thing visible in the .h files would be a function or two.
> That'd
On Fri, Aug 15, 2014 at 9:54 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2014-08-14 12:21:38 -0400, Robert Haas wrote:
>>> And what does that actually do? Send back a result-set, or a new
>>> protocol message?
>
>> What I was thinking of was to return "COMMIT X/X" instead of
>> "COMMIT". S
On 2014-08-18 12:33:44 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-08-18 12:27:12 -0400, Tom Lane wrote:
> >> Should we consider putting it into an extension rather than having
> >> it in the core system? That would offer some additional protection
> >> for production systems, whic
Andres Freund writes:
> On 2014-08-18 12:27:12 -0400, Tom Lane wrote:
>> Should we consider putting it into an extension rather than having
>> it in the core system? That would offer some additional protection
>> for production systems, which really shouldn't have much need for
>> this IMO.
> I'
Heikki Linnakangas wrote:
> On 08/18/2014 08:05 AM, Alvaro Herrera wrote:
> >We already have the FNV checksum implementation in the backend -- can't
> >we use that one for this and avoid messing with MD5?
> >
> >(I don't think we're looking for a cryptographic hash here. Am I wrong?)
>
> Hmm. An
On 2014-08-18 12:27:12 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-08-18 11:56:44 -0400, Robert Haas wrote:
> >> I fully agree with the idea of exposing the amount of free memory in
> >> the shared memory segment (as discussed in other emails); that's
> >> critical information. But
Andres Freund writes:
> On 2014-08-18 11:56:44 -0400, Robert Haas wrote:
>> I fully agree with the idea of exposing the amount of free memory in
>> the shared memory segment (as discussed in other emails); that's
>> critical information. But I think exposing address space layout
>> information is
On Fri, Aug 15, 2014 at 8:28 AM, Fujii Masao wrote:
>> Now that we discuss the interactions with other parameters. Another
>> thing that I am wondering about now is: what should we do if we
>> specify s_s_num to a number higher than the elements in s_s_names?
>> Currently, the patch gives the prio
On Fri, Aug 15, 2014 at 7:17 AM, Fujii Masao wrote:
> On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund wrote:
>> On 2014-08-14 14:37:22 -0400, Robert Haas wrote:
>>> On Thu, Aug 14, 2014 at 2:21 PM, Andres Freund
>>> wrote:
>>> > On 2014-08-14 14:19:13 -0400, Robert Haas wrote:
>>> >> That's abou
On 2014-08-18 11:56:44 -0400, Robert Haas wrote:
> On Fri, Aug 15, 2014 at 4:20 AM, Andres Freund wrote:
> > On 2014-08-15 11:12:11 +0300, Marti Raudsepp wrote:
> >> Hi
> >> On Thu, May 8, 2014 at 4:28 PM, Andres Freund
> >> wrote:
> >> > Ok. A new version of the patches implementing that are
>
On Fri, Aug 15, 2014 at 4:20 AM, Andres Freund wrote:
> On 2014-08-15 11:12:11 +0300, Marti Raudsepp wrote:
>> Hi
>> On Thu, May 8, 2014 at 4:28 PM, Andres Freund wrote:
>> > Ok. A new version of the patches implementing that are
>> > attached. Including a couple of small fixups and docs. The lat
On Mon, Aug 18, 2014 at 10:02 PM, Greg Stark wrote:
> On Mon, Aug 18, 2014 at 12:55 PM, Michael Paquier
> wrote:
> Done for 9.4 but the patch is still in master. In fact it's the most
> recent version and I'm still pretty convinced it's a good patch.
If this feature is not going to be part of 9.4
Robert, Tom, and others,
Glad to see good discussion and progress on the locking topic!
My proof of concept code (steps a though e below) avoided any reading or
writing to the pipe (and associated handling of SIGPIPE), it just relied on
postmaster open of PIPE with ENXIO to indicate all is clea
On Mon, Aug 18, 2014 at 7:55 PM, wrote:
> Thanks for the review!
>
>> One question is why reply_fsync is defined as volatile variable?
>> Sorry I could not understand reason of that.
>
> It was affected to time_to_abort -- since it is unnecessary, it deletes.
>
>> Currently patch modifies argumen
=?UTF-8?B?5Zyf5Y2c55q/?= writes:
> where and when using these system attributes?
http://www.postgresql.org/docs/devel/static/ddl-system-columns.html
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
I didn't follow the original discussions, but now that I look at this I
have to wonder:
Why does pg_basebackup -T create the symlink pointing to the wrong
location in the first place, only to fix it later? Wouldn't it make a
lot more sense to create it correctly in the first place?
- Heikki
Hi all,
After switching primary serer while using repliaction slot, the
standby server will not able to connect new primary server.
Imagine this situation, if primary server has two ASYNC standby
servers, also use each replication slots.
And the one standby(A) apply WAL without problems. But anoth
On Mon, Aug 18, 2014 at 09:01:20AM -0400, Robert Haas wrote:
> On Sat, Aug 16, 2014 at 3:28 AM, Noah Misch wrote:
> >> I'd be afraid that a secondary mechanism that mostly-but-not-really
> >> works could do more harm by allowing us to miss bugs in the primary,
> >> pipe-based locking mechanism tha
On Mon, Aug 18, 2014 at 10:05 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 08/18/2014 08:05 AM, Alvaro Herrera wrote:
>
>> Marco Nenciarini wrote:
>>
>> To calculate the md5 checksum I've used the md5 code present in pgcrypto
>>> contrib as the code in src/include/libpq/md5.h is
On 08/18/2014 08:05 AM, Alvaro Herrera wrote:
Marco Nenciarini wrote:
To calculate the md5 checksum I've used the md5 code present in pgcrypto
contrib as the code in src/include/libpq/md5.h is not suitable for large
files. Since a core feature cannot depend on a piece of contrib, I've
moved the
On Mon, Aug 18, 2014 at 12:55 PM, Michael Paquier
wrote:
> I imagine that you also need to fix the release notes accordingly.
> Patch attached for master and REL9_4_STABLE.
Thanks.
Done for 9.4 but the patch is still in master. In fact it's the most
recent version and I'm still pretty convinced
On Sat, Aug 16, 2014 at 3:28 AM, Noah Misch wrote:
> Nice algorithm.
Thanks.
>> I'd be afraid that a secondary mechanism that mostly-but-not-really
>> works could do more harm by allowing us to miss bugs in the primary,
>> pipe-based locking mechanism than the good it would accomplish.
>
> Users
On 08/18/2014 03:04 AM, Marco Nenciarini wrote:
Hi Hackers,
This is the first piece of file level incremental backup support, as
described on wiki page https://wiki.postgresql.org/wiki/Incremental_backup
It is not yet complete, but I wish to share it on the list to receive
comments and suggesti
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 8/17/14 5:19 PM, Stephen Frost wrote:
> > Alvaro, all,
> >
> > * Stephen Frost (sfr...@snowman.net) wrote:
> >> As mentioned, I'll add this to the ALTER TABLE documentation and remove
> >> it from the TABLESPACE docs. That's not done yet but I shou
On Mon, Aug 18, 2014 at 8:30 PM, Greg Stark wrote:
> On Tue, Aug 5, 2014 at 3:41 AM, Noah Misch wrote:
>> This remains open for 9.4. Your proposal to revert the feature in 9.4 and
>> fix
>> it in 9.5 sounds reasonable.
>
> Ok, I've gone ahead and done this. I'm sorry for the delays and confusio
In order to support alternatives to OpenSSL, we need to wean off
applications from using PQgetssl(). To do that, we have to provide an
alternative API to get the same information. PQgetSSL() returns a
pointer directly to the OpenSSL private struct, and you can do anything
with that. We cannot h
On Tue, Aug 5, 2014 at 3:41 AM, Noah Misch wrote:
> This remains open for 9.4. Your proposal to revert the feature in 9.4 and fix
> it in 9.5 sounds reasonable.
Ok, I've gone ahead and done this. I'm sorry for the delays and confusion.
> On Thu, Jul 10, 2014 at 04:15:35PM +0100, Greg Stark wrot
>According to the measurement result, the amount of WAL generated in
>"Multiple Blocks in one run" than that in "Single Block in one run".
>So ISTM that compression of multiple blocks at one run can improve
>the compression ratio. Am I missing something?
Sorry for using unclear terminology. WAL ge
Thanks for the review!
> One question is why reply_fsync is defined as volatile variable?
> Sorry I could not understand reason of that.
It was affected to time_to_abort -- since it is unnecessary, it deletes.
> Currently patch modifies argument of some function (e.g., Handle
> CopyStream, Proc
Thank you for sharing updated patch. With latest 9.5 source code, patch
build is failing with following error message i.e.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C catalog
> schemapg.h
> cd ../../../src/include/catalog && '/opt/local/bin/perl' ./duplicate_oids
> 3255
> make[3]:
hi, Michael
thanks a lot! your reminding lead me go a step forward!
the 7 attributes are system attributes of some table such as pg_class,
pg_type. but now I have a new question:
where and when using these system attributes?
2014-08-18 15:57 GMT+08:00 Michael Paquier :
> On Mon, Aug 18,
On 08/17/2014 07:15 PM, Anastasia Lubennikova wrote:
2014-08-07 0:30 GMT+04:00 Heikki Linnakangas :
* I'm getting two regression failures with this (opr_sanity and join).
opr_sanity failure is corrected.
But there is remain question with join.
I check the latest version of my github repo and
On Mon, Aug 18, 2014 at 4:42 PM, 土卜皿 wrote:
>Recently, for understanding postgresql's optimizer, I read and debug the
> source code. these two days, I read these macros in sysattr.h:
>
> ...
> #define ObjectIdAttributeNumber (-2)
> ...
>
> and the relative codes, but I still did not know why
On Mon, Aug 18, 2014 at 4:12 PM, Fujii Masao wrote:
> On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier
> wrote:
>> On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao wrote:
>>> Attached patch changes \watch so that it displays how long the query takes
>>> if \timing is enabled.
>>>
>>> I didn't refac
hi, all
I am so sorry for asking some questions like this!
Recently, for understanding postgresql's optimizer, I read and debug
the source code. these two days, I read these macros in sysattr.h:
...
#define ObjectIdAttributeNumber (-2)
...
and the relative codes, but I still did not know
On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier
wrote:
> On Thu, Aug 14, 2014 at 11:10 PM, Fujii Masao wrote:
>> Attached patch changes \watch so that it displays how long the query takes
>> if \timing is enabled.
>>
>> I didn't refactor PSQLexec and SendQuery into one routine because
>> the con
On Mon, Aug 18, 2014 at 3:48 PM, Fujii Masao wrote:
> On Mon, Aug 18, 2014 at 2:38 PM, Michael Paquier
> wrote:
>> - IDENTIFY_SYSTEM checks were incorrect (even in HEAD). The following
>> check was done but in 9.4 this command returns 4 fields:
>> (PQntuples(res) != 1 || PQnfields(res) < 3)
>> Th
70 matches
Mail list logo
