On Tue, Jan 27, 2015 at 6:24 AM, Andres Freund wrote:
> Unfortunately that Assert()s when there's a lock conflict because
> e.g. another backend is currently connecting. That's because ProcSleep()
> does a enable_timeout_after(DEADLOCK_TIMEOUT, DeadlockTimeout) - and
> there's no deadlock timeout
On 01/23/2015 02:58 AM, Petr Jelinek wrote:
On 23/01/15 00:40, Andreas Karlsson wrote:
- Renamed some things from int12 to int128, there are still some places
with int16 which I am not sure what to do with.
I'd vote for renaming them to int128 too, there is enough C functions
that user int16 f
Hi PG devs!
Tom Lane writes:
>> Wait for first IO, issue second IO request
>> Compute
>> Already have second IO request, issue third
>> ...
>
>> We'd be a lot less sensitive to IO latency.
>
> It would take about five minutes of coding to prove or disprove this:
> stick a PrefetchBuffer call int
On Mon, Jun 30, 2014 at 5:06 PM, Abhijit Menon-Sen wrote:
> I think having two columns would work. The columns could be called
> "database" and "database_list" and "user" and "user_list" respectively.
>
> The database column may contain one of "all", "sameuser", "samegroup",
> "replication", but i
On Mon, Jan 26, 2015 at 09:20:54AM -0500, Andrew Dunstan wrote:
> On 01/23/2015 02:18 AM, Noah Misch wrote:
> >On Wed, Jan 21, 2015 at 06:51:34PM -0500, Andrew Dunstan wrote:
> >>We could probably fix this fairly easily for non- U+ cases by having
> >>jsonb_to_cstring use a different escape_jso
On Tue, Jan 27, 2015 at 3:18 AM, Jim Nasby wrote:
>
> On 1/23/15 10:16 PM, Amit Kapila wrote:
>>
>> Further, if we want to just get the benefit of parallel I/O, then
>> I think we can get that by parallelising partition scan where different
>> table partitions reside on different disk partitions,
On 23 January 2015 23:55, Alvaro Herrera,
> -j1 is now the same as not specifying anything, and vacuum_one_database
> uses more common code in the parallel and not-parallel cases: the not-
> parallel case is just the parallel case with a single connection, so
> the setup and shutdown is mostly the
This developed a slight merge conflict. I've rebased the attached
version, and I also took the step of getting rid of buf_table.c, as I
think I proposed somewhere upthread. This avoids the overhead of
constructing a BufferTag only to copy it into a BufferLookupEnt, plus
some function calls and so
On Tue, Jan 27, 2015 at 4:21 AM, Robert Haas wrote:
> That's what I hope to find out. :-)
Buildfarm seems happy now. I just gave a try to that on one of my
small Windows VMs and compared the performance with 9.4 for this
simple test case when building with MSVC 2010:
create table aa as select ran
On 2015/01/27 9:15, Jim Nasby wrote:
On 12/22/14 12:50 AM, Etsuro Fujita wrote:
I think ExplainModifyTarget should show the parent of the inheritance
tree in multi-target-table cases, as described there, but noticed that
it doesn't always work like that. Here is an example.
Anything ever happ
On 23 January 2015 21:10, Alvaro Herrera Wrote,
> In case you're up for doing some more work later on, there are two
> ideas
> here: move the backend's TranslateSocketError to src/common, and try to
> merge pg_dump's select_loop function with the one in this new code.
> But that's for another pat
On Mon, Jan 26, 2015 at 9:08 PM, Robert Haas wrote:
>> Contrary opinions? Robert?
>
> I'm totally OK with further aligning just that one allocation.
Of course, now that I think about it, aligning it probably works
mostly because the size is almost exactly one cache line. If it were
any bigger or
On Mon, Jan 26, 2015 at 8:04 PM, Andres Freund wrote:
> On 2015-01-26 19:58:25 -0500, Bruce Momjian wrote:
>> On Tue, Jan 27, 2015 at 01:43:41AM +0100, Andres Freund wrote:
>> > master + 32align.patch:
>> > -c max_connections=400
>> > tps = 183791.872359 (high run vs. run variability)
>> > -c max_
On 2015-01-26 22:03:03 +0100, Andres Freund wrote:
> Attached is a patch trying to this. Doesn't look too bad and lead me to
> discover missing recovery conflicts during a AD ST.
>
> But: It doesn't actually work on standbys, because lock.c prevents any
> stronger lock than RowExclusive from being
On 2015-01-26 19:58:25 -0500, Bruce Momjian wrote:
> On Tue, Jan 27, 2015 at 01:43:41AM +0100, Andres Freund wrote:
> > master + 32align.patch:
> > -c max_connections=400
> > tps = 183791.872359 (high run vs. run variability)
> > -c max_connections=401
> > tps = 185494.98244 (high run vs. run varia
On Tue, Jan 27, 2015 at 01:43:41AM +0100, Andres Freund wrote:
> master + 32align.patch:
> -c max_connections=400
> tps = 183791.872359 (high run vs. run variability)
> -c max_connections=401
> tps = 185494.98244 (high run vs. run variability)
>
> master + 64align.patch:
> -c max_connections=400
>
On 12/26/14 1:38 AM, Abhijit Menon-Sen wrote:
At 2014-09-25 15:40:11 +0530,a...@2ndquadrant.com wrote:
>
>All right, then I'll post a version that addresses Amit's other
>points, adds a new file/function to pgstattuple, acquires content
>locks, and uses HeapTupleSatisfiesVacuum, hint-bit settin
On 12/23/14 12:52 PM, Stephen Frost wrote:
* José Luis Tallón (jltal...@adv-solutions.net) wrote:
>On 12/23/2014 05:29 PM, Stephen Frost wrote:
> >> The "capabilities" would be:
> >>* MAINTENANCE --- Ability to run
> >> VACUUM [ANALYZE | FREEZE] (but not VACUUM FULL),
> >> ANALYZE (
On 2015-01-05 21:43:04 -0500, Bruce Momjian wrote:
> On Fri, Jan 2, 2015 at 06:25:52PM +0100, Andres Freund wrote:
> > I can't run tests right now...
> >
> > What exactly do you want to see with these tests? that's essentially
> > what I've already benchmarked + some fprintfs?
>
> I want to test t
On 2015-01-26 18:30:13 -0600, Jim Nasby wrote:
> On 12/23/14 11:41 AM, Andres Freund wrote:
> >I think it'd generally be useful to have something like errhidecontext()
> >akin to errhidestatement() to avoid things like the above.
> >
> >>>
> >>>Under this proposal, do you want to sup
On 12/23/14 11:41 AM, Andres Freund wrote:
> >I think it'd generally be useful to have something like errhidecontext()
> >akin to errhidestatement() to avoid things like the above.
> >
>
>Under this proposal, do you want to suppress the context/statement
>unconditionally or via some hook/variabl
On 27/01/15 00:51, Andres Freund wrote:
On 2015-01-26 15:35:44 -0800, Peter Geoghegan wrote:
On Mon, Jan 26, 2015 at 3:12 PM, Andrew Gierth
wrote:
Obvious overheads in float8 comparison include having to check for NaN,
and the fact that DatumGetFloat8 on 64bit doesn't get inlined and forces
a
On 12/22/14 12:50 AM, Etsuro Fujita wrote:
I think ExplainModifyTarget should show the parent of the inheritance
tree in multi-target-table cases, as described there, but noticed that
it doesn't always work like that. Here is an example.
Anything ever happen with this?
--
Jim Nasby, Data Archi
On Tue, Jan 27, 2015 at 12:03 AM, Jim Nasby
wrote:
> But one backend can effectively "pin" a buffer more than once, no? If so,
> then ISTM there's some risk that code path A pins and forgets to unpin, but
> path B accidentally unpins for A.
>
The danger is that there's a codepath that refers to
On 1/26/15 5:08 PM, David Steele wrote:
I've written tests to show the rsync vulnerability and another to show
that this can affect a running database. However, to reproduce it
reliably you need to force a checkpoint or have them happening pretty
close together.
Related to this and Stephen's c
On 1/26/15 4:51 PM, Tom Lane wrote:
Jim Nasby writes:
On 1/24/15 3:31 PM, Tom Lane wrote:
Another idea is to teach Valgrind that whenever a backend reduces its
pin count on a shared buffer to zero, that buffer should become undefined
memory.
Shouldn't this technically tie in with Resour
On 2015-01-26 15:35:44 -0800, Peter Geoghegan wrote:
> On Mon, Jan 26, 2015 at 3:12 PM, Andrew Gierth
> wrote:
> > Obvious overheads in float8 comparison include having to check for NaN,
> > and the fact that DatumGetFloat8 on 64bit doesn't get inlined and forces
> > a store/load to memory rather
On Mon, Jan 26, 2015 at 3:12 PM, Andrew Gierth
wrote:
> Obvious overheads in float8 comparison include having to check for NaN,
> and the fact that DatumGetFloat8 on 64bit doesn't get inlined and forces
> a store/load to memory rather than just using a register. Looking at
> those might be more be
> "Peter" == Peter Geoghegan writes:
Peter> What I find particularly interesting about this patch is that it
Peter> makes sorting numerics significantly faster than even sorting
Peter> float8 values,
I get a much smaller difference there than you do.
Obvious overheads in float8 compariso
On 1/26/15 5:11 PM, Jim Nasby wrote:
>> The race condition is a problem for pg_start/stop_backup and friends.
>> In this instance, everything will be shut down when the rsync is
>> running, so there isn't a timestamp race condition to worry about.
>
> Yeah, I'm more concerned about people that use
On Mon, Jan 26, 2015 at 5:36 PM, Josh Berkus wrote:
> In order to get a consensus on moving to a new app I had to explain what
> was wrong with the old app. Eventually I had to use strong language to
> do so, because nobody was paying attention otherwise. While Magnus's
> app isn't my original p
Jim Nasby writes:
> On 1/24/15 3:31 PM, Tom Lane wrote:
>> Another idea is to teach Valgrind that whenever a backend reduces its
>> pin count on a shared buffer to zero, that buffer should become undefined
>> memory.
>
> Shouldn't this technically tie in with ResourceOwners?
No. ResourceOwner
On Mon, Jan 26, 2015 at 5:21 PM, Stephen Frost wrote:
> I don't disagree with you about any of that. I don't think you disagree
> with my comment either. What I'm not entirely clear on is how consensus
> could be reached. Leaving it dormant for the better part of a year
> certainly doesn't appe
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 1/23/15 12:40 PM, Stephen Frost wrote:
> >>>That said, the whole timestamp race condition in rsync gives me the
> >>>heebie-jeebies. For normal workloads maybe it's not that big a deal, but
> >>>when dealing with fixed-size data (ie: Postgr
Jim Nasby writes:
> On 1/23/15 10:16 PM, Amit Kapila wrote:
>> Further, if we want to just get the benefit of parallel I/O, then
>> I think we can get that by parallelising partition scan where different
>> table partitions reside on different disk partitions, however that is
>> a matter of separa
Robert,
> Didn't stop me. And actually, I didn't face a shitstorm of criticism.
> The way I remember it, I got a pretty much unqualified positive
> reaction at the time.
Including from me, because it was a huge improvement on what we had
before. As the new app is.
> Only later, when you had c
On 1/26/15 4:17 PM, Pavel Stehule wrote:
Any way to reduce the code duplication between the array and non-array
versions? Maybe factor out the operator caching code?
I though about it - but there is different checks, different result processing,
different result type.
I didn't find any r
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> When it comes to changing auditing settings, I think that needs to be very
> restrictive. Really, it should be more (or differently) restrictive than SU,
> so that you can effectively audit your superusers with minimal worries about
> superus
On 1/24/15 3:31 PM, Tom Lane wrote:
Another idea is to teach Valgrind that whenever a backend reduces its
pin count on a shared buffer to zero, that buffer should become undefined
memory.
Shouldn't this technically tie in with ResourceOwners? If a pointer takes the
pin count from 1 to 2, the
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 23, 2015 at 1:16 PM, Stephen Frost wrote:
> >> Well, I'm still of the view that there's little to lose by having this
> >> remain out-of-core for a release or three. We don't really all agree
> >> on what we want, and non-core co
2015-01-26 23:01 GMT+01:00 Jim Nasby :
> On 1/24/15 2:48 AM, Pavel Stehule wrote:
>
>> with array_offsets - returns a array of offsets
>>
>
> + returns a offset of first occurrence of some element in a
> array. It uses
> should be
> + returns the offset of the first occurrence of s
On Mon, Jan 26, 2015 at 4:32 PM, Josh Berkus wrote:
> On 01/26/2015 01:29 PM, Robert Haas wrote:
>> Furthermore,
>> if it sucked so bad, why did it take anyone 5 years to get around to
>> rewriting it? It took me less than a year to get around to replacing
>> what you wrote.
>
> Because whoever
On 1/23/15 12:40 PM, Stephen Frost wrote:
>That said, the whole timestamp race condition in rsync gives me the
heebie-jeebies. For normal workloads maybe it's not that big a deal, but when
dealing with fixed-size data (ie: Postgres blocks)? Eww.
The race condition is a problem for pg_start/sto
On 1/24/15 2:48 AM, Pavel Stehule wrote:
with array_offsets - returns a array of offsets
+ returns a offset of first occurrence of some element in a
array. It uses
should be
+ returns the offset of the first occurrence of some element in
an array. It uses
+ returns a
2015-01-26 22:34 GMT+01:00 Jim Nasby :
> On 1/22/15 2:01 PM, Pavel Stehule wrote:
>
>>
>> * I would to simplify a behave of evaluating of message
>> expression - probably I disallow NULL there.
>>
>>
>> Well, the only thing I could see you doing there is throwing a
>> different error i
On 1/23/15 10:16 PM, Amit Kapila wrote:
Further, if we want to just get the benefit of parallel I/O, then
I think we can get that by parallelising partition scan where different
table partitions reside on different disk partitions, however that is
a matter of separate patch.
I don't think we ev
On 2015-01-26 13:32:51 -0800, Josh Berkus wrote:
> On 01/26/2015 01:29 PM, Robert Haas wrote:
> > Furthermore,
> > if it sucked so bad, why did it take anyone 5 years to get around to
> > rewriting it? It took me less than a year to get around to replacing
> > what you wrote.
>
> Because whoever
On 1/22/15 2:01 PM, Pavel Stehule wrote:
* I would to simplify a behave of evaluating of message expression -
probably I disallow NULL there.
Well, the only thing I could see you doing there is throwing a different
error if the hint is null. I don't see that as an improvement. I'
On 01/26/2015 01:29 PM, Robert Haas wrote:
> Furthermore,
> if it sucked so bad, why did it take anyone 5 years to get around to
> rewriting it? It took me less than a year to get around to replacing
> what you wrote.
Because whoever replaced it knew they'd be facing a shitstorm of criticism?
-
On Mon, Jan 26, 2015 at 8:43 AM, Andrew Gierth
wrote:
> Another spinoff from the abbreviation discussion. Peter Geoghegan
> suggested on IRC that numeric would benefit from abbreviation, and
> indeed it does (in some cases by a factor of about 6-7x or more, because
> numeric comparison is no speed
On Mon, Jan 26, 2015 at 4:16 PM, Josh Berkus wrote:
> Well, if it's essentially unusable, then we've reached parity with the
> old app (yes, you deserved that).
No, I didn't. What we had before I wrote that tool was a bunch of
wiki pages you put together which were forever having problems with
m
Hi,
dbase_redo does:
if (InHotStandby)
{
/*
* Lock database while we resolve conflicts to ensure
that
* InitPostgres() cannot fully re-execute concurrently.
This
* a
On 1/23/15 2:15 PM, Stephen Frost wrote:
> >I happen to like the idea specifically because it would allow regular
> >roles to change the auditing settings (no need to be a superuser or to
> >be able to modify postgresql.conf/postgresql.auto.conf)
>
>Is there really a use case for non-superusers
On 01/26/2015 12:46 PM, Robert Haas wrote:
> I find the new tool essentially unusable - having one
> link to the whole thread instead of individual links to just the
> important messages in that thread is a huge regression for me, as is
> the lack of the most recent activity on the summary page.
W
On Mon, Jan 26, 2015 at 4:07 PM, Magnus Hagander wrote:
> I assume what was referred to was that the old cf app would show the last 3
> (I think it was) comments/patches/whatnot on a patch on the summary page
> (and then clickthrough for more details).
Yep.
--
Robert Haas
EnterpriseDB: http://
On Mon, Jan 26, 2015 at 4:01 PM, Magnus Hagander wrote:
> According to my mailbox, you didn't even respond on that thread. But it may
> well be that your email ended up on some other thread and therefor was not
> included when I went back and looked over all the responses I got on it. If
> that wa
On Mon, Jan 26, 2015 at 10:05 PM, Andres Freund
wrote:
> On 2015-01-26 12:54:04 -0800, Peter Geoghegan wrote:
> > On Mon, Jan 26, 2015 at 12:46 PM, Robert Haas
> wrote:
> > > Well, I can't speak to anyone else's opinion, but I'm quite sure I
> > > raised the issue that we need a way to call out
On 2015-01-26 12:54:04 -0800, Peter Geoghegan wrote:
> On Mon, Jan 26, 2015 at 12:46 PM, Robert Haas wrote:
> > Well, I can't speak to anyone else's opinion, but I'm quite sure I
> > raised the issue that we need a way to call out which messages in the
> > thread are important, and I think that's
Hi,
On 2015-01-22 19:56:07 +0100, Andres Freund wrote:
> Hi,
>
> On 2015-01-20 16:28:19 +0100, Andres Freund wrote:
> > I'm analyzing a problem in which a customer had a pg_basebackup (from
> > standby) created 9.2 cluster that failed with "WAL contains references to
> > invalid pages". The faile
On Mon, Jan 26, 2015 at 9:46 PM, Robert Haas wrote:
> On Mon, Jan 26, 2015 at 3:24 PM, Magnus Hagander
> wrote:
> > Yes, and the agreement after that feedback was to try it out and then
> figure
> > out what changes were needed? As about half the feedback said it was
> better
> > without and hal
On 1/26/15 9:46 AM, Pavel Stehule wrote:
The design I thought had been agreed on was to add some new option to
plpgsql's RAISE command which would cause suppression of all CONTEXT lines
not just the most closely nested one. You could argue about whether the
behavior needs to be
On Mon, Jan 26, 2015 at 12:46 PM, Robert Haas wrote:
> Well, I can't speak to anyone else's opinion, but I'm quite sure I
> raised the issue that we need a way to call out which messages in the
> thread are important, and I think that's pretty much what Peter is
> saying, too.
It is.
> I find th
On 1/25/15 7:42 PM, Amit Langote wrote:
On 21-01-2015 PM 07:26, Amit Langote wrote:
Ok, I will limit myself to focusing on following things at the moment:
* Provide syntax in CREATE TABLE to declare partition key
While working on this, I stumbled upon the question of how we deal with
any inde
On Mon, Jan 26, 2015 at 3:24 PM, Magnus Hagander wrote:
> Yes, and the agreement after that feedback was to try it out and then figure
> out what changes were needed? As about half the feedback said it was better
> without and half said it was better with.
Well, I can't speak to anyone else's opi
On 1/25/15 4:23 AM, Pavel Stehule wrote:
I tested a concept iteration over array in format [key1, value1, key2, value2,
.. ] - what is nice, it works for [[key1,value1],[key2, value2], ...] too
It is only a few lines more to current code, and this change doesn't break a
compatibility.
Do you
On Fri, Jan 23, 2015 at 1:16 PM, Stephen Frost wrote:
>> Well, I'm still of the view that there's little to lose by having this
>> remain out-of-core for a release or three. We don't really all agree
>> on what we want, and non-core code can evolve a lot faster than core
>> code, so what's the ru
On Mon, Jan 26, 2015 at 9:20 PM, Robert Haas wrote:
> On Mon, Jan 26, 2015 at 3:13 PM, Peter Geoghegan wrote:
> > On Sun, Jan 25, 2015 at 3:22 AM, Andrew Gierth
> > wrote:
> >> There's a fairly serious readability problem when someone has posted a
> >> patch as a subthread of some more general
On Mon, Jan 26, 2015 at 3:13 PM, Peter Geoghegan wrote:
> On Sun, Jan 25, 2015 at 3:22 AM, Andrew Gierth
> wrote:
>> There's a fairly serious readability problem when someone has posted a
>> patch as a subthread of some more general discussion. For example, look
>> at the "adaptive ndistinct esti
On Sun, Jan 25, 2015 at 3:22 AM, Andrew Gierth
wrote:
> There's a fairly serious readability problem when someone has posted a
> patch as a subthread of some more general discussion. For example, look
> at the "adaptive ndistinct estimator" patch: it's not obvious which
> attachment is the actual
On Mon, Jan 26, 2015 at 2:10 PM, Peter Geoghegan wrote:
> On Mon, Jan 26, 2015 at 11:05 AM, Robert Haas wrote:
>> Now that these issues are fixed and the buildfarm is green again, I'm
>> going to try re-enabling this optimization on Windows. My working
>> theory is that disabling that categorica
On 2015-01-26 14:05:03 -0500, Stephen Frost wrote:
> This capability would be used in conjunction with the SAN snapshot
> capability, it's not intended to be a comparison to what SANs offer.
Oh, on a reread that's now clear. Many of those actually allow hooks to
be run when taking a snapshot, that
On Mon, Jan 26, 2015 at 11:05 AM, Robert Haas wrote:
> Now that these issues are fixed and the buildfarm is green again, I'm
> going to try re-enabling this optimization on Windows. My working
> theory is that disabling that categorically was a mis-diagnosis of the
> real problem, and that now th
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jan 26, 2015 at 1:59 PM, Andres Freund wrote:
> > On 2015-01-26 13:47:02 -0500, Stephen Frost wrote:
> >> Right. We already have a role attribute which allows pg_basebackup
> >> (replication). Also, with pg_basebackup / rolreplication, your
On Fri, Jan 23, 2015 at 12:34 PM, Robert Haas wrote:
> In other words, even on systems that don't HAVE_LOCALE_T, we still
> have to support the default collation and the C collation, and they
> have to behave differently. There's no way to make that work using
> only strxfrm(), because nothing ge
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2015-01-26 13:47:02 -0500, Stephen Frost wrote:
> > Right. We already have a role attribute which allows pg_basebackup
> > (replication). Also, with pg_basebackup / rolreplication, your role
> > is able to read the entire data directory from th
On Mon, Jan 26, 2015 at 1:59 PM, Andres Freund wrote:
> On 2015-01-26 13:47:02 -0500, Stephen Frost wrote:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>> > On Wed, Jan 21, 2015 at 11:27 AM, Adam Brightwell
>> > wrote:
>> > > After re-reading through this thread is seems like EXCLUSIVEBACKUP
On Mon, Jan 26, 2015 at 1:34 PM, Andres Freund wrote:
> I guess we'd need to tie it into PG_exception_stack levels, so it
> correctly handles nesting with sigsetjmp locations. In contrast to
> sigsetjmp() style handlers we can't rely on PG_CATCH cleaning up that
> state.
I was thinking that PG_TR
On 2015-01-26 13:47:02 -0500, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Wed, Jan 21, 2015 at 11:27 AM, Adam Brightwell
> > wrote:
> > > After re-reading through this thread is seems like EXCLUSIVEBACKUP
> > > (proposed
> > > by Magnus) seemed to be a potentially a
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 21, 2015 at 11:27 AM, Adam Brightwell
> wrote:
> > After re-reading through this thread is seems like EXCLUSIVEBACKUP (proposed
> > by Magnus) seemed to be a potentially acceptable alternative.
>
> So this would let you do pg_start_backup
> >> Aside from any reduction in the need
> >> for volatile, this might actually perform slightly better, because
> >> sigsetjmp() is a system call on some platforms. There are probably
> >> few cases where that actually matters, but the one in pq_getmessage(),
> >> for example, might not be entir
On Thu, Jan 22, 2015 at 5:19 PM, Tom Lane wrote:
> David Johnston writes:
>> On Thu, Jan 22, 2015 at 3:04 PM, Tom Lane wrote:
>>> Is that a requirement, and if so why? Because this proposal doesn't
>>> guarantee any such knowledge AFAICS.
>
>> The proposal provides for SQL access to all possibl
On Wed, Jan 21, 2015 at 11:27 AM, Adam Brightwell
wrote:
> After re-reading through this thread is seems like EXCLUSIVEBACKUP (proposed
> by Magnus) seemed to be a potentially acceptable alternative.
So this would let you do pg_start_backup() and pg_stop_backup(), but
it wouldn't let you run pg_b
> That's pretty similar to to PG_ENSURE_ERROR_CLEANUP, except that that is
> also called after FATAL errors. If we do this, we probably should try to
> come up with a easier to understand naming scheme. PG_TRY_WITH_CLEANUP
> vs. PG_ENSURE_ERROR_CLEANUP isn't very clear to a reader.
Yep.
>> Instea
Another spinoff from the abbreviation discussion. Peter Geoghegan
suggested on IRC that numeric would benefit from abbreviation, and
indeed it does (in some cases by a factor of about 6-7x or more, because
numeric comparison is no speed demon).
This patch abbreviates numerics to a weight+initial d
On 2015-01-26 11:18:41 -0500, Tom Lane wrote:
> Also and perhaps more to the point, I'm no longer convinced that this sort
> of thing doesn't require any volatile markers. The fundamental problem
> we're hitting with PG_TRY is that the compiler is optimizing on the
> assumption that no "unexpected
Robert Haas writes:
> On Sun, Jan 25, 2015 at 2:02 PM, Tom Lane wrote:
>> This is scary as hell. I intend to go around and manually audit
>> every single PG_TRY in the current source code, but that is obviously
>> not a long-term solution. Anybody have an idea about how we might
>> get trustwor
On 2015-01-26 10:52:07 -0500, Robert Haas wrote:
> On Sun, Jan 25, 2015 at 2:02 PM, Tom Lane wrote:
> > This is scary as hell. I intend to go around and manually audit
> > every single PG_TRY in the current source code, but that is obviously
> > not a long-term solution. Anybody have an idea abo
On Sun, Jan 25, 2015 at 2:02 PM, Tom Lane wrote:
> This is scary as hell. I intend to go around and manually audit
> every single PG_TRY in the current source code, but that is obviously
> not a long-term solution. Anybody have an idea about how we might
> get trustworthy mechanical detection of
2015-01-26 16:14 GMT+01:00 Tom Lane :
> Pavel Stehule writes:
> > 2015-01-26 14:02 GMT+01:00 Marko Tiikkaja :
> > I am thinking, so solution
>
> > /* if we are doing RAISE, don't report its location */
> > if (estate->err_text == raise_skip_msg)
> > return;
>
> > is too simple, a
Pavel Stehule writes:
> 2015-01-26 14:02 GMT+01:00 Marko Tiikkaja :
> I am thinking, so solution
> /* if we are doing RAISE, don't report its location */
> if (estate->err_text == raise_skip_msg)
> return;
> is too simple, and this part should be fixed. This change can be done b
Andres Freund writes:
> On 2015-01-25 14:02:47 -0500, Tom Lane wrote:
>> I've been looking for other instances of the problem Mark Wilding
>> pointed out, about missing "volatile" markers on variables that
>> are modified in PG_TRY blocks and then used in the PG_CATCH stanzas.
>> There definitely
Andres Freund writes:
> On 2015-01-23 16:47:30 -0500, Tom Lane wrote:
>> There are at least two bugs in reorderbuffer.c's ReorderBufferCommit():
> Thanks for fixing these!
> Unfortunately there's more - we'll currently do bad things if
> transaction commit fails. At the very least the (sub-)tran
On 01/23/2015 02:18 AM, Noah Misch wrote:
On Wed, Jan 21, 2015 at 06:51:34PM -0500, Andrew Dunstan wrote:
The following case has just been brought to my attention (look at the
differing number of backslashes):
andrew=# select jsonb '"\\u"';
jsonb
--
"\u"
2015-01-26 14:02 GMT+01:00 Marko Tiikkaja :
> On 1/26/15 1:44 PM, Pavel Stehule wrote:
>
>> 2015-01-26 13:39 GMT+01:00 Marko Tiikkaja :
>>
>>> On 1/26/15 1:14 PM, Pavel Stehule wrote:
>>>
I afraid about some unexpected side effects of your proposal if somebody
mix languages - these side
On Mon, Jan 26, 2015 at 10:06 PM, Heikki Linnakangas
wrote:
> On 01/26/2015 02:56 PM, Sawada Masahiko wrote:
>>
>> Hi,
>>
>> Attached patch fixes the typo in guc.c.
>> It's typo, I think.
>>
>> diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
>> index f6df077..f4f1965 10064
On 01/26/2015 02:56 PM, Sawada Masahiko wrote:
Hi,
Attached patch fixes the typo in guc.c.
It's typo, I think.
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index f6df077..f4f1965 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -3880,7
On 1/26/15 1:44 PM, Pavel Stehule wrote:
2015-01-26 13:39 GMT+01:00 Marko Tiikkaja :
On 1/26/15 1:14 PM, Pavel Stehule wrote:
I afraid about some unexpected side effects of your proposal if somebody
mix languages - these side effects should not be critical
I have no idea what you're talking
Hi,
Attached patch fixes the typo in guc.c.
It's typo, I think.
Regards,
---
Sawada Masahiko
fix_typo_guc_c.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
2015-01-26 13:39 GMT+01:00 Marko Tiikkaja :
> On 1/26/15 1:14 PM, Pavel Stehule wrote:
>
>> 2015-01-26 13:02 GMT+01:00 Marko Tiikkaja :
>>
>>> I can see where it's a lot nicer not to have the context visible for
>>> people who only care about the contents of the message, but the way it's
>>> done
On 1/26/15 1:14 PM, Pavel Stehule wrote:
2015-01-26 13:02 GMT+01:00 Marko Tiikkaja :
I can see where it's a lot nicer not to have the context visible for
people who only care about the contents of the message, but the way it's
done in PL/PgSQL right now is just not good enough. On the other han
1 - 100 of 109 matches
Mail list logo
