On Jun 27, 2015 8:07 AM, "Michael Paquier"
wrote:
>
> On Sat, Jun 27, 2015 at 6:12 AM, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2015-06-24 16:41:48 +0200, Andres Freund wrote:
> >>> I, by now, have come to a different conclusion. I think it's time to
> >>> entirely drop the renegotiatio
2015-06-26 17:28 GMT+02:00 Robert Haas :
> On Wed, Jun 24, 2015 at 7:39 PM, Jim Nasby
> wrote:
> >> I think it's a whole separate topicto Pavel's original proposal
> >> though, and really merits a separate thread. For Pavel's issue I'm all
> >> in favour of just changing the log message, I think
> On Thu, Jun 25, 2015 at 11:55 PM, Robert Haas wrote:
> > On Thu, Jun 25, 2015 at 6:25 PM, Kouhei Kaigai wrote:
> >> I have a serious open item reported 1.5 month ago then reminded
> >> several times has not been fixed up yet.
> >>
> >> 9a28c8860f777e439aa12e8aea7694f8010f3...@bpxm15gp.gisp.nec.
Fujita-san,
> > BTW, if you try newer version of postgres_fdw foreign join patch,
> > please provide me to reproduce the problem/
>
> OK
>
Did you forget to attach the patch, or v17 is in use?
> > I'd like to suggest a solution that re-construct remote tuple according
> > to the fdw_scan_tlist o
Amit Kapila writes:
> On Fri, Jun 26, 2015 at 9:47 PM, Tom Lane wrote:
>> What we evidently need to do is fix things so that the pg_file_settings
>> data gets captured before we suppress duplicates.
>>
>> The simplest change would be to move the whole thing to around line 208 in
>> guc-file.l, j
Amit Kapila writes:
> I have looked into it and found that the main reason for such
> a behaviour is that for those operations it traverses whole
> shared_buffers and it seems to me that we don't need that
> especially for not-so-big tables. We can optimize that path
> by looking into buff mappin
I happened to notice these in a backend's memory context dump:
ident parser context: 0 total in 0 blocks; 0 free (0 chunks); 0 used
hba parser context: 7168 total in 3 blocks; 3920 free (1 chunks); 3248 used
Is there a good reason why these weren't made children of the
PostmasterContext, so t
On Fri, Jun 26, 2015 at 9:45 PM, Amit Kapila
wrote:
> Sometime back on one of the PostgreSQL blog [1], there was
> discussion about the performance of drop/truncate table for
> large values of shared_buffers and it seems that as the value
> of shared_buffers increase the performance of drop/trunc
On 2015-06-27 10:10:04 -0400, Tom Lane wrote:
> In the past we've speculated about fixing the performance of these things
> by complicating the buffer lookup mechanism enough so that it could do
> "find any page for this table/tablespace/database" efficiently.
> Nobody's had ideas that seemed sane
Robert Haas writes:
> On Fri, Jun 26, 2015 at 4:02 PM, Tom Lane wrote:
>> Combining this with my idea about preserving the ConfigVariable list,
>> I'm thinking that it would be a good idea for ProcessConfigFile() to
>> run in a context created for the purpose of processing the config files,
>> ra
On 2015-06-26 14:48:35 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > Rework the way multixact truncations work.
>
> I spent some time this morning reviewing this patch and had some
> comments that I relayed over IM to Andres.
Thanks for that!
> 2. We set PGXACT->delayChkpt while
On 2015-06-27 15:07:05 +0900, Michael Paquier wrote:
> On Sat, Jun 27, 2015 at 6:12 AM, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2015-06-24 16:41:48 +0200, Andres Freund wrote:
> >>> I, by now, have come to a different conclusion. I think it's time to
> >>> entirely drop the renegotiatio
Andres Freund writes:
> On 2015-06-27 15:07:05 +0900, Michael Paquier wrote:
>> +1 for removing on master and just disabling on back-branches.
> The problem with that approach is that it leaves people hanging in the
> dry if they've uncommented the default value, or changed it. That
> doesn't see
On 2015-06-27 12:10:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-06-27 15:07:05 +0900, Michael Paquier wrote:
> >> +1 for removing on master and just disabling on back-branches.
>
> > The problem with that approach is that it leaves people hanging in the
> > dry if they've uncomm
I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
view doesn't act as its author presumably intended. Specifically, it
reads as empty until/unless the current session processes a SIGHUP event.
This is because before that happens, it's depending on having inherited
the state
convert_string_datum() says:
/*
* Note: originally we guessed at a suitable output buffer
size, and
* only needed to call strxfrm twice if our guess was too small.
* However, it seems that some versions of Solaris have buggy
strx
On Sat, Jun 27, 2015 at 9:51 AM, Noah Misch wrote:
> PostgreSQL 9.5 adds a strxfrm() call in bttext_abbrev_convert(), which does
> not account for the Solaris bug. I wish to determine whether that bug is
> still relevant today. If you have access to Solaris with the is_IS.ISO8859-1
> locale inst
27.06.2015, 19:51, Noah Misch kirjoitti:
> convert_string_datum() says:
>
> /*
>* Note: originally we guessed at a suitable output buffer
> size, and
>* only needed to call strxfrm twice if our guess was too small.
>* However, it seems
This patch implements version 1.2 of contrib module pg_trgm.
This supports the triconsistent function, introduced in version 9.4 of the
server, to make it faster to implement indexed queries where some keys are
common and some are rare.
I've included the paths to both upgrade and downgrade betwee
> I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
> view doesn't act as its author presumably intended. Specifically, it
> reads as empty until/unless the current session processes a SIGHUP event.
> This is because before that happens, it's depending on having inherited
>
Tatsuo Ishii writes:
>> I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
>> view doesn't act as its author presumably intended. Specifically, it
>> reads as empty until/unless the current session processes a SIGHUP event.
> I'm just wondering why we did not catch this ear
Main pgbench logic consists of single file pgbench.c which is 4036
lines of code as of today. This is not a small number and I think it
would be nice if it is divided into smaller files because it will make
it easier to maintain, add or change features of pgbench. I will come
up with an idea how t
On Sun, Jun 28, 2015 at 8:20 AM, Tom Lane wrote:
> Tatsuo Ishii writes:
>>> I noticed that in EXEC_BACKEND builds (ie, Windows) the pg_file_settings
>>> view doesn't act as its author presumably intended. Specifically, it
>>> reads as empty until/unless the current session processes a SIGHUP eve
Michael Paquier writes:
> On Sun, Jun 28, 2015 at 8:20 AM, Tom Lane wrote:
>> Yeah, exactly. Unfortunately I see no way to add a useful test, at least
>> not one that will work in installcheck mode. There's no way to predict
>> what will be in the view in that case. Even for "make check", the
Peter Geoghegan writes:
> On Sat, Jun 27, 2015 at 9:51 AM, Noah Misch wrote:
>> PostgreSQL 9.5 adds a strxfrm() call in bttext_abbrev_convert(), which does
>> not account for the Solaris bug. I wish to determine whether that bug is
>> still relevant today. If you have access to Solaris with the
On Sun, Jun 28, 2015 at 10:40 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Sun, Jun 28, 2015 at 8:20 AM, Tom Lane wrote:
>>> Yeah, exactly. Unfortunately I see no way to add a useful test, at least
>>> not one that will work in installcheck mode. There's no way to predict
>>> what will
On Sat, Jun 27, 2015 at 7:14 PM, Tom Lane wrote:
> I think the point of Noah's query is to find out whether "ancient" is an
> accurate description. If indeed nothing newer than Solaris 8 exhibits
> the bug, I'd be okay with not working around it, but otherwise we have
> some decisions to make.
E
On Sat, Jun 27, 2015 at 7:40 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> > I have looked into it and found that the main reason for such
> > a behaviour is that for those operations it traverses whole
> > shared_buffers and it seems to me that we don't need that
> > especially for not-so-big ta
>> I'm just wondering why we did not catch this earlier. If this is
>> because threre's no regression test case for pg_file_settings view,
>
> Yeah, exactly. Unfortunately I see no way to add a useful test, at least
> not one that will work in installcheck mode. There's no way to predict
> what
On Sat, Jun 27, 2015 at 8:06 PM, Gurjeet Singh wrote:
>
> On Fri, Jun 26, 2015 at 9:45 PM, Amit Kapila
wrote:
>>
>> Attached patch implements the above idea and I found that
>> performance doesn't dip much with patch even with large value
>> of shared_buffers. I have also attached script and sql
On Sat, Jun 27, 2015 at 7:19 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> > On Fri, Jun 26, 2015 at 9:47 PM, Tom Lane wrote:
> >> What we evidently need to do is fix things so that the pg_file_settings
> >> data gets captured before we suppress duplicates.
> >>
> >> The simplest change would be
Hi
I am thinking about simplifying a deployment some multiversion PostgreSQL
extensions, and scripts.
With current possibilities, we have to use DO statement, what is not
optimal or possible in some use cases. The implementation of condition
block (possible nested) is very simple.
The proposed s
The proposed syntax of new psql commands
\if_ver_eq 9.2
...
\else
\endif
What do you thinking about it?
Couldn't this kind of thing be done directly with PL/pgSQL?
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
2015-06-28 7:49 GMT+02:00 Fabien COELHO :
>
> The proposed syntax of new psql commands
>> \if_ver_eq 9.2
>> ...
>> \else
>> \endif
>>
>
> What do you thinking about it?
>>
>
> Couldn't this kind of thing be done directly with PL/pgSQL?
>
you can use PL/pgSQL - but there are some limits
* maint
Hello Tatsuo,
Main pgbench logic consists of single file pgbench.c which is 4036 lines
of code as of today. This is not a small number and I think it would be
nice if it is divided into smaller files because it will make it easier
to maintain, add or change features of pgbench.
I do not thi
I was just musing about this today, and was afraid that no one else would
want it!
This would be useful to me in the following use cases which I have right
now:
1. I have a SQL script that invokes \COPY into a temporary table or some
similar thing, preventing most of my logic from being pushed in
On Sun, Jun 28, 2015 at 12:47 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jun 26, 2015 at 4:02 PM, Tom Lane wrote:
>>> Combining this with my idea about preserving the ConfigVariable list,
>>> I'm thinking that it would be a good idea for ProcessConfigFile() to
>>> run in a context crea
37 matches
Mail list logo
