On Thu, Apr 10, 2014 at 9:55 AM, Tom Lane wrote:
> Florian Pflug writes:
> > I was (and still am) not in favour of duplicating the whole quadruple of
> > (state, initialvalue, transferfunction, finalfunction) because it seems
> > excessive. In fact, I believed that doing this would probably be g
On Thu, Apr 10, 2014 at 9:55 AM, Tom Lane wrote:
>
> > I'm pretty sure David Rowley did some benchmarking. The results should be
> > in this thread somewhere I think, but they currently evade me... Maybe
> David
> > can re-post, if he's following this...
>
> I saw benchmarks addressing window agg
2014-04-10 5:50 GMT+02:00 Amit Kapila :
> On Tue, Apr 8, 2014 at 9:07 PM, Pavel Stehule
> wrote:
> > 2014-04-08 6:27 GMT+02:00 Amit Kapila :
> >> So do you want to just print lock time for error'd statements, won't
> >> it better to
> >> do it for non-error'd statements as well or rather I feel i
On Thu, Apr 10, 2014 at 10:44 AM, Rajeev rastogi
wrote:
> On 09 April 2014 12:14, Pavan Deolasee Wrote:
>
> >Whenever I was asked to have a look at implementing this feature, I
> always wondered about the great amount of global state that a backend
> maintains which is normally tied to a single
On Tue, Apr 8, 2014 at 11:32 PM, Bruce Momjian wrote:
> On Sun, Apr 6, 2014 at 11:45:59AM +0530, Amit Kapila wrote:
> In fact, this C program compiled by gcc on Debian issues no compiler
> warnings and returns 'hello', showing that -1 and ~0 compare as equal:
>
> int
> main(int ar
On 09 April 2014 12:14, Pavan Deolasee Wrote:
>Whenever I was asked to have a look at implementing this feature, I always
>wondered about the great amount of global state that a backend maintains which
>is normally tied to a single top transaction. Since AT will have same
>characteristics as a
Hi,
I'm reading xlog.c, and I noticed a comment of
do_pg_abort_backup is typo.
...
10247 * NB: This is only for aborting a non-exclusive backup that
doesn't write
10248 * backup_label. A backup started with pg_stop_backup() needs to be
finished
10249 * with pg_stop_backup().
...
I think "A backu
On Mon, Apr 7, 2014 at 7:10 PM, Tom Lane wrote:
> Amit Kapila writes:
>> On Sat, Apr 5, 2014 at 8:24 PM, Tom Lane wrote:
> AFAICS, pg_ctl already reports to stderr if stderr is a tty. This whole
> issue only comes up when pg_ctl itself is running as a service (which
> I guess primarily means st
On Tue, Apr 8, 2014 at 9:07 PM, Pavel Stehule wrote:
> 2014-04-08 6:27 GMT+02:00 Amit Kapila :
>> So do you want to just print lock time for error'd statements, won't
>> it better to
>> do it for non-error'd statements as well or rather I feel it can be more
>> useful
>> for non-error statements?
Stephen Frost writes:
> Interesting. I'm trying to reason out why we don't have it already in
> similar situations; we can't *always* flatten a subquery...
I think we do, just nobody's particularly noticed (which further reduces
the urgency of finding a solution, I suppose).
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> That sounds a bit confused.
It was- I clearly hadn't followed the thread entirely.
> The quals aren't getting to see rows they
> shouldn't be allowed to see. The issue rather is whether rows that the
> user quals would exclude might get locked anyway be
On Thursday, Apr 10,2014 at 1:15Am, Álvaro Herrera wrote:
>Magnus Hagander wrote:
>>On Wed, Apr 9, 2014 at 4:55 PM, Alvaro Herrera
>>wrote:
>> > So it'd be an array, and by default you'd have something like:
>> > basebackup_skip_path = $log_directory ?
>> >
>> > Maybe use it to skip backup l
On 10 April 2014 01:13, Florian Pflug wrote:
> Also, the *only* reason that SUM(int2|int4) cannot use int8 as it's
> transition type is that it needs to return NULL, not 0, if zero rows
> were aggregates. It might seems that it could just use int8 as state
> with initial value NULL, but that only
On 10/04/14 00:23, Robert Haas wrote:
On Tue, Apr 8, 2014 at 5:27 AM, Ian Barwick wrote:
On 08/04/14 18:22, Ian Barwick wrote:
As it was kind of annoying not to have this when playing around with
event triggers.
This also tightens up the existing tab completion for ALTER TRIGGER,
which conta
On 9 April 2014 22:55, Tom Lane wrote:
> Florian Pflug writes:
>> I was (and still am) not in favour of duplicating the whole quadruple of
>> (state, initialvalue, transferfunction, finalfunction) because it seems
>> excessive. In fact, I believed that doing this would probably be grounds for
>>
On Apr9, 2014, at 23:17 , Florian Pflug wrote:
> On Apr9, 2014, at 21:35 , Tom Lane wrote:
>> A quick test says that avg(int4)
>> is about five percent slower than sum(int4), so that's the kind of hit
>> we'd be taking on non-windowed aggregations if we do it like this.
>
> That's rather surpri
Haribabu Kommi wrote:
> I modified the "autovac_balance_cost" function to balance the costs using
> the number of running workers, instead
> of default vacuum cost parameters.
Just as a heads-up, this patch wasn't part of the commitfest, but I
intend to review it and possibly commit for 9.4. Not
I noticed that pg_identify_object() gives a bogus answer for the text
search object types: it is failing to schema-qualify the objects. I
guess at the time I thought that those object types were global, not
contained within schemas (as seems reasonable. Who would want to have
different text searc
Florian Pflug writes:
> I was (and still am) not in favour of duplicating the whole quadruple of
> (state, initialvalue, transferfunction, finalfunction) because it seems
> excessive. In fact, I believed that doing this would probably be grounds for
> outright rejection of the patch, on the base o
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> So if you wanted user-supplied quals to limit which rows get locked
>> physically, they would need to be applied before the lower LockRows node.
> Right.
>> To my mind, it's not immediately apparent that that is a reasonable
>> ex
On Apr9, 2014, at 20:20 , Tom Lane wrote:
> There was discussion upthread of providing
> two separate forward transition functions, but Florian argued that that
> would do nothing that you couldn't accomplish with a runtime check in
> the forward function. I think that's nonsense though, because
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Dean Rasheed writes:
> > On 10 March 2014 03:36, Craig Ringer wrote:
> >> I've found an issue with updatable security barrier views. Locking is
> >> being pushed down into the subquery. Locking is thus applied before
> >> user-supplied quals are, so we pot
On Apr9, 2014, at 21:35 , Tom Lane wrote:
> As a quick check, I compared aggregation performance in HEAD, non-assert
> builds, with and without --disable-float8-byval on a 64-bit machine.
> So this tests replacing a pass-by-val transition datatype with a
> pass-by-ref one without any other changes
Dean Rasheed writes:
> On 10 March 2014 03:36, Craig Ringer wrote:
>> I've found an issue with updatable security barrier views. Locking is
>> being pushed down into the subquery. Locking is thus applied before
>> user-supplied quals are, so we potentially lock too many rows.
> That has nothing
I wrote:
> ... an invertible aggregate may require a more
> complex transition state data structure --- in particular, if you're
> forced to go from a pass-by-value to a pass-by-reference data type, right
> there you are going to take a big hit in aggregate performance, and there
> is no way for th
According to Joshua Drake on IRC, there is a DDOS in progress against a
customer in the same network as the buildfarm. As a consequence, you
may experience slowness, or inability to connect while they deal with it.
--
Vik
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Wed, Apr 9, 2014 at 11:24 AM, Tom Lane wrote:
>> Maybe we should make *neither* of these the default opclass, and give
>> *neither* the name json_ops.
>
> There's definitely something to be said for that. Default opclasses are
> sensible when there's basically only one behavior that's interest
Dean Rasheed writes:
> OK, I'm marking this ready for committer attention, on the
> understanding that that doesn't include the invtrans_minmax patch.
I've started to look at this patch set. After rereading the thread,
I'm thinking that it's a mistake to just add the inverse transition
function
> How can I pass or set the value of pset variable for an regression test?
I just wrote some tests using \pset columns to control the output.
Having figured out what the point of the patch is I'm pretty happy
with the functionality. It definitely is something I would appreciate
having.
One thing
On 2014-04-05 00:21:47 +0200, Andres Freund wrote:
> On 2014-01-15 21:13:18 -0500, Peter Eisentraut wrote:
> > The attached patch will probably fail to apply because of the pg_proc
> > changes. So if you want to try it out, look into the header for the Git
> > hash it was based off. I'll produce
On Wed, Apr 9, 2014 at 8:24 AM, Tom Lane wrote:
>> Maybe we should make *neither* of these the default opclass, and give
>> *neither* the name json_ops.
>
> There's definitely something to be said for that. Default opclasses are
> sensible when there's basically only one behavior that's interesti
Tom Lane :
> Committed with some additional documentation work. Thanks for
> submitting this!
Thank you for committing. I had not thought of using different structure
for the index. It works faster with my test case, too.
I am sending rebased version of the consistent operator names patch
in cas
Robert Haas writes:
> On Wed, Apr 9, 2014 at 12:24 AM, Rajeev rastogi
> wrote:
>> Now when we grant the lock to particular transaction, depending on type of
>> transaction, bit
>> Mask will be set for either holdMaskByAutoTx or holdMaskByNormalTx.
>> Similar when lock is ungranted, corresponding
Alvaro Herrera writes:
> Robert Haas wrote:
>> On Tue, Apr 8, 2014 at 4:41 PM, Tom Lane wrote:
>>> http://www.postgresql.org/docs/devel/static/gist-builtin-opclasses.html
>>> http://www.postgresql.org/docs/devel/static/gin-builtin-opclasses.html
>>> http://www.postgresql.org/docs/devel/static/spg
Alvaro Herrera writes:
> Tom Lane wrote:
>> One other point here is that non-default opclasses can't be used in
>> UNIQUE/PRIMARY KEY/EXCLUDE constraints, because there's no place to
>> specify an opclass name in those syntaxes. UNIQUE/PRIMARY KEY don't
>> matter here since these aren't btree opc
Robert Haas wrote:
> On Tue, Apr 8, 2014 at 4:41 PM, Tom Lane wrote:
> > I just created sections in the SGML manual chapters about GIST, GIN, and
> > SP-GIST to hold documentation about the standard opclasses provided for
> > them:
> >
> > http://www.postgresql.org/docs/devel/static/gist-builtin-o
Tom Lane wrote:
> > On Wed, Apr 9, 2014 at 2:37 AM, Heikki Linnakangas
> > wrote:
> >> Both of the operator classes are actually much less flexible than I'd like.
>
> > Maybe we should make *neither* of these the default opclass, and give
> > *neither* the name json_ops.
+1. I was thinking the
On Wed, Apr 9, 2014 at 12:24 AM, Rajeev rastogi
wrote:
>> > Deadlock Detection:
>> I'm not sure how this would work out internally
> In order to resolve deadlock, two member variable will be created in the
> structure PROLOCK:
> Bitmask for lock types currently held by autonomous transact
On 2014-04-09 11:50:33 -0400, Robert Haas wrote:
> > One question:
> > 1. I have seen that initdb still creates pg_dynshmem, is it required
> > after your latest changes?
>
> It's only used now if dynamic_shared_memory_type = mmap. I know
> Andres was never a huge fan of the mmap implementation,
On Wed, Apr 9, 2014 at 7:41 AM, Amit Kapila wrote:
> Few Observations:
>
> 1. One new warning has been introduced in code.
> 1>src\backend\port\win32_shmem.c(295): warning C4013:
> 'dsm_set_control_handle' undefined; assuming extern returning int
> Attached patch fixes this warning.
OK, committed
On 2014-04-09 11:42:32 -0400, Bruce Momjian wrote:
> On Wed, Apr 9, 2014 at 09:27:11AM -0400, Robert Haas wrote:
> > On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane wrote:
> > > Robert Haas writes:
> > >> Well, that's sorta my concern. I mean, right now we've got people
> > >> saying "what the heck is
On Wed, Apr 9, 2014 at 09:27:11AM -0400, Robert Haas wrote:
> On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> Well, that's sorta my concern. I mean, right now we've got people
> >> saying "what the heck is a replica identity?". But, if the logical
> >> decoding stu
On Tue, Apr 8, 2014 at 3:08 AM, Michael Paquier
wrote:
> On Tue, Apr 8, 2014 at 1:18 AM, Robert Haas wrote:
>> Not sure if this is exactly the right way to do it, but I agree that
>> something along those lines is a good idea. I also think, maybe even
>> importantly, that we should probably docu
Robert Haas writes:
> On Wed, Apr 9, 2014 at 2:37 AM, Heikki Linnakangas
> wrote:
>> Both of the operator classes are actually much less flexible than I'd like.
> Maybe we should make *neither* of these the default opclass, and give
> *neither* the name json_ops.
There's definitely something to
On Tue, Apr 8, 2014 at 5:27 AM, Ian Barwick wrote:
> On 08/04/14 18:22, Ian Barwick wrote:
>>
>> As it was kind of annoying not to have this when playing around with
>> event triggers.
>>
>> This also tightens up the existing tab completion for ALTER TRIGGER,
>> which contained redundant code for
On Wed, Apr 9, 2014 at 2:37 AM, Heikki Linnakangas
wrote:
> Both of the operator classes are actually much less flexible than I'd like.
> Firstly, they index everything. In many cases, that's not what you want, so
> you end up with much larger indexes than necessary. Secondly, jsonb_ops
> indexes
Magnus Hagander wrote:
> On Wed, Apr 9, 2014 at 4:55 PM, Alvaro Herrera
> wrote:
> > So it'd be an array, and by default you'd have something like:
> > basebackup_skip_path = $log_directory
> > ?
> >
> > Maybe use it to skip backup labels by default as well.
> > basebackup_skip_pa
On Wed, Apr 9, 2014 at 12:40 PM, Peter Geoghegan wrote:
> On Wed, Apr 9, 2014 at 1:21 AM, Heikki Linnakangas
> wrote:
> > I didn't say that. On the contrary, I think the shotgun approach
> jsonb_ops
> > and jsonb_hash_ops take is too broad. It should be possible to specify
> what
> > to index in
Kyotaro HORIGUCHI writes:
> Oops! I found a bug in this patch. The previous v8 patch missed
> the case that build_index_pathkeys() could build a partial
> pathkeys from the index tlist.
TBH I think that's barely the tip of the iceberg of cases where this
patch will get the wrong answer. It looks
On Wed, Apr 9, 2014 at 10:37 AM, Heikki Linnakangas wrote:
> The ship has cleatly sailed to add parameterized opclasses to 9.4, but
> let's keep it in mind when we decide on the defaults.
>
> In the absence of parameterizable opclasses, it would be much more
> flexible to have opclasses that inde
On Wed, Apr 9, 2014 at 4:55 PM, Alvaro Herrera wrote:
> Magnus Hagander wrote:
>
> > While pg_log is definitely the most common one being the default on many
> > platforms, we'll still be missing other ones. Should we really hardcode
> it,
> > or should we somehow derive it from the settings for l
Magnus Hagander wrote:
> While pg_log is definitely the most common one being the default on many
> platforms, we'll still be missing other ones. Should we really hardcode it,
> or should we somehow derive it from the settings for log_directory instead?
>
> As a more general discussion, is this s
On Wed, Apr 9, 2014 at 2:06 AM, Prabakaran, Vaishnavi <
vaishna...@fast.au.fujitsu.com> wrote:
> Hi all,
>
>
>
> Following the discussion in message id -
> cahgqgwffmor4ecugwhzpaapyqbsekdg66vmj1rvej6z-ega...@mail.gmail.com , I
> have developed the patch which gives option to user to exclude pg_l
On 2014-04-09 10:26:25 -0400, Tom Lane wrote:
> Andres Freund writes:
> > It's not unreasonable to argue that we just shouldn't optimize for
> > several pins held by the same backend for the same and always touch the
> > global count.
>
> NAK.
Note I didn't implement it because I wasn't too conv
Andres Freund writes:
> It's not unreasonable to argue that we just shouldn't optimize for
> several pins held by the same backend for the same and always touch the
> global count.
NAK. That would be a killer because of increased contention for buffer
headers. The code is full of places where a
On 2014-04-09 10:09:44 -0400, Tom Lane wrote:
> The resource managers are interesting to bring up in this context.
> That mechanism didn't exist when PrivateRefCount was invented.
> Is there a way we could lay off the work onto the resource managers?
> (I don't see one right at the moment, but I'm
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
>> count itself. While I understand overflowing int32 counter will take a
>> large number of pins on the same buffer, it can still happen in the
On Wed, Apr 9, 2014 at 9:38 AM, Andres Freund wrote:
> On 2014-04-09 09:17:59 -0400, Robert Haas wrote:
>> On Wed, Apr 9, 2014 at 8:32 AM, Andres Freund wrote:
>> > I've tried to reproduce problems around this (when I wrote this), but
>> > it's really hard to construct cases that need more than 8
Dilip kumar writes:
> On 09 April 2014 13:31, Nicolas Barbier Wrote
>> Do you have a real-world example use case of such joins, to offset the
>> extra planner time that will likely have to be paid (even for queries
>> for which the functionality ends up not being used)?
> I think this will be mor
On 2014-04-09 09:17:59 -0400, Robert Haas wrote:
> On Wed, Apr 9, 2014 at 8:32 AM, Andres Freund wrote:
> > I've tried to reproduce problems around this (when I wrote this), but
> > it's really hard to construct cases that need more than 8 pins. I've
> > tested performance for those cases by simpl
On Wed, Apr 9, 2014 at 1:02 AM, Tom Lane wrote:
> Robert Haas writes:
>> Well, that's sorta my concern. I mean, right now we've got people
>> saying "what the heck is a replica identity?". But, if the logical
>> decoding stuff becomes popular, as I hope it will, that's going to be
>> an importa
On Wed, Apr 9, 2014 at 8:32 AM, Andres Freund wrote:
> I've tried to reproduce problems around this (when I wrote this), but
> it's really hard to construct cases that need more than 8 pins. I've
> tested performance for those cases by simply not using the array, and
> while the performance suffer
On 2014-04-09 18:13:29 +0530, Pavan Deolasee wrote:
> On Wed, Apr 9, 2014 at 6:02 PM, Andres Freund wrote:
> > I've tried to reproduce problems around this (when I wrote this), but
> > it's really hard to construct cases that need more than 8 pins. I've
> > tested performance for those cases by sim
On Wed, Apr 9, 2014 at 6:02 PM, Andres Freund wrote:
>
>
> I've tried to reproduce problems around this (when I wrote this), but
> it's really hard to construct cases that need more than 8 pins. I've
> tested performance for those cases by simply not using the array, and
> while the performance su
On 2014-04-09 08:22:15 -0400, Robert Haas wrote:
> On Wed, Apr 9, 2014 at 5:34 AM, Simon Riggs wrote:
> > We've got to the stage now that saving this much memory is essential,
> > so this patch is a must-have.
> >
> > The patch does all I would expect and no more, so approach and details
> > look
On Wed, Apr 9, 2014 at 5:34 AM, Simon Riggs wrote:
> We've got to the stage now that saving this much memory is essential,
> so this patch is a must-have.
>
> The patch does all I would expect and no more, so approach and details
> look good to me.
>
> Performance? Discussed many years ago, but I
On Tue, Apr 8, 2014 at 9:15 PM, Robert Haas wrote:
> Apparently not. However, I'm fairly sure this is a step toward
> addressing the complaints previously raised, even if there may be some
> details people still want changed, so I've gone ahead and committed
> it.
Few Observations:
1. One new w
Thanks a lot Michael.
On Wed, Apr 9, 2014 at 3:59 PM, Michael Meskes wrote:
> Thanks Ashutosh,
>
> both patches committed and backported to the whole 9.* series.
>
> Michael
> --
> Michael Meskes
> Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
> Michael at BorussiaFan dot
On 09 April 2014 13:31, Nicolas Barbier Wrote
> Do you have a real-world example use case of such joins, to offset the
> extra planner time that will likely have to be paid (even for queries
> for which the functionality ends up not being used)?
>
> I guess there might be queries that join on “va
Thanks Ashutosh,
both patches committed and backported to the whole 9.* series.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia
On 2014-04-09 05:34:42 -0400, Simon Riggs wrote:
> On 21 March 2014 14:22, Andres Freund wrote:
>
> > That seems to work fairly well. On the few tests I could run on my
> > laptop - I've done this during a flight - it's a small performance win
> > in all cases I could test. While saving a fair am
As part of the ALTER TABLE lock reductions we've now agreed that
reloptions should have a lock level associated with them, so we can
take appropriate lock levels.
Attached patch will be applied at start of 9.5 dev cycle, so that any
new relopt authors are aware that lock levels are needed for any
On 21 March 2014 14:22, Andres Freund wrote:
> That seems to work fairly well. On the few tests I could run on my
> laptop - I've done this during a flight - it's a small performance win
> in all cases I could test. While saving a fair amount of memory.
We've got to the stage now that saving thi
On Wed, Apr 9, 2014 at 1:21 AM, Heikki Linnakangas
wrote:
> I didn't say that. On the contrary, I think the shotgun approach jsonb_ops
> and jsonb_hash_ops take is too broad. It should be possible to specify what
> to index in a more detailed fashion.
It is - use an expression index. That's by fa
On Tue, Apr 8, 2014 at 02:08:25PM -0400, Greg Stark wrote:
> On Mon, Apr 7, 2014 at 10:43 AM, Robert Haas wrote:
> > OK, done. One less thing to worry about when committing!
>
> Also one less thing to cause headaches with etags and similar tools.
> It always drove me nuts that I was constantly
Thank you, this done the job.All the best
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Firing-trigger-if-only-tp5798484p5799344.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
On Wed, Apr 9, 2014 at 01:02:05AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > Well, that's sorta my concern. I mean, right now we've got people
> > saying "what the heck is a replica identity?". But, if the logical
> > decoding stuff becomes popular, as I hope it will, that's going to be
>
On 04/09/2014 10:40 AM, Peter Geoghegan wrote:
On Tue, Apr 8, 2014 at 11:37 PM, Heikki Linnakangas
wrote:
As the code stands, you don't have a choice on any of those things. The
decisions have been made by us, PostgreSQL developers. The only choice you
have is between jsonb_ops and jsonb_hash_o
On 8 April 2014 21:48, Florian Pflug wrote:
> On Apr7, 2014, at 17:41 , Dean Rasheed wrote:
>> I've just finished reading through all the other patches, and they all
>> look OK to me. It's mostly straightforward stuff, so despite the size
>> it's hopefully all committable once the base patch goes
2014-04-09 Dilip kumar :
> I would like to propose a New merge join algorithm for optimizing non ‘=’
> operators. (‘<’, ‘<=’, ‘>’, ‘>=’)
Do you have a real-world example use case of such joins, to offset the
extra planner time that will likely have to be paid (even for queries
for which the funct
Hi all
While working on something else I just noticed that there's no PQconnect
variant that can consume the output from PQconninfoParse(...), i.e. an
array of PQconninfoOption* .
This would be a nice-to-have for times when you want to pass a connstr,
modify it, and then connect with the modified
On Tue, Apr 8, 2014 at 11:37 PM, Heikki Linnakangas
wrote:
> As the code stands, you don't have a choice on any of those things. The
> decisions have been made by us, PostgreSQL developers. The only choice you
> have is between jsonb_ops and jsonb_hash_ops, with a strange combination of
> tradeoff
On 04/09/2014 09:55 AM, Hannu Krosing wrote:
This would be greatly simplified if we can accept the restriction that
there is only single
snapshot per backend (not per transaction). To me this seems a
completely sensible restriction.
Huh? In Read committed mode, every query within a transaction
83 matches
Mail list logo
