On 2014-06-09 11:24:22 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2014-06-09 09:45:12 -0700, Kevin Grittner wrote:
>
> > I am not sure, given predicate.c's coding, how
> > HEAPTUPLE_DELETE_IN_PROGRESS could cause problems. Could you elaborate,
>
On 2014-06-11 14:50:34 +0200, Magnus Hagander wrote:
> On Wed, Jun 11, 2014 at 2:35 PM, Andres Freund
> wrote:
>
> > On 2014-06-11 14:22:43 +0200, Magnus Hagander wrote:
> > > Yes, but how would you specify for example "i want DDL and all
> > replicatio
On 2014-06-12 00:38:36 -0400, Noah Misch wrote:
> On Tue, Apr 15, 2014 at 03:28:41PM -0400, Tom Lane wrote:
> > Andres Freund writes:
> > >> On 2014-03-27 08:02:35 -0400, Tom Lane wrote:
> > >>> Buildfarm member prairiedog thinks there's
this loop and just return,
> rather than keeping no action loop?
Don't think that'd make it any faster/simpler. We'd be stuck with
duplicate codepaths.
> 10.
> * Iff ri_type = REPLICA_IDENTITY_INDEX, indexOid must be the Oid of a
> suitable
> * index. Otherwise,
Hi,
On 2014-06-12 11:07:31 +0200, Christoph Berg wrote:
> Re: Robert Haas 2014-05-28
>
> > On Tue, May 27, 2014 at 8:22 PM, Maciek Sakrejda
> > wrote:
> > > On Mon, May 26, 2014 at 12:24 AM, Andres Freund
> > > wrote:
> > >> Any chance you'
Hi,
On 2014-06-12 09:15:08 +0200, Andres Freund wrote:
> > 6.
> > elog(ERROR, "cannot handle changeset extraction yet");
> >
> > Shouldn't it be better to use logical replication instead
> > of changeset extraction?
>
> Will change.
I don&
t position on this is that we should leave the code as is <9.4
and HEAPTUPLE_INSERT_IN_PROGRESS for the 9.4/master. Would you be ok
with that? The second best thing imo would be to discern and return
HEAPTUPLE_INSERT_IN_PROGRESS/HEAPTUPLE_DELETE_IN_PROGRESS for the
respective cases.
Which w
't
> throw an error on the server-side.
Brr. Then it'd need to be added to all statements, not just SELECT. I've
my doubts that's going to happen.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 S
_from_bytea(),
lo_from_bytea().
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On 2014-06-12 11:08:35 -0400, Robert Haas wrote:
> On Thu, Jun 12, 2014 at 5:41 AM, Andres Freund wrote:
> >> > With regard to Andres' proposal, I'm not that keen on setting
> >> > dynamic_shared_memory_type='none' by default.
> >
>
On 2014-06-13 13:01:59 +0530, Amit Kapila wrote:
> On Thu, Jun 12, 2014 at 12:45 PM, Andres Freund
> wrote:
> > On 2014-06-12 08:55:59 +0530, Amit Kapila wrote:
> > > Function pg_create_logical_replication_slot() is trying to
> > > save slot twice once during C
On 2014-06-13 14:21:33 +0530, Amit Kapila wrote:
> On Fri, Jun 13, 2014 at 1:45 PM, Andres Freund
> wrote:
> > On 2014-06-13 13:01:59 +0530, Amit Kapila wrote:
> > > Okay, but if it crashes before saving the persistency to permanent
> > > file and there remains a
ecord payload separately.
+1. I've found this annoying in the past.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
the
first place).
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
the rules about how rules
can be used safely even more confusing. I don't think anybody would be
helped by that. If somebody wrote a halfway sane ON UPDATE rule
(i.e. calling a function to do the dirty work) it wouldn't be sane
anymore if somebody starts to use the new syntax...
Greetings,
On 2014-06-14 15:48:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Hi,
> > On 2014-06-14 15:35:33 -0400, Tom Lane wrote:
> >> Given that ON UPDATE rules are close to being a deprecated feature,
> >> it doesn't seem appropriate to work harder than thi
On 2014-06-14 16:44:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-14 15:48:52 -0400, Tom Lane wrote:
> >> Well, it wouldn't be "unsafe" (barring volatile functions in the UPDATE,
> >> which are unsafe already). It might be slow, bu
WAL_DEBUG, but I guess I won't
convince others of that... I think for now the least bad solution is to
add a #ifndef WAL_DEBUG around that assertion.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Traini
uldn't release
with an assertion that still regularly triggers in more or less
'harmless' situations.
I think it might be worthwile to keep it in master to help maintain the
rule against allocations in critical sections. And perhaps as a reminder
that e.g. the checkpointer is doing ba
On 2014-06-14 19:27:03 -0500, Jim Nasby wrote:
> On 6/14/14, 3:51 PM, Andres Freund wrote:
> >>Hm. But you might as well use a trigger, no? Is anyone likely to
> >>>actually be doing such a thing?
> >I don't think anybody is likely to do such a thing on an
message-id/20130926225545.gb26...@awork2.anarazel.de
and quite a few others sanely.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On 2014-06-15 03:12:21 +0200, Andres Freund wrote:
> Hi,
>
> At this year developer's meeting we'd discussed the atomics abstraction
> which is necessary for some future improvements. We'd concluded that a
> overview over the hardware capabilities of the supporte
On 2014-06-17 12:41:26 +0530, Amit Kapila wrote:
> On Fri, May 23, 2014 at 10:01 PM, Amit Kapila
> wrote:
> > On Fri, Jan 31, 2014 at 3:24 PM, Andres Freund
> wrote:
> > > I've pushed a rebased version of the patchset to
> > > http://git.postgresql.org/git
way.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a plan (consensus?) about deprecating rules altogether ?
>
> I believe that was just for user access to them, ie CREATE RULE. I
> don't think there was ever question of purging them from the code base.
I don't think any such concensus has been made? I wish it were, b
On 2014-06-17 18:01:58 +0530, Amit Kapila wrote:
> On Tue, Jun 17, 2014 at 3:56 PM, Andres Freund
> > On 2014-06-17 12:41:26 +0530, Amit Kapila wrote:
> > > 2.
> > > Handling of potentialy_spurious case seems to be pending
> > > in LWLoc
On 2014-06-17 09:46:13 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-17 11:22:17 +0200, Vik Fearing wrote:
> >> On 06/17/2014 09:43 AM, Hannu Krosing wrote:
> >>> Was'nt there a plan (consensus?) about deprecating rules altogether ?
>
> &
ttp://www.postgresql.org/message-id/52495dd3.9010...@vmware.com
Is there actually a significant usecase behind that wish or just a
general demand for being generic? To me it seems fairly unlikely you'd
end up with something useful by doing a minmax index over bounding
boxes.
Greetings,
Andres
On 2014-06-17 20:47:51 +0530, Amit Kapila wrote:
> On Tue, Jun 17, 2014 at 6:35 PM, Andres Freund
> wrote:
> > On 2014-06-17 18:01:58 +0530, Amit Kapila wrote:
> > > On Tue, Jun 17, 2014 at 3:56 PM, Andres Freund
> > > > On 2014-06-17 12:41:26 +0530, Amit Kapila
one away
due to LATERAL. It's now possible to pass data from tables to a SRF,
that previously wasn't possibly unless you'd used a SRF in the targetlist.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Sup
On 2014-06-17 11:48:10 -0400, Robert Haas wrote:
> On Tue, Jun 17, 2014 at 10:31 AM, Andres Freund
> wrote:
> > On 2014-06-17 10:26:11 -0400, Robert Haas wrote:
> >> On Sat, Jun 14, 2014 at 10:34 PM, Alvaro Herrera
> >> wrote:
> >> > Robert Haas wrot
erring to my patch, 16bits was just the width of the
*internal* name that should basically never be looked at. User visible
replication identifiers are always identified by an arbitrary string -
whose format is determined by the user of the replication identifier
facility. *BDR* currently stores the
7;s sometimes, for larger/hotly debated patches, useful to
start anew at significant new version though... 300 message deep threads
get unwiedly.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & S
On 2014-06-17 13:14:26 -0400, Robert Haas wrote:
> On Sat, Jun 14, 2014 at 9:12 PM, Andres Freund wrote:
> > At this year developer's meeting we'd discussed the atomics abstraction
> > which is necessary for some future improvements. We'd concluded that a
On 2014-06-17 12:14:00 -0400, Robert Haas wrote:
> On Tue, Jun 17, 2014 at 12:04 PM, Andres Freund
> wrote:
> >> Well, I'm not the guy who does things with geometric data, but I don't
> >> want to ignore the significant percentage of our users who are. As
&
On 2014-06-17 13:32:51 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2014-06-17 13:14:26 -0400, Robert Haas wrote:
> >> On Sat, Jun 14, 2014 at 9:12 PM, Andres Freund
> >> wrote:
>
> >>> 3) sparcv8: Last released model 1997.
> >
like "available for
> all data types for which there is a natural linear order", I'm not
> sure that that's 100% true; and it's certainly not complete, since
> for instance jsonb's ordering is rather artificial, and the area-based
> orderings of th
On 2014-06-18 12:18:26 +0300, Heikki Linnakangas wrote:
> On 06/17/2014 09:16 PM, Andres Freund wrote:
> >Well, it might be doable to correlate them along one axis, but along
> >both? That's more complicated... And even alongside one axis you
> >already get into probl
On 2014-06-17 16:48:07 -0700, Greg Stark wrote:
> On Tue, Jun 17, 2014 at 11:16 AM, Andres Freund
> wrote:
> > Well, it might be doable to correlate them along one axis, but along
> > both? That's more complicated... And even alongside one axis you
> > alre
x27;ll need to make sure all memory is
allocated beforehand
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-06-18 11:15:15 -0400, Robert Haas wrote:
> On Tue, Jun 17, 2014 at 1:55 PM, Andres Freund wrote:
> > What happens is that gcc will do a syscall triggering the kernel to turn
> > of scheduling; perform the math and store the result; turn scheduling on
> > again. That
oth
using longer strings would be problematic.
In the patch I have the user can actually see them as they're stored in
pg_replication_identifier, but there should never be a need for that.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL D
On 2014-06-18 12:36:13 -0400, Robert Haas wrote:
> On Tue, Jun 17, 2014 at 12:50 PM, Andres Freund
> wrote:
> >> >> I can clearly understand the utility of being able to reset the system
> >> >> ID to a new, randomly-generated system ID - but giving t
Restarting it after ANALYZE went through
would be defeating that purpose, no?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On 2014-06-18 18:54:05 +0200, Andres Freund wrote:
> On 2014-06-18 12:36:13 -0400, Robert Haas wrote:
> > Sure, but that only requires being able to reset the ID randomly, not
> > to a particular value.
>
> I can definitely see a point in a version of the option that genera
On 2014-06-18 13:24:14 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-18 12:51:43 -0400, Tom Lane wrote:
> >> Another angle is that some folks might have tried to automate things
> >> even more, with a wrapper script that starts up the n
ave chosen the current
scheme.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
resetxlog already has the option to change many
related things (e.g. the timeline id). And it'd require another copy of
several hundred lines of code. It's all stored in the control file/checkpoints.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant
On 2014-06-18 13:54:16 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-18 13:24:14 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >>> On 2014-06-18 12:51:43 -0400, Tom Lane wrote:
> >>>> Another angle is that some folks might h
27;t resetting the xlog.
Well, all those actually do write to the xlog (to write a new
checkpoint, containing the updated control file). Since pg_resetxlog has
done all this pretty much since forever renaming it now seems to be a
big hassle for users for pretty much no benefit? This isn't a
On 2014-06-18 15:52:49 -0400, Robert Haas wrote:
> On Wed, Jun 18, 2014 at 3:32 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2014-01-08 23:58:16 +, Robert Haas wrote:
> >> Reduce the number of semaphores used under --disable-spinlocks.
> >>
> >
On 2014-06-18 17:04:49 -0400, Robert Haas wrote:
> On Wed, Jun 18, 2014 at 12:13 PM, Andres Freund
> wrote:
> > There might be cases where that's true, but in the majority of cases
> > where the variable isn't highly contended it's just about the same. In
time os (not posix-y and
discontinued!) - but that doesn't support the gcc syntax used by
s_lock.h. So it's already not supported.
> But if people expect to use Postgres on it, we need BF members.
Yes. But I think it's exceedingly unlikely.
Greetings,
Andres Freund
--
Andre
On 2014-05-23 10:01:37 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The next question is whether to wait till after the branching with this?
>
> +1 for waiting (it's only a couple weeks anyway). This isn't a
> user-facing feature in any way, so I feel no urgenc
On 2014-06-19 19:31:28 +0200, Andres Freund wrote:
> On 2014-05-23 10:01:37 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > The next question is whether to wait till after the branching with this?
> >
> > +1 for waiting (it's only a couple weeks any
omment that they are not used for syscache.
> The only exception was added recently in f01d1ae3a104019:
> DECLARE_INDEX(pg_class_tblspc_relfilenode_index, 3455, on pg_class using
> btree(reltablespace oid_ops, relfilenode oid_ops));
There's no NULLs in here. It can have duplicates, but in tha
On 2014-06-20 17:29:33 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-20 16:50:15 -0400, Alvaro Herrera wrote:
> >> Non-unique indexes in indexing.h
> >> already bear a standard comment that they are not used for syscache.
> >> The
t; think this really would matters much, if we were to do things safely as
> described above.
Part of that seems to be solveable by WAL logging truncations. But I
also think that we need a more robust tracking of the oldest member
offset - we still aren't safe against member wraparounds
On 2014-06-22 12:38:04 +0100, Simon Riggs wrote:
> On 9 April 2014 15:09, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2014-04-09 18:13:29 +0530, Pavan Deolasee wrote:
> >>> An orthogonal issue I noted is that we never check for overflow in the ref
> >
he reply headers are left intact...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
f
> > minutes rather than millisecs.
>
>
> OK, so I think we want to see a patch based on v1 (FATAL approach)
> with a change of the name to idle_in_transaction_session_timeout
> and the units changed to milliseconds.
The idea with the GUC name is that if we ever get support
On 2014-05-05 09:10:17 -0700, Jeff Janes wrote:
> On Sat, May 3, 2014 at 1:11 AM, Andres Freund wrote:
>
> > On 2014-05-03 00:13:45 -0700, Jeff Janes wrote:
> > > On Friday, May 2, 2014, Jeff Janes wrote:
> > Why should we exclude system schemata? That seems more like
On 2014-06-22 09:27:24 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
>
> > The idea with the GUC name is that if we ever get support for
> > cancelling transactions we can name that
> > idle_in_transaction_transaction_timeout?
> > That seems a bit awkward...
On 2014-06-22 19:31:34 +0100, Simon Riggs wrote:
> Yes, that's roughly how the SLRU code works also, so sounds good.
Heh. I rather see that as an argument for it sounding bad :)
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Dev
On 2014-06-23 18:44:24 +0900, Fujii Masao wrote:
> On Sat, Apr 12, 2014 at 9:25 PM, Andres Freund wrote:
> > Hi,
> >
> > The last week I twice had the need to see how many backends had some
> > buffers pinned. Once during development and once while analyzing a stuc
which
> leads to
> + * a PANIC. Fortunately the hash table is small so that's
> unlikely to
> + * happen in practice.
> + */
> + MemoryContextAllowInCriticalSection(MdCxt, true);
> }
> }
Isn't that allowing a bit too much? We e.g. shouldn't allow
_fdvec_alloc() within a crritical section. Might make sense to create a
child context for it.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ocesses use the sigusr1
signal multiplexing.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 2014-06-22 19:03:32 -0700, Kevin Grittner wrote:
> Andres Freund wrote:
>
> > I think we'll want a version of this that just fails the
> > transaction once we have the infrastructure. So we should choose
> > a name that allows for a complimentary GUC.
>
>
On 2014-06-22 20:02:57 -0700, Tom Lane wrote:
> Ian Barwick writes:
> > On 23/06/14 00:58, Andres Freund wrote:
> >> I thought about committing this but couldn't get over this bit. If you
> >> type "SELECT * FROM pg_cat" it'll get autocompleted to
On 2014-06-23 20:29:17 +0900, Fujii Masao wrote:
> On Mon, Jun 23, 2014 at 7:48 PM, Andres Freund wrote:
> > On 2014-06-22 19:03:32 -0700, Kevin Grittner wrote:
> >> Andres Freund wrote:
> >>
> >> > I think we'll want a version of this that just f
On 2014-06-23 13:33:46 +0200, Vik Fearing wrote:
> On 06/22/2014 07:47 PM, Andres Freund wrote:
> > On 2014-06-22 09:27:24 -0700, Kevin Grittner wrote:
> >> Andres Freund wrote:
> > but I don't like that much. Not sure what'd be good, the best I
On 2014-06-23 08:36:02 -0400, Stephen Frost wrote:
> Andres,
>
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > I wonder if it'd make sense to allow a signal to trigger a memory
> > context dump? I and others more than once had the need to examine memory
> >
On 2014-06-23 10:09:49 -0400, Robert Haas wrote:
> On Wed, Jun 18, 2014 at 12:46 PM, Andres Freund
> wrote:
> > On 2014-06-18 12:36:13 -0400, Robert Haas wrote:
> >> > I actually don't think any of the discussions I was involved in had the
> >> >
t differences between
> the atomic ops supported on Intel vs. PPC. For older or more obscure
> platforms, categories 2 and 1 would still be there when needed.
Yea, I think all reasonable systems are in 3). And because of the
fallback to __sync/__atomic intrinsics it's actually much easier to
b
On 2014-06-23 10:45:51 -0400, Robert Haas wrote:
> On Mon, Jun 23, 2014 at 10:11 AM, Andres Freund
> wrote:
> >> > Why? Users and other systems only ever see the external ID. Everything
> >> > leaving the system is converted to the external form. The short id
&g
On 2014-06-23 19:59:10 +0530, Amit Kapila wrote:
> On Tue, Jun 17, 2014 at 8:56 PM, Andres Freund
> wrote:
> > On 2014-06-17 20:47:51 +0530, Amit Kapila wrote:
> > > On Tue, Jun 17, 2014 at 6:35 PM, Andres Freund
> > > wrote:
> > >
> > >
gt; Again, the concern that was expressed at the developer's meeting was
> that the performance characteristics of the CAS loop might be
> significantly different from a native atomic op as to cause us
> heartburn. I think that's a valid concern... but if everything in
> com
On 2014-06-23 09:28:19 -0700, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jun 23, 2014 at 11:16 AM, Andres Freund
> > wrote:
> >> Since fetch-and-add is trivially implemented using CAS, there's not much
> >> need to distinguish between CAS an
On 2014-06-23 12:46:11 -0400, Robert Haas wrote:
> On Mon, Jun 23, 2014 at 12:29 PM, Andres Freund
> wrote:
> >> > That we have support for platforms that we haven't even documented as
> >> > working (e.g. SuperH) or platforms that don't work in the realwo
On 2014-06-23 10:07:36 -0700, Tom Lane wrote:
> Andres Freund writes:
> > I wonder if it'd make sense to allow a signal to trigger a memory
> > context dump? I and others more than once had the need to examine memory
> > usage on production systems and using gdb isn
Hi,
On 2014-06-23 13:00:11 -0700, Jeff Davis wrote:
> On Fri, 2014-06-20 at 09:10 +0000, Andres Freund wrote:
> > To fix, simply move all the all-visible handling outside the critical
> > section. Doing so means that the PD_ALL_VISIBLE on the page won't be
> > included
ed_xacts will have
to suffice.
> BTW, since nobody has commented on the issue of the postgres_fdw
> automatically exempting itself from the timeout, I will plan on
> removing that when the naming argument reaches something resembling
> a conclusion and I go to push this ... unless someone
patch that way? Seems we have
something several people can live with ;)
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
me.
I'd actually say that 99% of the things that need it are not going to
happen because we don't want to break on disk compatibility.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Servi
any architecture,
> In 32-bit or 64-bit architecture adding a char array of length 20 to
> PageHeaderData cause error in regression test.
You likely didn't adapt SizeOfPageHederData.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQ
ecause it could also be NOT
> what someone wants.
I think options=-c idle_in_transaction_timeout=0 in the server config
should already do the trick.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Train
On 2014-06-24 13:03:37 -0400, Noah Misch wrote:
> On Mon, Jun 23, 2014 at 05:16:15PM +0200, Andres Freund wrote:
> > On 2014-06-23 10:29:54 -0400, Robert Haas wrote:
> > > Telling people that
> > > they can't have even the most minimal platform support code in
On 2014-06-24 10:22:08 -0700, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-06-24 13:03:37 -0400, Noah Misch wrote:
> >> If a change has the potential to make some architectures give wrong
> >> answers only at odd times, that's a different kind of problem.
ould do that check? We currently only allow rollbacks
from the corresponding database...
The best idea I have is to do it via autovacuum.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 2014-06-25 10:39:53 -0700, Josh Berkus wrote:
> On 06/25/2014 10:14 AM, Andres Freund wrote:
> > Hi,
> >
> > [sorry for the second copy Robert]
> >
> > Attached is a new version of the atomic operations patch. Lots has
> > changed since the last pos
milarly, I would rip out - or separate into a separate patch - the
> code that tries to use atomic operations to implement TAS if we don't
> already have an implementation in s_lock.h. That might be worth
> doing, if there are any common architectures that don't already
r.
Heh, just wrote the same after reading the beginning of your email ;)
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On 2014-06-26 10:39:01 +0300, Heikki Linnakangas wrote:
> On 06/24/2014 01:27 AM, Andres Freund wrote:
> >Does your change still make
> >sense to you and do you see problem with the current state (as of ecac0e2b)?
>
> Hmm, in the current state, it's again possibl
On 2014-06-25 20:16:08 -0400, Robert Haas wrote:
> On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund wrote:
> > Since it better be legal to manipulate a atomic variable while holding a
> > spinlock we cannot simply use an arbitrary spinlock as backing for
> > atomics. That&#
omics-fallback.h) provides atomics and barriers if not yet
available. By here we're sure that nothing else will provide them.
Then we can provide operations (atomics-generic.h) that build ontop of
the provided functions. E.g. implement _sub, _and et al.
I'll include some more
On 2014-06-26 07:44:14 -0500, Merlin Moncure wrote:
> On Thu, Jun 26, 2014 at 5:20 AM, Andres Freund wrote:
> > On 2014-06-25 20:16:08 -0400, Robert Haas wrote:
> >> On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund
> >> wrote:
> >> > Since it better be lega
On 2014-06-26 11:47:15 -0700, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Jun 26, 2014 at 6:20 AM, Andres Freund
> > wrote:
> >> On 2014-06-25 20:16:08 -0400, Robert Haas wrote:
> >>> I think that's going to fall afoul of Tom's previously-arti
k.h, but I think
that'd be a pretty clear improvement. One open question is what happens
with the SpinlockRelease() when barriers are implemented using spinlocks
and we need a barrier for the SpinlockRelease().
Better ideas, other suggestions?
I'm now going to drink.
Andres
--
Andres Freu
On 2014-06-26 14:13:07 -0700, Tom Lane wrote:
> Andres Freund writes:
> > I think we should rework things so that we fall back to
> > pg_write_barrier(), (*((volatile slock_t *) (lock)) = 0) instead of what
> > we have right now.
>
> Surely it had better be a rea
Hi,
On 2014-06-26 23:01:10 +0200, Andres Freund wrote:
> I think we should rework things so that we fall back to
> pg_write_barrier(), (*((volatile slock_t *) (lock)) = 0) instead of what
> we have right now.
> That'd require to make barrier.h independent from s_lock.h, but I th
901 - 1000 of 9041 matches
Mail list logo
