On Thu, Jul 12, 2012 at 12:35:26AM +0300, Peter Eisentraut wrote:
> This might be useful for some people. Here is an emacs configuration
> for perl-mode that is compatible with the new perltidy settings. Note
> that the default perl-mode settings produce indentation that will be
> completely shre
On Wed, Jan 2, 2019 at 11:40 AM Thomas Munro
wrote:
> For the 0001 patch, I'll probably want to reconsider the naming a bit
> ("simple -> "specialized", "generic", ...?), refine (ability to turn
> off the small vector optimisation? optional MemoryContext? ability
> to extend without copying or z
On Mon, Dec 31, 2018 at 9:56 AM Amit Kapila wrote:
>
> To support logical decoding for zheap operations, we need a way to
> ensure zheap tuples can be registered as change streams. One idea
> could be that we make ReorderBufferChange aware of another kind of
> tuples as well, something like this
On Wed, Jan 02, 2019 at 11:35:46AM -0500, Tom Lane wrote:
> In fact, that's demonstrably not so: on my RHEL6 and Fedora boxes,
> /usr/bin/etags isn't owned by any package, because it's a symlink
> managed by the "alternatives" system. It points to /usr/bin/etags.emacs
> which is owned by the emacs
Greetings,
Happy new year!
We would like to follow up again for this issue and fix proposal. Could someone
give some suggestions to the fix proposal? Or other ideas to fix this issue?
Looking forward to your feedbacks!
Best regards,
--
Chengchao Yu
Software Engineer | Microsoft | Azure Dat
Hi Justin,
On Tue, Jan 1, 2019 at 11:17 AM Justin Pryzby wrote:
> dsa_area could not attach to segment
/*
* If we are reached by dsa_free or dsa_get_address,
there must be at
* least one object allocated in the referenced
segment. Otherwise,
That sounds like a plausible approach. Have you done any performance
measurements?
No I haven't yet
In your patch, I would organize the changes to the portal API a bit
differently. Don't change the signature of CreatePortal().
okay
Get rid of PortalSetCurrentTop() and PortalClearCurrent
On Thu, 3 Jan 2019 at 01:50, Surafel Temesgen wrote:
> On Mon, Dec 31, 2018 at 12:38 PM David Rowley
> wrote:
>> Just looking at the v5 patch, it seems not to handle 0 column tables
>> correctly.
> The attach patch contain a fix for it
+ /* if it is zero-column table then we're done */
+ if (
I was surprised yesterday in a difference between querying domains as scalars
versus domains as arrays. As we're all generally aware, when a domain is
queried and projected as a scalar in a result set, it is described
over-the-wire as that column having the oid of the domain's base type, NOT the
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> So I'd like to get to a point where we're comfortable marking these
>> functions leakproof despite the possibility of corner-case failures.
>> We could just decide that the existing failure cases in varstr_cmp are
>> not usefully ex
On 21/11/2018 15:46, Christoph Berg wrote:
> 2018-11-21 15:19:47.394 CET [24453] LOG: starting PostgreSQL 12devel on
> x86_64-pc-linux-gnu, compiled by gcc (Debian 8.2.0-9) 8.2.0, 64-bit
Do we want to do the whole version string, or just "PostgreSQL 12devel"?
--
Peter Eisentraut h
On 15/12/2018 00:04, Alexey Bashtanov wrote:
> I'd like to propose a patch to log bind parameter values not only when
> logging duration,
> but also on error (timeout in particular) or in whatever situation the
> statement normally gets logged.
> This mostly could be useful when the request origi
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Noah Misch writes:
> >>> Either of those solutions sounds fine. Like last time, I'll vote for
> >>> explicitly
> >>> verifying leakproofness.
>
> >> Yeah, I'm leaning in t
Peter Eisentraut writes:
> While we're considering the pg_regress output, what do you think about
> replacing the ==... separator with a standard diff separator like
> "diff %s %s %s\n". This would make the file behave more like a proper
> diff file, for use with other tools. And it shows th
On 06/12/2018 23:56, Michael Paquier wrote:
> On Thu, Dec 06, 2018 at 01:26:30PM -0300, Alvaro Herrera wrote:
>> That means I can just get pg_partition_root() done first, and try to
>> write the queries using that instead of WITH RECURSIVE.
>
> FWIW, I was just writing a patch about this one, so I
On 22/11/2018 14:10, Christoph Berg wrote:
> It's nice that PG_REGRESS_DIFF_OPTS exists, but the diffs are often
> coming from automated build logs where setting the variable after the
> fact doesn't help.
>
> Please consider the attached patch, extension packagers will thank
> you.
Committed.
W
Hi,
On 12/29/18 10:03 AM, Peter Eisentraut wrote:
On 21/12/2018 11:12, Jesper Pedersen wrote:
Here is a patch that passes the -j option from pg_upgrade down to
vacuumdb if supported.
It's not clear to me that that is what is usually wanted.
The point of the post-upgrade analyze script is spe
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Noah Misch writes:
>>> Either of those solutions sounds fine. Like last time, I'll vote for
>>> explicitly
>>> verifying leakproofness.
>> Yeah, I'm leaning in that direction as well. Other than comparisons
>> involving strings
On 2018-Dec-03, Tatsuo Ishii wrote:
> To:
> ---
> -M querymode
> --protocol=querymode
>
> Protocol to use for submitting queries to the server:
>
> simple: use simple query protocol.
>
> extended: use extended q
Donald Dong writes:
> I think #3 is a better choice since it's less invasive and would
> potentially avoid similar problems in the future. I think may worth
> the risks of breaking some extensions. I moved the rule to the
> Makefile.global and added $(X) in case it's set.
Yeah, I think #3 is the
On 4/1/18 9:26 AM, David Rowley wrote:
> On 16 March 2018 at 04:01, Tom Lane wrote:
>> I hadn't been paying much attention to this thread, but I've now taken
>> a quick look at the 2018-02-19 patch, and I've got to say I do not like
>> it much. The changes in createplan.c in particular seem like
Mark writes:
> Am I correct in my understanding that any row that has been modified (i.e.
> UPDATE) is in state HEAPTUPLE_INSERT_IN_PROGRESS so it will not be included
> in the sample?
An update will mark the existing tuple as delete-in-progress and then
insert a new tuple (row version) that's in
Hi Tom,
Thanks for your reply.
Am I correct in my understanding that any row that has been modified (i.e.
UPDATE) is in state HEAPTUPLE_INSERT_IN_PROGRESS so it will not be included
in the sample?
I'm going to rework the application so there is less time between the
DELETE and the COMMIT so I wi
Peter Eisentraut writes:
> On 01/01/2019 17:44, Nikolay Shaplov wrote:
>> +if [ ! $(command -v ctags) ]
>> +then
>> + echo "'ctags' utility is not found" 1>&2
>> + echo "Please install 'ctags' to run make_ctags" 1>&2
>> + exit 1
>> +fi
> This assumes that the ctags and etags programs are part
Mark writes:
> I have a long running job which deletes all of the common_student table and
> then repopulates it. It takes long time to load all the other data and
> commit the transaction. I didn't think the delete inside the transaction
> would have any effect until it is commited or rolled back
Hi,
The doc on COPY CSV says about the backslash-dot sequence:
To avoid any misinterpretation, a \. data value appearing as a
lone entry on a line is automatically quoted on output, and on
input, if quoted, is not interpreted as the end-of-data marker
However this quoting does not happen
On 02/01/2019 17:35, Heikki Linnakangas wrote:
On 28/10/2018 19:32, Andrey Borodin wrote:
Hi everyone!
2 окт. 2018 г., в 6:14, Michael Paquier написал(а):
Andrey, your latest patch does not apply. I am moving this to the next
CF, waiting for your input.
I'm doing preps for CF.
Here's rebas
On 28/10/2018 19:32, Andrey Borodin wrote:
Hi everyone!
2 окт. 2018 г., в 6:14, Michael Paquier написал(а):
Andrey, your latest patch does not apply. I am moving this to the next
CF, waiting for your input.
I'm doing preps for CF.
Here's rebased version.
Thanks, I had another look at thes
On 1/2/19 4:20 PM, Peter Eisentraut wrote:
> On 14/12/2018 12:41, Tomas Vondra wrote:
>> 1) names of the options
>>
>> I'm not particularly happy with calling the option "gucs" - it's an
>> acronym and many users have little idea what GUC stands for. So I think
>> a better name would be desirable
On 14/12/2018 12:41, Tomas Vondra wrote:
> 1) names of the options
>
> I'm not particularly happy with calling the option "gucs" - it's an
> acronym and many users have little idea what GUC stands for. So I think
> a better name would be desirable, but I'm not sure what would that be.
> Options? P
On 1/2/19 11:51 AM, Surafel Temesgen wrote:
>
>
> On Tue, Jan 1, 2019 at 8:38 PM Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> wrote:
>
> >
> > The attached patch include all the comment given by Tomas and i
> > check sql standard about LIMIT and this feature
>
On 26/12/2018 09:47, Fabien COELHO wrote:
> I'm wary of changing the SPI_commit and SPI_rollback interfaces which are
> certainly being used outside the source tree and could break countless
> code, and it seems quite unclean that commit and rollback would do
> anything else but committing or ro
On 26/12/2018 09:20, Fabien COELHO wrote:
> I try to avoid global variables when possible as a principle, because I
> paid to learn that they are bad:-) Maybe I'd do a local struct, declare an
> instance within the function, and write two functions to dump/restore the
> transaction status variab
On 01/01/2019 17:44, Nikolay Shaplov wrote:
> +if [ ! $(command -v ctags) ]
> +then
> + echo "'ctags' utility is not found" 1>&2
> + echo "Please install 'ctags' to run make_ctags" 1>&2
> + exit 1
> +fi
This assumes that the ctags and etags programs are part of packages of
the same name. I don
> I've been trying to use vim for postgres development some yeas ago, but I did
> not manage to do it for log time, as I quit the job etc.
>
> Now I am trying again, but I've lost my .vimrc and notes and had to start from
> the very beginning. I vaguely remember what tools I've been using, but I ha
On 26/11/2018 05:58, Amit Langote wrote:
> On 2018/11/09 14:38, Amit Langote wrote:
>> Rebased due to change in addRangeTableEntryForRelation's API.
>
> Rebased again due to changes in psql's describe output for partitioned tables.
Review:
Is "partition bound" the right term? For list partition
2018年12月31日(月) 22:25 Amit Kapila :
>
> On Mon, Dec 31, 2018 at 5:48 PM Kohei KaiGai wrote:
> >
> > 2018年12月31日(月) 13:10 Amit Kapila :
> > >
> > > On Sun, Dec 30, 2018 at 9:01 AM Kohei KaiGai wrote:
> > > > 2018年12月30日(日) 4:12 Tom Lane :
> > > > >
> > > > > Kohei KaiGai writes:
> > > > > > 2018年1
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Noah Misch writes:
> > Either of those solutions sounds fine. Like last time, I'll vote for
> > explicitly
> > verifying leakproofness.
>
> Yeah, I'm leaning in that direction as well. Other than comparisons
> involving strings, it's not cle
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2018-Dec-14, Stephen Frost wrote:
>
> > > My vote goes to put the keyword inside of and exclusively in the
> > > parenthesized option list.
> >
> > I disagree with the idea of exclusively having concurrently be in the
> > parenth
Hi,
Thank you for looking at it
On Mon, Dec 31, 2018 at 12:38 PM David Rowley
wrote:
> Just looking at the v5 patch, it seems not to handle 0 column tables
> correctly.
>
> For example:
>
> # create table t();
> # insert into t default values;
> # insert into t default values;
>
> $ pg_dump --tab
Hi,
On Wed, 2 Jan 2019 at 12:17, Oleksii Kliukin wrote:
> Thank you. Attached the new version(called it v8) with the following changes
> to the documentation:
Thank you for jumping on it. Your changes look good to me.
I was also thinking about changing the value in PG_CONTROL_VERSION,
becaus
On Wed, Jan 2, 2019, at 11:02, Petr Jelinek wrote:
> The patch generally looks good, but the documentation of max_wal_senders
> needs updating. In config.sgml we say:
>
> > WAL sender processes count towards the total number
> > of connections, so this parameter's value must be less than
> > m
On Tue, Jan 1, 2019 at 8:38 PM Tomas Vondra
wrote:
> >
> > The attached patch include all the comment given by Tomas and i
> > check sql standard about LIMIT and this feature
> >
>
> Unfortunately, it seems the "limit" regression tests fail for some
> reason - the output mismatches the ex
Hi,
On 02/01/2019 10:21, Oleksii Kliukin wrote:
> On Mon, Dec 17, 2018, at 14:10, Alexander Kukushkin wrote:
>> Hi,
>>
>> On Thu, 6 Dec 2018 at 00:55, Petr Jelinek
>> wrote:
Does excluding WAL senders from the max_connections limit and including
max_wal_senders in MaxBackends also imp
В письме от среда, 2 января 2019 г. 0:05:10 MSK пользователь Alvaro Herrera
написал:
> One thing I would like to revise here is to avoid unnecessary API change
> -- for example the RelationHasCascadedCheckOption macro does not really
> need to be renamed because it only applies to views, so there'
On Mon, Dec 17, 2018, at 14:10, Alexander Kukushkin wrote:
> Hi,
>
> On Thu, 6 Dec 2018 at 00:55, Petr Jelinek
> wrote:
> > > Does excluding WAL senders from the max_connections limit and including
> > > max_wal_senders in MaxBackends also imply that we need to add
> > > max_wal_senders to the
46 matches
Mail list logo
