Tom,
Many thanks for your comments and for jumping into this discussion.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Joshua D. Drake (j...@commandprompt.com) wrote:
> >> It seems to me that perhaps the solution is then to pull pg_audit
> >> into user space and instead wo
On Wed, May 27, 2015 at 5:13 PM, Naoya Anzai wrote:
>> Perhaps we could make the documentation
>> clearer about those things though, changing the description of this
>> function to "get current transaction ID, and assign a new one if one
>> is not assigned yet":
>> http://www.postgresql.org/docs/d
At 2015-05-27 23:41:29 -0400, t...@sss.pgh.pa.us wrote:
>
> What about turning ReadDir into a wrapper around a ReadDirExtended
> function that adds an elevel argument?
Sounds reasonable, doing.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Abhijit Menon-Sen writes:
> At 2015-05-27 20:22:18 -0400, t...@sss.pgh.pa.us wrote:
>> I doubt that that (not using AllocateDir) [â¦]
> (Disregarding per your followup.)
>> What I think is a reasonable compromise is to treat AllocateDir
>> failure as nonfatal, but to continue using ReadDir etc
On Wed, May 27, 2015 at 11:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, May 27, 2015 at 11:00 PM, Tom Lane wrote:
>>> Assuming that we can get a fix for the fsync-failure-during-restart
>>> problem committed by the end of the week, there will be a new set of
>>> back-branch minor rele
Robert Haas writes:
> On Wed, May 27, 2015 at 11:00 PM, Tom Lane wrote:
>> Assuming that we can get a fix for the fsync-failure-during-restart
>> problem committed by the end of the week, there will be a new set of
>> back-branch minor releases next week. Usual schedule, wrap Monday
>> for publi
On Wed, May 27, 2015 at 11:00 PM, Tom Lane wrote:
> Assuming that we can get a fix for the fsync-failure-during-restart
> problem committed by the end of the week, there will be a new set of
> back-branch minor releases next week. Usual schedule, wrap Monday
> for public announcement Thursday.
W
At 2015-05-27 20:22:18 -0400, t...@sss.pgh.pa.us wrote:
>
> I doubt that that (not using AllocateDir) […]
(Disregarding per your followup.)
> What I think is a reasonable compromise is to treat AllocateDir
> failure as nonfatal, but to continue using ReadDir etc which means
> that any post-open f
On 05/27/2015 07:02 PM, Stephen Frost wrote:
JD,
As it is currently an extension, it does not need to be in core. If
this extension reaches a point where it needs to be in core to
achieve some level of integration not currently provided then we can
evaluate that problem. Currently, that is not
Assuming that we can get a fix for the fsync-failure-during-restart
problem committed by the end of the week, there will be a new set of
back-branch minor releases next week. Usual schedule, wrap Monday
for public announcement Thursday.
regards, tom lane
--
Sent via pgs
On Wed, May 27, 2015 at 10:14 PM, Alvaro Herrera
wrote:
> Well I'm not very clear on what's the problematic case. The scenario I
> actually saw this first reported was a pg_basebackup taken on a very
> large database, so the master could have truncated multixact and the
> standby receives a trunc
Stephen Frost writes:
> * Joshua D. Drake (j...@commandprompt.com) wrote:
>> It seems to me that perhaps the solution is then to pull pg_audit
>> into user space and instead work on a general solution (an API?
>> custom backend?) that provides what is needed.
> I am planning on working on the nec
2015-05-28 3:30 GMT+02:00 Joshua D. Drake :
>
> On 05/27/2015 06:11 PM, Stephen Frost wrote:
>
> Thank you for your honest comments and your concern.
>>
>> I sincerely hope you're able to be involved in developing auditing for
>> PostgreSQL in the future, as it is a key requirement in any secure
On Thu, Apr 30, 2015 at 8:07 PM, Sawada Masahiko wrote:
> On Fri, Apr 24, 2015 at 11:21 AM, Sawada Masahiko
> wrote:
>> On Fri, Apr 24, 2015 at 1:31 AM, Jim Nasby wrote:
>>> On 4/23/15 11:06 AM, Petr Jelinek wrote:
On 23/04/15 17:45, Bruce Momjian wrote:
>
> On Thu, Apr 23, 20
Robert Haas wrote:
> On Wed, May 27, 2015 at 6:21 PM, Alvaro Herrera
> wrote:
> > Steve Kehlet wrote:
> >> I have a database that was upgraded from 9.4.1 to 9.4.2 (no pg_upgrade, we
> >> just dropped new binaries in place) but it wouldn't start up. I found this
> >> in the logs:
> >>
> >> waiting
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
> On 05/27/2015 06:38 PM, Stephen Frost wrote:
> >While I certainly appreciate the support, I don't believe auditing will
> >be able to work as an extension over the long term and if the community
> >is unwilling or unable to accept steps in th
On Wed, May 27, 2015 at 6:21 PM, Alvaro Herrera
wrote:
> Steve Kehlet wrote:
>> I have a database that was upgraded from 9.4.1 to 9.4.2 (no pg_upgrade, we
>> just dropped new binaries in place) but it wouldn't start up. I found this
>> in the logs:
>>
>> waiting for server to start2015-05-27 1
On 05/27/2015 06:38 PM, Stephen Frost wrote:
While I certainly appreciate the support, I don't believe auditing will
be able to work as an extension over the long term and if the community
is unwilling or unable to accept steps in that direction through contrib
modules or even changes to core t
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
> On 05/27/2015 06:11 PM, Stephen Frost wrote:
> >Thank you for your honest comments and your concern.
> >
> >I sincerely hope you're able to be involved in developing auditing for
> >PostgreSQL in the future, as it is a key requirement in any
2015-05-28 1:41 GMT+08:00 David G. Johnston :
> On Tue, May 26, 2015 at 7:03 PM, digoal zhou
> wrote:
>
>> When we create table, some column use foreign key references.
>> Now PostgreSQL don't create index for the FK, and there is no problem.
>> But when some body need the index to speed up the q
On 05/27/2015 06:11 PM, Stephen Frost wrote:
Thank you for your honest comments and your concern.
I sincerely hope you're able to be involved in developing auditing for
PostgreSQL in the future, as it is a key requirement in any secure
environment.
Guys,
I think we are overlooking the rath
On Wed, May 27, 2015 at 6:55 PM, Andres Freund wrote:
> On 2015-05-27 15:39:14 -0400, Robert Haas wrote:
>> On Mon, May 25, 2015 at 10:05 PM, Andres Freund wrote:
>> > Hm. So we have a *occasional* stack size exceeded failure and an
>> > occasional spinlock error in test_shm_mq. I'm inclined to t
Steve Kehlet wrote:
> On Wed, May 27, 2015 at 3:21 PM Alvaro Herrera
> wrote:
>
> > I think a patch like this should be able to fix it ... not tested yet.
> >
>
> Thanks Alvaro. I got a compile error, so looked for other uses of
> SimpleLruDoesPhysicalPageExist and added MultiXactOffsetCtl, does
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> On Wed, May 27, 2015 at 04:36:53PM -0400, Stephen Frost wrote:
> > This list includes all issues that I've
> > identified from the commits done to master, comments made by the
> > numerous individuals who have taken time to look at the patch and
> >
On Wed, May 27, 2015 at 04:36:53PM -0400, Stephen Frost wrote:
> This list includes all issues that I've
> identified from the commits done to master, comments made by the
> numerous individuals who have taken time to look at the patch and
> comment, and those found by the ongoing work of David and
On Wednesday, May 27, 2015, digoal zhou wrote:
>
> 2015-05-28 1:41 GMT+08:00 David G. Johnston >:
>
>> On Tue, May 26, 2015 at 7:03 PM, digoal zhou > > wrote:
>>
>>> When we create table, some column use foreign key references.
>>> Now PostgreSQL don't create index for the FK, and there is no pro
On Thu, May 28, 2015 at 6:07 AM, Gaetano Mendola wrote:
> I'm playing with a static analyzer and it's giving out some real error
> analyzing postgresql code base like the following one
>
> src/backend/access/transam/commit_ts.c
>return *ts != 0 // line 321
> but a few line up (line 315) ts is
I wrote:
> Abhijit Menon-Sen writes:
>> At 2015-05-27 11:46:39 +0530, a...@2ndquadrant.com wrote:
>>> I'm trying a couple of approaches to that (e.g. using readdir directly
>>> instead of ReadDir), but other suggestions are welcome.
>> Here's what that looks like, but not yet fully tested.
> I d
Abhijit Menon-Sen writes:
> At 2015-05-27 11:46:39 +0530, a...@2ndquadrant.com wrote:
>> I'm trying a couple of approaches to that (e.g. using readdir directly
>> instead of ReadDir), but other suggestions are welcome.
> Here's what that looks like, but not yet fully tested.
I doubt that that (n
On 5/27/15 5:08 PM, Andres Freund wrote:
> I don't think I need to. clang-format has apparently done pretty much
> what I described:
Well, that appears to work reasonably well in practice, which is all we
can hope for. Unfortunately, clang-format makes a bit of a mess of some
of our code, so it i
Folks,
The time may have come again to discuss $Subject. As I recall, the
state of the spec back in 2007, when this was last discussed, was so
abysmal that we simply abandoned the effort.
It appears, at least to me, that SQL:2011 has polished this up in ways
that could be helpful, especially whe
On 2015-05-27 15:39:14 -0400, Robert Haas wrote:
> On Mon, May 25, 2015 at 10:05 PM, Andres Freund wrote:
> > Hm. So we have a *occasional* stack size exceeded failure and an
> > occasional spinlock error in test_shm_mq. I'm inclined to think that
> > this is a shm_mq problem, and not a more gener
On Wed, May 27, 2015 at 3:21 PM Alvaro Herrera
wrote:
> I think a patch like this should be able to fix it ... not tested yet.
>
Thanks Alvaro. I got a compile error, so looked for other uses of
SimpleLruDoesPhysicalPageExist and added MultiXactOffsetCtl, does this look
right?
+ (!InRecovery |
Steve Kehlet wrote:
> I have a database that was upgraded from 9.4.1 to 9.4.2 (no pg_upgrade, we
> just dropped new binaries in place) but it wouldn't start up. I found this
> in the logs:
>
> waiting for server to start2015-05-27 13:13:00 PDT [27341]: [1-1] LOG:
> database system was shut do
On Wed, May 27, 2015 at 10:06:03PM +0200, Christoph Berg wrote:
> Re: Bruce Momjian 2015-05-27 <20150527174244.gb31...@momjian.us>
> > > In fact, I'm wondering if pg_upgrade shouldn't rather *increase* the
> > > timeline to make sure the archive_command doesn't clobber any files
> > > from the old
On 05/27/2015 05:19 PM, Peter Eisentraut wrote:
And even if we got to the point where all commits should be perfectly
pgindented, it wouldn't work, because under the current workflow the
updated typedef list isn't available until after the commit (on an
unpredictable schedule). (This problem w
boix writes:
> Hello, my partner and me are working with the goal of improve the GEQO's
> performance, we tried with Ant Colony Optimization, but it does not
> improve, actually we are trying with a new variant of Genetic Algorithm,
> specifically Micro-GA. This algorithm finds a better solutio
On 5/27/15 2:55 PM, Tom Lane wrote:
> These are all things we might try to fix (where "fix" could include
> "replace it with another tool") if the back-patching pain created by even
> minor changes of the formatting rules weren't so great. But at this point
> I despair of getting to consensus on a
On 2015-05-27 16:55:45 -0400, Peter Eisentraut wrote:
> On 5/26/15 8:31 PM, Andres Freund wrote:
> > I actually think both are relatively easy to figure out without a
> > typedef list. There's harder cases though, e.g. (char *) &foo in an
> > expression is already more complicated.
>
> Well, if yo
On 5/26/15 8:31 PM, Andres Freund wrote:
> I actually think both are relatively easy to figure out without a
> typedef list. There's harder cases though, e.g. (char *) &foo in an
> expression is already more complicated.
Well, if you know of a way to fix this, let's see it. Others have been
tryin
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> I note that there are already 11 followup commits fixing bugs in
> pg_audit, including 7 in the first 24 hours. It's usually not a good
> thing when you can get the regression tests for a piece of
> platform-independent code to pass in less t
Robert Haas writes:
> Tom, do you want to review this patch and figure out how to solve the
> underlying problem? If not, I will take care of it. But I will be
> unhappy if I put time and effort into this and then you insist on
> changing everything afterwards, again.
[ sorry for slow response,
Jeff Janes writes:
> As it is currently, it is not clear what purpose nonempty_pages serves.
It's to allow an early exit at vacuumlazy.c:271 in case there is no chance
of deleting a useful number of pages.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql
I'm playing with a static analyzer and it's giving out some real error
analyzing postgresql code base like the following one
src/backend/access/transam/commit_ts.c
return *ts != 0 // line 321
but a few line up (line 315) ts is checked for null, so either is not
needed to check for null or *ts
Re: Bruce Momjian 2015-05-27 <20150527174244.gb31...@momjian.us>
> > In fact, I'm wondering if pg_upgrade shouldn't rather *increase* the
> > timeline to make sure the archive_command doesn't clobber any files
> > from the old cluster when reused in the new cluster?
> >
> > https://bugs.debian.org
On Wed, May 27, 2015 at 3:25 PM, Ted Toth wrote:
> On Wed, May 27, 2015 at 1:31 PM, Robert Haas wrote:
>> On Wed, May 27, 2015 at 11:35 AM, Ted Toth wrote:
>>> I'm trying to use a newer version than is available from RH in our
>>> custom distro but am having problems install both x86_64 and i686
On Mon, May 25, 2015 at 10:05 PM, Andres Freund wrote:
> Hm. So we have a *occasional* stack size exceeded failure and an
> occasional spinlock error in test_shm_mq. I'm inclined to think that
> this is a shm_mq problem, and not a more general locking problem - it
> seems likely, but not guarantee
http://yum.postgresql.org/9.4/redhat/rhel-6.5-x86_64/
On Wed, May 27, 2015 at 1:31 PM, Robert Haas wrote:
> On Wed, May 27, 2015 at 11:35 AM, Ted Toth wrote:
>> I'm trying to use a newer version than is available from RH in our
>> custom distro but am having problems install both x86_64 and i686
Hello, my partner and me are working with the goal of improve the GEQO's
performance, we tried with Ant Colony Optimization, but it does not
improve, actually we are trying with a new variant of Genetic Algorithm,
specifically Micro-GA. This algorithm finds a better solution than GEQO
in less t
Andres Freund writes:
> But really, the typedef list is the minor part what annoys me about
> pgindent. That it completely butchers so many constructs (e.g. function
> pointer typedefs, inline asm as extreme examples) is much worse.
These are all things we might try to fix (where "fix" could incl
On 05/27/2015 02:37 PM, Robert Haas wrote:
On Tue, May 26, 2015 at 2:50 AM, Shulgin, Oleksandr
wrote:
Is it reasonable to add this patch to CommitFest now?
It's always reasonable to add a patch to the CommitFest if you would
like for it to be reviewed and avoid having it get forgotten about.
On Tue, May 26, 2015 at 2:50 AM, Shulgin, Oleksandr
wrote:
> Is it reasonable to add this patch to CommitFest now?
It's always reasonable to add a patch to the CommitFest if you would
like for it to be reviewed and avoid having it get forgotten about.
There seems to be some disagreement about whe
On Tue, May 26, 2015 at 2:46 AM, Nivedita Kulkarni
wrote:
> We have newbie to Postgresql.
Hi,
You've reached the pgsql-hackers mailing list, which is for discussion
of current development issues, problems and bugs, and proposed new
features. Questions about how to use PostgreSQL should be dire
On Wed, May 27, 2015 at 11:35 AM, Ted Toth wrote:
> I'm trying to use a newer version than is available from RH in our
> custom distro but am having problems install both x86_64 and i686 rpms
> because file conflicts. We have some i686 packages that use libgdal
> which pulls in libpq which ends up
On Mon, May 18, 2015 at 10:21 AM, Tom Lane wrote:
> Uriy Zhuravlev writes:
>> I have attached a patch that extends ALTER OPERATOR to support COMMUTATOR,
>> NEGATOR, RESTRICT and JOIN.
>
> There are fairly significant reasons why we have not done this, based
> on the difficulty of updating existin
On Wed, May 27, 2015 at 05:40:09PM +0200, Christoph Berg wrote:
> commit 4c5e060049a3714dd27b7f4732fe922090edea69
> Author: Bruce Momjian
> Date: Sat May 16 00:40:18 2015 -0400
>
> pg_upgrade: force timeline 1 in the new cluster
>
> Previously, this prevented promoted standby servers
On Tue, May 26, 2015 at 7:03 PM, digoal zhou wrote:
> When we create table, some column use foreign key references.
> Now PostgreSQL don't create index for the FK, and there is no problem.
> But when some body need the index to speed up the query within these APP,
> they need to add the index man
On Mon, May 25, 2015 at 04:35:11PM -0300, Alvaro Herrera wrote:
> Davin M. Potts wrote:
> > At Alvaro's suggestion, I'm forwarding my questions (see email thread
> > further below) to this list.
> >
> > In short, building of PL/Python has been disabled on OpenBSD since 2005.
> > The errors seen at
When we create table, some column use foreign key references.
Now PostgreSQL don't create index for the FK, and there is no problem.
But when some body need the index to speed up the query within these APP,
they need to add the index manual one-by-one when has many tables.
If we can add syntax for
On Mon, May 25, 2015 at 04:26:02PM -0400, Andrew Dunstan wrote:
>
> On 05/25/2015 03:35 PM, Andrew Dunstan wrote:
> >
> >On 05/25/2015 12:38 PM, Davin M. Potts wrote:
> >>At Alvaro's suggestion, I'm forwarding my questions (see email thread
> >>further below) to this list.
> >>
> >>In short, build
On Mon, May 25, 2015 at 04:37:11PM -0400, Tom Lane wrote:
> "Davin M. Potts" writes:
> > At Alvaro's suggestion, I'm forwarding my questions (see email thread
> > further below) to this list.
>
> > In short, building of PL/Python has been disabled on OpenBSD since 2005.
> > The errors seen at the
On 05/27/2015 09:40 AM, Glyn Astill wrote:
From: Andreas Joseph Krogh
To: pgsql-hackers@postgresql.org
Sent: Wednesday, 27 May 2015, 13:55
Subject: Re: [HACKERS] Triggers on transaction?
På onsdag 27. mai 2015 kl. 12:42:29, skrev Marko Tiikkaja :
On 5/27/15 12:39 PM, Jordan Gigov wrote:
I fo
On Wed, May 27, 2015 at 9:24 AM, Stephen Frost wrote:
> I agree that the documentation needs improvement. I don't agree with
> your assessment that the code quality is well below the level we
> normally expect, as committed. That's clearly a difficult thing to
> judge, hence my compromise propos
On 05/27/2015 11:53 AM, Bruce Momjian wrote:
On Wed, May 27, 2015 at 02:31:07AM +0200, Andres Freund wrote:
But really, the typedef list is the minor part what annoys me about
pgindent. That it completely butchers so many constructs (e.g. function
pointer typedefs, inline asm as extreme example
On Wed, May 27, 2015 at 7:00 PM, Dan Langille wrote:
> Have you been to PGCon before? Do you remember the hacker lounge? Do you
> remember going there to work on stuff? Do you recall anything about it?
>
I remember I've tried to visit it in 2012 or 2013. That time I found empty
room and nobod
Have you been to PGCon before? Do you remember the hacker lounge? Do you
remember going there to work on stuff? Do you recall anything about it?
—
Dan Langille
http://langille.org/
signature.asc
Description: Message signed with OpenPGP using GPGMail
On Wed, May 27, 2015 at 02:31:07AM +0200, Andres Freund wrote:
> But really, the typedef list is the minor part what annoys me about
> pgindent. That it completely butchers so many constructs (e.g. function
> pointer typedefs, inline asm as extreme examples) is much worse. It's
> also neigh on impo
commit 4c5e060049a3714dd27b7f4732fe922090edea69
Author: Bruce Momjian
Date: Sat May 16 00:40:18 2015 -0400
pg_upgrade: force timeline 1 in the new cluster
Previously, this prevented promoted standby servers from being upgraded
because of a missing WAL history file. (Timeline 1 do
I'm trying to use a newer version than is available from RH in our
custom distro but am having problems install both x86_64 and i686 rpms
because file conflicts. We have some i686 packages that use libgdal
which pulls in libpq which ends up in the same location in both the
x86_64 and i686 postgresq
* Noah Misch (n...@leadboat.com) wrote:
> The test case demonstrated a hole in GRANT auditing, and your diagnosis is
> incorrect. GRANT statements aren't subject to event triggers. Selecting DDL
> too, with pg_audit.log=all, does not audit the GRANT substatement.
GRANT statements are subject to
On 27 May 2015 at 15:06, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > What I think should happen is that the command tag should vary according
> to
> > whether an INSERT or an UPDATE was performed, so we get a visible
> > difference without any new tags.
>
> The problem with doing that is tha
Simon Riggs writes:
> Can't you just use deferred triggers?
That seems like the real $64 question.
> I'm not clear exactly when such a trigger should run. If the trigger issues
> more SQL, which also has triggers... do we run the PreCommit trigger twice?
> Or just accept that we wanted it to run
Simon Riggs wrote:
> What I think should happen is that the command tag should vary according to
> whether an INSERT or an UPDATE was performed, so we get a visible
> difference without any new tags.
The problem with doing that is that the same command might have updated
some tuples and inserted
On Tue, May 26, 2015 at 04:32:42PM -0300, Alvaro Herrera wrote:
> Robert Haas wrote:
>
> > But every time we pgindent, especially with slightly different
> > settings, we cause tools like 'git blame' to return less useful
> > answers. And that sucks.
>
> I've wondered a few times whether there's
On Tue, May 26, 2015 at 08:10:04PM -0400, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > > + /*
> > > + * Don't audit substatements. All the substatements we care about
> > > should
> > > + * be covered by the event triggers.
> > > + */
> > > + if (context <= PROCESS_UTILI
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 27 May 2015 at 02:42, Stephen Frost wrote:
> > Now, looking at the code, I'm actually failing to see a case where we
> > use the RowSecurityPolicy->policy_name.. Perhaps *that's* what we
> > should be looking to remove?
>
> If we add s
> From: Andreas Joseph Krogh
>To: pgsql-hackers@postgresql.org
>Sent: Wednesday, 27 May 2015, 13:55
>Subject: Re: [HACKERS] Triggers on transaction?
>
>
>På onsdag 27. mai 2015 kl. 12:42:29, skrev Marko Tiikkaja :
>On 5/27/15 12:39 PM, Jordan Gigov wrote:
>>> I found myself in need of triggers
Robert,
Thank you for your response.
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, May 26, 2015 at 8:10 PM, Stephen Frost wrote:
> > I certainly welcome review from others and if there is not another
> > committer-level formal review before we get close on 9.5 (say, end of
> > August),
On 22 May 2015 at 00:28, Alvaro Herrera wrote:
> > On the other hand, this was noticed because Alvaro just argued that it
> > *should* have a new command tag. Alvaro, where do you see the advantage?
>
> Well, I was just skimming nearby code and noticed that CreateCommandTag
> hadn't been updated
På onsdag 27. mai 2015 kl. 12:42:29, skrev Marko Tiikkaja mailto:ma...@joh.to>>:
On 5/27/15 12:39 PM, Jordan Gigov wrote:
> I found myself in need of triggers that are run only once per transaction,
> rather than per row or statement within the transaction. Meaning it will
> always be deferred a
On 27 May 2015 at 11:55, Jordan Gigov wrote:
> Updating a materialized view in my case. It should only update when 2-3 of
> our 30+ tables get new data, which for those is kind of rare. Not having
> such a trigger means I will have to call it in each usage in the code and
> hope future maintainer
On Wed, May 27, 2015 at 12:07 PM, hubert depesz lubaczewski <
dep...@depesz.com> wrote:
> On Wed, May 27, 2015 at 01:55:24PM +0300, Jordan Gigov wrote:
> > Updating a materialized view in my case. It should only update when 2-3
> of
> > our 30+ tables get new data, which for those is kind of rare.
On Wed, May 27, 2015 at 01:55:24PM +0300, Jordan Gigov wrote:
> Updating a materialized view in my case. It should only update when 2-3 of
> our 30+ tables get new data, which for those is kind of rare. Not having
> such a trigger means I will have to call it in each usage in the code and
> hope fu
Updating a materialized view in my case. It should only update when 2-3 of
our 30+ tables get new data, which for those is kind of rare. Not having
such a trigger means I will have to call it in each usage in the code and
hope future maintainers don't forget it. This is why I postponed migrating
th
> Andres Freund wrote:
> > Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
>
Few comments/questions:
1.
insert.sgml
+ column. For example, INSERT ... ON CONFLICT DO UPDATE
+ tab SET table_name.col = 1 is invalid (this follows the general
+ behavior for UPDATE).
Here in
On 5/27/15 12:39 PM, Jordan Gigov wrote:
I found myself in need of triggers that are run only once per transaction,
rather than per row or statement within the transaction. Meaning it will
always be deferred and never called twice for the same transaction.
What's the use case?
.m
--
Sent vi
I found myself in need of triggers that are run only once per transaction,
rather than per row or statement within the transaction. Meaning it will
always be deferred and never called twice for the same transaction.
Perhaps in 9.6 this part of syntax for trigger creation can be changed from:
[ FO
2015-05-27 0:01 GMT+02:00 Martín Marqués :
> El 25/05/15 a las 06:13, alex2010 escribió:
> > Maybe it makes sense to add ability to store large objects in the same
> table space as the table.
> > Or an opportunity - to specify table space for a large object.
> > Do you have anything in todolists
Thank you for comments.
I understand your points.
For only to read a current transaction-id, I know we just have to use
txid_current_snapshot and that is a best way, but I feel a little bit
hassle to explain columns of txid_current_snapshot for my supporting customers..
(Xmin is and Xmax i
On 27 May 2015 at 02:42, Stephen Frost wrote:
> Now, looking at the code, I'm actually failing to see a case where we
> use the RowSecurityPolicy->policy_name.. Perhaps *that's* what we
> should be looking to remove?
>
If we add support for restrictive policies, it would be possible, and
I think
90 matches
Mail list logo
